Skip to main content

Last Call Review of draft-ietf-dart-dscp-rtp-07
review-ietf-dart-dscp-rtp-07-genart-lc-sparks-2014-10-14-00

Request Review of draft-ietf-dart-dscp-rtp
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-10-14
Requested 2014-10-02
Authors David L. Black , Paul Jones
I-D last updated 2014-10-14
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 Robert Sparks
State Completed
Request Last Call review on draft-ietf-dart-dscp-rtp by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 10)
Result Ready w/nits
Completed 2014-10-14
review-ietf-dart-dscp-rtp-07-genart-lc-sparks-2014-10-14-00
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dart-dscp-rtp-07
Reviewer: Robert Sparks
Review Date: 14-Oct-2014
IETF LC End Date: 14-Oct-2014
IESG Telechat date: not yet scheduled for a telechat

Summary: Ready with nits

These are very small nits to consider. Please feel free to leave the
existing text alone if these suggestions don't help.

At the end of page 13, the sentence that starts "Transport protocol
support for multiple"... is very long and hard to parse. I suspect it
will be hard to translate. The action of changing the existing protocols
is implied rather than explicit in the current wording. "current
designs" is vague. I suggest this as a starting point: "Adding support
for multiple QoS-based traffic classes within a single network 5-tuple
to a transport protocol adds significant complexity compared to the
current protocol definitions. For congestion-controlled transport
protocols, network congestion information for each QoS-based traffic
class would have to be disambiguated to allow congestion control to be
managed separately for each such traffic class." Hopefully it can be
made even simpler.

In the first paragraph of 5.2, would "Such reordering may lead to
unneeded retransmission, and spurious emission of retransmission control
signals (such as NACK) in reliable delivery protocols (see Section 5.1)"
work?