Skip to main content

Last Call Review of draft-ietf-dart-dscp-rtp-07
review-ietf-dart-dscp-rtp-07-secdir-lc-tsou-2014-10-23-00

Request Review of draft-ietf-dart-dscp-rtp
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-10-14
Requested 2014-10-02
Authors David L. Black , Paul Jones
I-D last updated 2014-10-23
Completed reviews Genart Last Call review of -07 by Robert Sparks (diff)
Genart Telechat review of -08 by Robert Sparks (diff)
Secdir Last Call review of -07 by Tina Tsou (Ting ZOU) (diff)
Opsdir Last Call review of -07 by Fred Baker (diff)
Assignment Reviewer Tina Tsou (Ting ZOU)
State Completed
Request Last Call review on draft-ietf-dart-dscp-rtp by Security Area Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has issues
Completed 2014-10-23
review-ietf-dart-dscp-rtp-07-secdir-lc-tsou-2014-10-23-00

Dear all,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security
 area directors. Document editors and WG chairs should treat these comments
 just like any other last call comments.

IMHO, the document is

almost ready

. I just have minor comments:

** Technical **

* Page 6:

For IPv6, addition of the flow label [RFC6437] to network 5-tuples

results in network 6-tuples, but in practice, use of a flow label is

unlikely to result in a finer-grain traffic subset than the

corresponding network 5-tuple (e.g., the flow label is likely to

represent the combination of two ports with use of the UDP

protocol).

The flow label is different in each direction. Hence, if anything, you

should talk about 7-tuples rather than 6-tuples.

* Page 6, Section 2.2:

What about the drawbacks of multiplexing? -- You don't describe any.

What about Head of Line blocking?

* Page 13, Section 5.1:

When a protocol that provides reliable delivery receives a packet

other than the next expected packet, the protocol usually assumes

that the expected packet has been lost and respond with a

retransmission request for that packet.

Note: There is no "retransmission request" in TCP. Aditionally:

s/respond/responds/

* Page 13, Section 5.1:

This should not be done for current transport protocols within a

single network 5-tuple, with the exception of UDP and UDP-Lite.

This text is rather confusing. Maybe rephrase as "This should not be

done for transport protocol instances of current protocols, except of

UDP and UDP-Lite"?

* Security considerations section

Maybe Section 3.3 of RFC 6274 wuld be of use here?

** Nits/Editorial **

* Page 2:

The results of using multiple DSCPs to obtain different QoS

treatments within a single network 5-tuple (e.g., reordering) have

transport protocol interactions, particularly with congestion

control functionality.

Please "(e.g., reordering)" right after "treatments".

* Page 2:

s/requirments/requirements/

* Page 3:

Please add references for VP8 and H264

* Page 5:

RTP is usually carried over a datagram protocol, such as

UDP[RFC0768], UDP-Lite [RFC3828] or DCCP [RFC4340]; UDP is most

commonly used, but a non-datagram protocol (e.g., TCP) may also be

used.

Add missing space in "UDP[RFC0768]".

* Page 6:

When TURN selects use of TCP, the entire real-time communications

session is carried over a single TCP 5-tuple.

s/five-tuple/connection/

* Page 8, Section 3:

The DiffServ architecture[RFC2475] maintains distinctions among:

Please add the missing space

* Page 8:

s/loading/load/

* Page 11, Section 3.2:

Better results may be achieved when DSCPs are used to spread traffic

among a smaller number of DiffServ-based traffic subsets or

aggregates, see [I-D.geib-tsvwg-diffserv-intercon] for one proposal.

Please put the "see [I-D..]" within parenthesis.

* Page 13, Section 5.1:

Reordering also affects other forms of congestion control, such as

techniques for RTP congestion control that were under development

when this memo was published, see [I-D.ietf-rmcat-cc-requirements]

for requirements.

Please put the "see [I-D..." within parethesis -- i.e. "(see [I-D..)".

* Page 17, section 5.4:

SSRC

Please expand this acronym.

* Page 18, Section 6:

, see Section 5.2 above.

Please put this text within parenthesis.

Thank you,

Tina