David B -05 review -- 5 DSCP Marking of NQB Traffic

(e.g. they are NQB on higher-speed links, but QB on lower-speed links) s/are NQB on/exhibit NQB behavior on/ and s/QB on/exhibit QB behavior on/ If there is uncertainty as to whether an application's traffic aligns with the description of NQB behavior in the preceding section, the application SHOULD NOT mark its traffic with the NQB DSCP. Well, the previous section (4) is somewhat conversational and informal, whereas this "SHOULD NOT" is a very important requirement. It would be better to spell that requirement out crisply, e.g., in the form of: If , or then the application SHOULD NOT mark its traffic with the NQB DSCP. That reduces the opportunity for different readers to reach different interpretations about what is required. In such a case, the application SHOULD instead implement a congestion control mechanism, for example as described in [RFC8085] or [I-D.ietf-tsvwg-ecn-l4s-id]. Add a specific section number or numbers to the citation of RFC 8085, as there's a lot of other material in that RFC. It is worthwhile to note again that the NQB designation and marking is intended to convey verifiable traffic behavior, not needs or wants. Hmm – perhaps s/not needs/in addition to needs/ ?? Thus, a useful property of nodes that support separate queues for NQB and QB flows would be that ... I suggest providing a forward reference at the end of this sentence to a section or sections later in this draft that explain more about how that property can be achieved, perhaps to Section 14 (Security considerations) ?

gwhiteCL / NQBdraft

David B -05 review -- 5 DSCP Marking of NQB Traffic #10