Re: [Dart] AD review of draft-ietf-dart-dscp-rtp-06

["Black, David" <[e-mail]>]

Richard,

Thank you for the review, and I’m pleased that the draft provides a helpful introduction to DiffServ.

Comments inline @ David>

I’ll submit a -07 with these changes plus a version of Colin’s suggested change to the 5.4 text on RTCP RTT behavior.

Thanks,
--David

From: Dart [mailto:[e-mail]] On Behalf Of Richard Barnes
Sent: Tuesday, September 23, 2014 10:22 PM
To: [e-mail]; [e-mail]
Subject: [Dart] AD review of draft-ietf-dart-dscp-rtp-06

I have reviewed this draft in preparation for IETF LC.  Overall this looks very good.  As someone who is not deeply familiar with DiffServ concepts, the document provided a helpful introduction and clearly justified its recommendations.  I'll go ahead and request last call.
Some minor comments are below.  My main concern is that this document is so well populated with references that it will get stuck in MISSREF for years while others catch up :)

Thanks,
--Richard

MINOR

Section 6:
"""
   The only use of multiple standardized PHBs and DSCPs that prevents
   network reordering among packets marked with different DSCPs is use
   of PHBs within a single AF class.
"""
It doesn't prevent reordering, right?  It just makes reordering much more unlikely and more transient.  (Unless you're using a strict definition of "network reordering" that ignores things like ECMP balancing.)  The "allow" phrasing is used several times in this section.  It would be helpful to clarify.

David> Will change “prevents” -> “does not enable” and change “allow” -> “enable”
EDITORIAL
Abstract:
"""
   Use of different DSCPs
   to obtain different QoS treatments within a single network 5-tuple,
   the results (e.g., reordering) may cause transport protocol
   interactions, particularly with congestion control functionality.
"""
This sentence doesn't really parse.  Maybe just delete "the results (e.g., reordering)"?  Likewise for the same phrase in the introduction.
David> Oh dear, I’ve clearly been staring at the same text for too long :-(.  Will rephrase to:
   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.
Introduction:
"""
   (Section 7 is an empty IANA Considerations section)
"""
Note to future self: Remove this parenthetical and renumber once this hits the RFC Editor.
David> I’ll swap the order of sections 7 and 8, then delete this parenthetical remark now ;-).
Section 5.1:
"""
   In general, marking packets with different DSCPs results in different
   PHBs being applied at nodes in the network, making reordering
   possible due to use of different pools of forwarding resources for
   each PHB.
"""
This seems like a pretty import, so I would state it more strongly.  It doesn't just make reordering possible, it makes it much more likely.  (This is the flip side of the Section 6 comment above.)
David> “possible” -> “very likely”