[auth48] Re: [AD] AUTH48: RFC-to-be 9956 <draft-ietf-tsvwg-nqb-33> for your review

[Megan Ferguson <[e-mail]>]

Greg, Ruediger, *Thomas, and *AD,

--
*AD/Gorry - please review/approve the updates to Section 7.2 (described in response to Question #21 below) viewable in the following diff(s):
   https://www.rfc-editor.org/authors/rfc9956-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9956-auth48rfcdiff.html (side by side)

--
Thank you for your replies, guidance, and updated XML file!

We have adopted Greg’s XML file and made some further changes (some requested, some additional).  

We have trimmed the list of questions we originally sent to only include:

-questions we needed to follow up on and/or those that are awaiting further author response on (e.g., Thomas’s opinion is requested) (16, 18, 21, 30(b), 31(c)).

-questions where Greg’s response led us to take further action (to point these out for your review — no further author action is required if our update correctly captures the intent).  We have created a diff file highlighting the changes we made to Greg’s file and included the link below the questions.

We consider all other questions from our first mail that are not in this list to be resolved.


#11: We have updated to use DS and codepoint as requested.

>> 11) <!-- [rfced] We see that [RFC2474] uses "DS" rather than "Diffserv"
>> for "Differentiated Services". It also uses "codepoint" rather
>> than "code point". Please review and let us know if/how to
>> update uses in this document.
>> 
>> 
>> Original:
>> The architecture defines the use of the Diffserv field [RFC2474] for
>> this purpose, and numerous RFCs have been written that describe
>> recommended interpretations of the values (Diffserv Code Points
>> [RFC2474]) of the field, and standardized treatments (traffic
>> conditioning and per-hop-behaviors [RFC2475]) that can be implemented
>> to satisfy the performance requirements of traffic so marked.
>> -->
>> 
>> [GW] Please align the terminology with RFC2474:  "DS" instead of "Diffserv", "codepoint" instead of "code point".



#16 - please see our possible rephrase below:

> 16) <!--[rfced] Might breaking this text into a list be easier for the
> reader?
> 
> 
> Original:
> Thus, a useful property of nodes (i.e. network switches and
> routers) that support separate queues for NQB and QB microflows is
> that for microflows consistent with the NQB sender requirements in
> Section 4, the NQB queue would likely be a better choice than the QB
> queue; and for microflows inconsistent with those requirements, the QB
> queue would likely be a better choice than the NQB queue.
> 
> 
> Perhaps:
> Thus, a useful property for nodes (i.e., network switches and routers)
> that support separate queues for NQB and QB microflows would be to
> behave as follows:
> 
> 
> * for microflows consistent with the NQB sender requirements in 
> Section 4, the NQB queue would likely be a better choice than 
> the QB queue and
> 
> 
> * for microflows inconsistent with the requirements in Section 4,
> the QB queue would likely be a better choice than the NQB queue.
> -->
> 
> [GW] I personally prefer the original.


[rfced] Might the following update be acceptable?

Perhaps:
Thus, a useful property of nodes (i.e., network switches and routers) that support separate queues for NQB and QB microflows is that each queue tends to be the better choice for the traffic it is designed for: the NQB queue for microflows consistent with the NQB sender requirements in Section 4 and the QB queue for those that are not.

#17 - we have cut the note as requested:
> 17) <!--[rfced] Section 6.3: We thank you for the note at the end of this
> section about citing an obsoleted RFC. Is the note meant to
> remain in the document at publication? If so, may we put it in
> the <aside> element?
> 
> 
> Original:
> [NOTE: this section references the obsoleted RFC2598 instead of its
> replacement RFC3246, because the former contains the description of
> EF performance.]
> -->
> 
> 
> [GW] I think it is unnecessary to keep the NOTE.

#18 - Apologies - Looks like we need to clarify our question: what technology/item described in Section 4 of RFC 8100 is operational (a document cannot be operational, but the concept the document describes)?

> 18) <!--[rfced] Perhaps it would be helpful to the reader to describe
> what part of RFC 8100 is being used here?
> 
> 
> Original:
> If [RFC8100] is operational between interconnected domains, the
> receiving domain may prefer a different DSCP for NQB traffic that
> allows for a DSCP range-based classification for the Default / Elastic
> Treatment Aggregate.
> -->
> 
> [GW] I will defer to Ruediger on this one.
> [RG] The reference or the sentence may refer to section 4 of RFC 8100, https://www.rfc-editor.org/rfc/rfc8100.html#section-4

[rfced] Might this suggested text work?  Or something similar?

Perhaps:
If a Diffserv-Intercon Interconnection Class (see Section 4 of [RFC8100]) is operational between interconnected domains, the receiving domain may prefer a different DSCP for NQB traffic that allows for a DSCP range-based classification for the Default / Elastic Treatment Aggregate.


#21 - we will await review by *Thomas of Greg’s response to this question (see mail below as this is a sizable suggestion).   We believe your update here also resolves our query #30a.  Please let us know if any further action is necessary in relation to #21 or #30a.

#22 - We have added the header from RFC 8325 to Figure 1.
> 22) <!-- [rfced] Figure 1 in RFC 8325 has header information that might be
> helpful to the reader to include in the update in this document. 
> Would you like us to add the header to the figure?
> 
> 
> Perhaps:
> +===============+======+==========+==================================+
> | IETF Diffserv | PHB |Reference | IEEE 802.11 |
> | Service Class | | RFC |User Priority| Access Category |
> |===============+======+==========+=============+====================|
> -->
> 
> [GW] Sure.


#25 - We have updated to the newest version, which is now 20.1.0 and have confirmed that the table you mentioned still has this title.

> 25) <!--[rfced] Please review the [SA-5G] reference entry. According to
> the URL, the most current version is 20.0.0. Should the
> reference entry be updated to point to that version? -->
> 
> [GW] Only if Table 5.7.4-1 is still:  Standardized 5QI to QoS characteristics mapping

#26 - We have updated to use the most current version as requested.
> 26) <!-- [rfced] Please review reference entry [IEEE802-11]. This
> reference points to a superseded version of IEEE Std 802.11 from
> 2020. The most current version is IEEE Std 802.11-2024. Would you
> like this reference to point to the most current version? -->
> 
> [GW] Yes, that’s fine.

#30(b) - (Please see original question/response in email below as this is a sizable response). 

> Do you prefer "DSCP value 45 (decimal)" when that fits?

[rfced] Is the above pointed to us?  We would leave the form chosen entirely up to the authors - we just want to point out that an inconsistency may exist and work to make it uniform if possible (for clarity / ease of the reader).

> [GW] I've made no changes on this yet. If you can confirm the preferred terminology, I will review each instance and check whether it works.
[rfced] We will await further action from the authors on all sub-points of #30(b).

#30(c) - Thank you for pointing this out.  We have included this response/suggestion in a separate mail thread regarding draft-briscoe-docsis-q-protection-07.

> c) Please review these similar uses for consistency:
> 
> 
> classic congestion control algorithm
> "classic congestion control" (capped because introducing a term)
> 
> 
> In the companion document (draft-briscoe-docsis-q-protection-07), we see:
> 
> 
> 'Classic" congestion control (and 'Scalable' congestion control)
> Classic queue
> Classic traffic
> classic congestion controllers
> 
> 
> Should these be made more consistent within the cluster?
> 
> [GW] In this document, the term is used as it was defined in RFC9330 (which it references). For draft-briscoe-docsis-q-protection-07, it would be worth reviewing those instances to see if they could be made more consistent with this document and with RFC9330.

[rfced] We will assume no updates are necessary to uses of Classic queue and Default queue in the document unless we hear otherwise.

#30(d) - We have updated as accepted:

> d) We several uses like the following:
> 
> 
> Original:
> ...that are relatively low data rate...
> 
> 
> ...be relatively low data rate...
> 
> 
> Where we would have expected "have a relatively low data rate". May
> we update these as such?
> 
> [GW] Yes.

#30(e) - We went with lowercase and DS domain to match the majority of instances.
> Diffserv Domain vs. DiffServ domain vs. Diffserv domain
> [GW] I'm unsure.  RFC2474 defines "Differentiated Services Domain", but then uses "DS domain" throughout.


#30(f) - We have made these updates as requested.

> f) We'd like to add hyphens to these terms, so they would appear as
> follows. Please let us know if this is acceptable.
> 
> 
> delay-sensitive applications / traffic
> high-capacity interior nodes
> low-data-rate microflow / application
> low-delay performance / variation services
> low-latency queue (both forms are used in RFCs 9330-9332)
> rate-shaped capacity
> rate-shaping function
> -->
> [GW] all are ok, except "low-delay variation services".   That one should be "low-delay-variation services" (low modifies variation which modifies delay).

#31(a) We did not see an overt response.  We will assume our expansions were acceptable unless we hear objection.

> a) We have added expansions for abbreviations upon first use per
> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness.

#31(c) - When updating to use abbreviations after they were used with expansion on the first instance, we noted some uses of “non-NQB-compliant”.  Please review for a double negative (non-non-queue-building) and let us know if these should instead be made QB.

Please also note that we updated to use QoE after expansion on first use.  Please let us know any objections.

# 32 - We have made the updates requested below:

> 
> [GW] The first instance: "has traditionally been defined." can be replaced by "has previously been defined."
> The second instance: "a more traditional Traffic Conditioning approach and police the application of the NQB DSCP" can be replaced by "a Traffic Conditioning approach that polices the application of the NQB DSCP”


For (especially Greg’s) convenience, a diff file highlighting the changes we made to the version submitted by Greg is available here:
  https://www.rfc-editor.org/authors/rfc9956rpcupdates-diff.html

A diff file between the last version and Greg’s version is available here:
  https://www.rfc-editor.org/authors/rfc9956greg-diff.html

Our usual diff files (encompassing changes from both of the above) are posted here (please refresh):
   https://www.rfc-editor.org/authors/rfc9956-diff.html
   https://www.rfc-editor.org/authors/rfc9956-rfcdiff.html (side by side)
   https://www.rfc-editor.org/authors/rfc9956-auth48diff.html
   https://www.rfc-editor.org/authors/rfc9956-auth48rfcdiff.html (side by side)

Our current files are posted here (please refresh):
   https://www.rfc-editor.org/authors/rfc9956.txt
   https://www.rfc-editor.org/authors/rfc9956.pdf
   https://www.rfc-editor.org/authors/rfc9956.html
   https://www.rfc-editor.org/authors/rfc9956.xml

Please review the document in its current form carefully as we do not make changes once it is published as an RFC.  

The AUTH48 status page is available here:
https://www.rfc-editor.org/auth48/rfc9956

The AUTH48 cluster information is available here:
https://www.rfc-editor.org/auth48/C350

Thank you.

Megan Feguson
RFC Production Center








> On Apr 23, 2026, at 7:11 AM, Ruediger.Geib=[e-mail] wrote:
> 
> Hi Greg,
> 
> I've inserted
> 
> [RG] The reference or the sentence may refer to section 4 of RFC 8100, https://www.rfc-editor.org/rfc/rfc8100.html#section-4
> 
> Below your comment regarding Question 18 in the text following.
> 
> Regards,
> 
> Ruediger
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Greg White <[e-mail]>
> Gesendet: Donnerstag, 23. April 2026 04:12
> An: [e-mail]; [e-mail]; Geib, Rüdiger <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Betreff: Re: AUTH48: RFC-to-be 9956 <draft-ietf-tsvwg-nqb-33> for your review
> 
> Hello Megan and Alice,
> 
> Thank you for your thorough review of this RFC-to-be!
> 
> Please see below, my [GW] responses to these numbered items.  To my coauthors, please review these responses and chime in if you have any disagreement.
> 
> Ruediger, could you specifically look at #18 below to see if you have any suggestions?
> 
> Thomas, could you specifically look at #21 below to see if my changes make sense?
> 
> In addition, I have included an updated XML ... with two apologies.  The first apology is that I see now your instructions clearly say to submit response inline -OR- via XML, whereas I've done both (some done in the XML, all noted in line below). The second apology is that I re-wrapped many of the paragraphs to make the XML easier to grep, though this may cause problems if you try to run a diff directly.   Please let me know if you want me to do anything differently.
> 
> Best Regards,
> Greg
> 
> 
> 
> 
> On 4/6/26, 11:45 PM, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> Authors,
> 
> 
> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
> 
> 
> 1) <!--[rfced] Please note that we have updated the short title of the
> document (that appears in the running header of the PDF output
> version) as follows to more closely match the full title. Please
> let us know any objections.
> 
> 
> Original:
> Non-Queue-Building PHB
> 
> 
> Current:
> NQB PHB for Diffserv
> -->
> 
> [GW] Ok.
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search <https://www.rfc-editor.org/search>. -->
> 
> [GW] I've added:
> 
> <keyword>DS</keyword>
> <keyword>DSCP</keyword>
> <keyword>L4S</keyword>
> <keyword>delay</keyword>
> <keyword>jitter</keyword>
> <keyword>delay variation</keyword>
> <keyword>Queuing Delay</keyword>
> <keyword>One Way Delay</keyword>
> <keyword>Round-Trip Time</keyword>
> <keyword>RTT</keyword>
> <keyword>Quality of Service</keyword>
> <keyword>QoS</keyword>
> <keyword>Quality of Experience</keyword>
> <keyword>QoE</keyword>
> 
> 
> 3) <!--[rfced] This sentence is long and employs a lot of hyphenation.
> Could we reword as follows to break things up a bit?
> 
> 
> Original:
> The purpose of this NQB PHB is to provide a separate queue that
> enables smooth (i.e. non-bursty), low-data-rate, application-limited
> traffic microflows, which would ordinarily share a queue with bursty
> and capacity-seeking traffic, to avoid the delay, delay variation and
> loss caused by such traffic.
> 
> 
> Perhaps:
> The purpose of this NQB PHB is to provide a separate queue
> enabling smooth (i.e., non-bursty) traffic microflows that have low data
> rates and limited applications to avoid the delay, delay variation,
> and loss caused by sharing a queue with bursty, capacity-seeking
> traffic (which they ordinarily would have done).
> -->
> 
> [GW] Your suggestion isn't directly usable, but here is an alternative for consideration.  I've left the XML untouched for now.
> 
> The purpose of this NQB PHB is to provide a separate queue
> enabling traffic microflows that are smooth (i.e. non-bursty),
> low-data-rate, and application-limited to avoid the delay, delay variation and
> loss that would ordinarily be caused by sharing a queue with bursty, capacity-seeking traffic.
> 
> 
> 4) <!--[rfced] We had a few questions about this sentence:
> 
> 
> a) Does this mean "are discussed in this document"? Or is there
> another way to update for clarity?
> 
> [GW] It means "are discussed in this document".
> 
> b) Are "mobile network radio" and "core segments" two separate entries
> in the list?
> 
> Original:
> In particular, the application of NQB PHB to cable broadband links,
> Wi-Fi links, and mobile network radio and core segments are discussed.
> 
> Perhaps:
> In particular, the application of NQB PHB to cable broadband links,
> Wi-Fi links, mobile network radio, and core segments are discussed in
> this document.
> -->
> [GW] it was intended to refer to mobile network radio links and mobile network core segments. These are covered in aggregate in section 7.2.   I've updated the XML to read:
> In particular, the application of NQB PHB to cable broadband links,
> Wi-Fi links, and mobile network radio/core segments are discussed in this document.
> 
> 
> 
> 5) <!--[rfced] We had a few questions related the following sentence.
> 
> 
> a) This sentence is long. May we break it up as follows?
> 
> 
> b) There is an inconsistency in capping for Differentiated Services
> with how it was used in the Abstract. We suggest simply using the
> abbreviation (as it already appears in the Abstract).
> 
> 
> c) We have updated to "have relatively low data rates". Please review
> that this captures your intended meaning.
> 
> 
> d) We have made a few other punctuation changes. Please review this
> text carefully.
> 
> 
> Original:
> This document defines a Differentiated Services per-hop behavior
> (PHB) called the "Non-Queue-Building Per-Hop Behavior" (NQB PHB),
> which isolates traffic microflows (application-to-application flows,
> see Section 1.2 of [RFC2475]) that are relatively low data rate and
> that do not themselves materially contribute to queuing delay and
> loss, allowing them to avoid the queuing delay and losses caused by
> other traffic.
> 
> 
> Perhaps:
> This document defines a Diffserv PHB called the "Non-Queue-Building
> Per-Hop Behavior" (or "NQB PHB"). The NQB PHB isolates traffic
> microflows (application-to-application flows, see Section 1.2 of
> [RFC2475]) that have relatively low data rates and that do not,
> themselves, materially contribute to queuing delay and loss. This
> isolation allows these traffic microflows to avoid the queuing
> delay and losses caused by other traffic.
> -->
> 
> [GW] Yes, fine & done.
> 
> 
> 6) <!--[rfced] We have attempted to break up the following sentence and
> clarify its intended meaning. Please review and confirm that this
> rewording maintains what you are trying to say (and if not,
> please submit a new rewording).
> 
> 
> Original:
> Such Non-Queue-Building microflows (for example:
> interactive voice, game sync packets, certain machine-to-machine
> applications, DNS lookups, and some real-time IoT analytics data) are
> low-data-rate application-limited microflows that are distinguished
> from bursty traffic microflows and high-data-rate traffic microflows
> managed by a classic congestion control algorithm, both of which
> cause queuing delay and loss.
> 
> 
> Current:
> Non-Queue-Building microflows such as interactive voice, game sync
> packets, certain machine-to-machine applications, DNS lookups, and
> some real-time Internet of Things (IoT) analytics data are
> low-data-rate, application-limited microflows. These can be
> distinguished from bursty traffic microflows and high-data-rate
> traffic microflows managed by a classic congestion control algorithm
> (both of which cause queuing delay and loss).
> -->
> 
> [GW] Yes, fine.
> 
> 
> 7) <!--[rfced] We had a few questions related to the example commonly
> deployed congestion control algorithms:
> 
> 
> a) We note that RFC 9438 uses "CUBIC" (not "Cubic"). Should this text
> be updated (along with other mentions throughout the text and the
> mentions in draft-briscoe-docsis-q-protection-07)?
> 
> 
> Original:
> ...such as Reno [RFC5681], Cubic [RFC9438] or BBR
> [I-D.ietf-ccwg-bbr],...
> 
> 
> Perhaps:
> ...such as Reno [RFC5681], CUBIC [RFC9438] or BBR [BBR-CC],...
> 
> 
> b) We note that RFC 5681 does not mention the word "Reno" in the body
> of the document. We do see it point to some Informative Reference
> entries on the topic (RFC 3782 and
> ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.) Please review and let us
> know if the pointer to RFC 5681 should be updated to something else.
> 
> 
> Original:
> ...congestion control algorithms, such as Reno [RFC5681],
> Cubic...
> -->
> 
> [GW] Yes, on "CUBIC".  RFC5681 is correct (other RFCs have used, for example (from 9438):
> "classical Reno congestion control [RFC5681]." ).
> 
> 
> 8) <!--[rfced] We have broken up this sentence and removed "in
> particular" as we were uncertain which part of the sentence it
> applied to. Please review to ensure we have maintained your
> intended meaning.
> 
> 
> Original:
> In contrast to applications that frequently cause queuing delay,
> there are a variety of relatively low data rate applications that do
> not materially contribute to queuing delay and loss but are
> nonetheless subjected to it by sharing the same bottleneck link in
> the access network, in particular.
> 
> 
> Current:
> In contrast to applications that frequently cause queuing delay, there
> are a variety of relatively low data rate applications that do not
> materially contribute to queuing delay and loss; nonetheless, they are
> subjected to it by sharing the same bottleneck link in the access
> network.
> -->
> 
> [GW] The "in particular" was referring to the phrase "in the access network".  For reference, the Abstract states: "The NQB PHB has been developed primarily for use by access network segments, where queuing delay and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments."  If we need to delete the words "in particular", I would then also delete the words "in the access network".
> 
> 
> 
> 
> 9) <!-- [rfced] We note that Section 6.6 appears to use the term
> "lower-rate" rather than "lower-speed" as indicated in the text
> below. Please let us know if/how to update.
> 
> 
> Original:
> The applicability of this PHB to lower-speed links is discussed in
> Section 6.6.
> -->
> 
> [GW] lower-rate is fine.
> 
> 
> 10) <!--[rfced] May we remove "and" from this sentence? That is, is
> PHB designed for broadband access network links that have buffers
> that are deep? Or is the last clause applicable to "minimal
> aggregation of traffic"?
> 
> 
> Original:
> This PHB is designed for broadband access network links, where there
> is minimal aggregation of traffic, and especially when buffers are
> deep (see Section 3.4).
> 
> 
> Perhaps A:
> This PHB is designed for broadband access network links, where there
> is minimal aggregation of traffic, especially when buffers are
> deep (see Section 3.4).
> 
> 
> Perhaps B:
> This PHB is designed for broadband access network links, where there
> is minimal aggregation of traffic (especially when buffers are
> deep (see Section 3.4)).
> -->
> 
> [GW] I think it would be better as:
> This PHB is designed for broadband access network links (where there
> is minimal aggregation of traffic), especially when buffers are
> deep (see Section 3.4).
> 
> 
> 11) <!-- [rfced] We see that [RFC2474] uses "DS" rather than "Diffserv"
> for "Differentiated Services". It also uses "codepoint" rather
> than "code point". Please review and let us know if/how to
> update uses in this document.
> 
> 
> Original:
> The architecture defines the use of the Diffserv field [RFC2474] for
> this purpose, and numerous RFCs have been written that describe
> recommended interpretations of the values (Diffserv Code Points
> [RFC2474]) of the field, and standardized treatments (traffic
> conditioning and per-hop-behaviors [RFC2475]) that can be implemented
> to satisfy the performance requirements of traffic so marked.
> -->
> 
> [GW] Please align the terminology with RFC2474:  "DS" instead of "Diffserv", "codepoint" instead of "code point".
> 
> 
> 
> 
> 12) <!--[rfced] Is there a way to avoid saying "treated..as treatment"?
> 
> 
> Original:
> In nodes that support multiple DiffServ Service Classes, NQB traffic
> is intended to be treated as a part of the Default treatment.
> 
> 
> Perhaps:
> In nodes that support multiple Diffserv Service Classes, NQB traffic
> is intended to be handled as a part of the Default treatment.
> -->
> 
> [GW] Yes, fine & done.
> 
> 
> 
> 13) <!--[rfced] Is there a way to rephrase to avoid so many uses of variants of
> "require"?
> 
> 
> Original:
> Note that these requirements in turn require compliance with all the
> requirements in Section 5 of [RFC9331].
> -->
> 
> [GW] Instead of "require", maybe "necessitate", "imply", "call for", or "involve"?
> 
> 
> 14) <!-- [rfced] We note that Section 4 of [RFC9331] uses the term
> "'Prague L4S Requirements'" rather than "L4S 'Prague'
> requirements". Please review and let us know if/how to update.
> 
> 
> Original:
> Applications that comply with both the NQB sender requirements in
> Section 4 and the L4S "Prague" requirements in Section 4 of [RFC9331]
> could mark their packets both with the NQB DSCP and with the ECT(1)
> value.
> -->
> 
> [GW] Changed to "Prague L4S Requirements"
> 
> 
> 
> 15) <!--[rfced] Does "around" mean "related to" in this text?
> 
> 
> Original:
> 
> 
> Microflows marked with the NQB DSCP are expected to comply with
> existing guidance for safe deployment on the Internet, including the
> guidance around response to network congestion, for example the
> requirements in [RFC8085] and Section 2 of [RFC3551] (also see the
> circuit breaker limits in Section 4.3 of [RFC8083] and the
> description of inelastic pseudowires in Section 4 of [RFC7893]).
> 
> 
> Perhaps:
> 
> 
> Microflows marked with the NQB DSCP are expected to comply with
> existing guidance for safe deployment on the Internet, including the
> guidance related to responses to network congestion, for example the
> requirements in [RFC8085] and Section 2 of [RFC3551] (also see the
> circuit breaker limits in Section 4.3 of [RFC8083] and the
> description of inelastic pseudowires in Section 4 of [RFC7893]).
> -->
> 
> [GW] Yes, fine & done.
> 
> 
> 16) <!--[rfced] Might breaking this text into a list be easier for the
> reader?
> 
> 
> Original:
> Thus, a useful property of nodes (i.e. network switches and
> routers) that support separate queues for NQB and QB microflows is
> that for microflows consistent with the NQB sender requirements in
> Section 4, the NQB queue would likely be a better choice than the QB
> queue; and for microflows inconsistent with those requirements, the QB
> queue would likely be a better choice than the NQB queue.
> 
> 
> Perhaps:
> Thus, a useful property for nodes (i.e., network switches and routers)
> that support separate queues for NQB and QB microflows would be to
> behave as follows:
> 
> 
> * for microflows consistent with the NQB sender requirements in
> Section 4, the NQB queue would likely be a better choice than
> the QB queue and
> 
> 
> * for microflows inconsistent with the requirements in Section 4,
> the QB queue would likely be a better choice than the NQB queue.
> -->
> 
> [GW] I personally prefer the original.
> 
> 
> 
> 16.5) <!-- We note that [RFC5685] uses "VOICE-ADMIT" rather than
>     "Voice-Admit". Please review and let us know if/how to update.
> 
> Original:
>   In the preceding sentence, "VA" and "CSx" refer to Voice-Admit
>   ([RFC5865]) and Class Selector ([RFC2474]) respectively.
> -->
> 
> [GW] Changed to "VOICE-ADMIT"
> 
> 
> 
> 17) <!--[rfced] Section 6.3: We thank you for the note at the end of this
> section about citing an obsoleted RFC. Is the note meant to
> remain in the document at publication? If so, may we put it in
> the <aside> element?
> 
> 
> Original:
> [NOTE: this section references the obsoleted RFC2598 instead of its
> replacement RFC3246, because the former contains the description of
> EF performance.]
> -->
> 
> 
> [GW] I think it is unnecessary to keep the NOTE.
> 
> 
> 
> 18) <!--[rfced] Perhaps it would be helpful to the reader to describe
> what part of RFC 8100 is being used here?
> 
> 
> Original:
> If [RFC8100] is operational between interconnected domains, the
> receiving domain may prefer a different DSCP for NQB traffic that
> allows for a DSCP range-based classification for the Default / Elastic
> Treatment Aggregate.
> -->
> 
> [GW] I will defer to Ruediger on this one.
> [RG] The reference or the sentence may refer to section 4 of RFC 8100, https://www.rfc-editor.org/rfc/rfc8100.html#section-4
> 
> 
> 19) <!-- [rfced] We note that Section 4 of [RFC2475] uses "Class Selector
> codepoint" rather than "Class Selector Codepoint". Please review
> and let us know if/how to update.
> 
> 
> Original:
> In such cases, Section 4 of [RFC2475] suggests that the upstream
> domain opportunistically re-mark traffic with a Class Selector
> codepoint or DSCP 0 (Default) under the assumption that traffic so
> marked would be handled in a predictable way by the downstream domain.
> -->
> 
> [GW] "Codepoint" is fine, done.
> 
> 
> 20) <!--[rfced] Note that we have changed IPSec to IPsec to match the
> following from RFC 4301:
> 
> 
> The spelling "IPsec" is preferred and used throughout this and all
> related IPsec standards. All other capitalizations of IPsec (e.g.,
> IPSEC, IPSec, ipsec) are deprecated.
> -->
> 
> 
> [GW] fine.
> 
> 
> 21) <!--[rfced] May we update as follows for the ease of the reader?
> Please review carefully to ensure we've maintained your intended
> meaning.
> 
> 
> Original:
> To support the NQB PHB, the mobile network could be configured to
> give User Equipment (UE, the mobile device used by the subscriber) a
> dedicated, low-latency, non-GBR (non-Guaranteed Bit Rate), EPS
> (Evolved Packet System, the core and access network architecture used
> in LTE) bearer, e.g., one with QCI 7 (QoS Class Identifier 7, which
> is typically used for low-latency, non-GBR services), in addition to
> the default EPS bearer.
> 
> 
> Perhaps:
> In addition to the default EPS bearer and to support the NQB PHB,
> the mobile network could be configured to give User Equipment (UE)
> (the mobile device used by the subscriber) a bearer that is
> a dedicated, low-latency, non-Guaranteed Bit Rate (non-GBR) Evolved
> Packet System (EPS) (the core and access network architecture used
> in LTE). For example, it could give a bearer with QCI 7 (QoS Class
> Identifier 7), which is typically used for low-latency, non-GBR
> services.
> 
> 
> -->
> 
> [GW] I agree that this sentence isn't an easy read.  I also note your comment 30a below relating to the term "bearer".  I've done a pass through this (with some help from AI) to rearrange the wording to see if we can clean it up.  I would appreciate review by Thomas that this text is concise and accurate.
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> 7.2 Mobile Networks
> Historically, 3GPP mobile networks have utilized "bearers" to encapsulate each user's user plane traffic through the radio access and core networks. Bearers are also associated with a Quality of Service (QoS) that determines how packets are prioritized at queues and radio schedulers. In LTE networks, these are EPS bearers, part of the Evolved Packet System (EPS), which comprises the core and access network architecture. Typically, an LTE operator provides a dedicated EPS bearer for IP Multimedia Subsystem (IMS) Voice over LTE (VoLTE) traffic to meet regulatory obligations for call completion rates, and a best-effort default EPS bearer for Internet traffic. This default EPS bearer is typically non-Guaranteed Bit Rate (non-GBR) and provides no guarantees; its buffering characteristics generally are not compatible with low-latency traffic. In 5G networks, similar functionality is provided using QoS flows within a PDU Session in the core network, which are mapped to Data Radio Bearers (DRBs) on the radio network. 5G systems offer more flexibility in QoS handling, allowing traffic to be treated according to type (e.g., loss-tolerant, low-latency); hence, they support more suitable treatment of Internet real-time microflows.
> 
> To support the NQB PHB, an LTE network could be configured to provide the User Equipment (UE, the subscriber's device) with a dedicated low-latency, non-GBR EPS bearer, in addition to the default EPS bearer. For example, this dedicated EPS bearer could use QCI 7 (QoS Class Identifier 7), which is typically used for low-latency, non-GBR services. Alternatively, in a 5G system, a Data Radio Bearer (DRB) with 5QI 7 (5G QoS Identifier 7, also used for low-latency traffic), could be provisioned (see Table 5.7.4-1: Standardized 5QI to QoS characteristics mapping in [SA-5G]).
> 
> A packet carrying the NQB DSCP could then be routed through this dedicated low-latency path, while packets without the NQB marking would be routed through the default bearer.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> 22) <!-- [rfced] Figure 1 in RFC 8325 has header information that might be
> helpful to the reader to include in the update in this document.
> Would you like us to add the header to the figure?
> 
> 
> Perhaps:
> +===============+======+==========+==================================+
> | IETF Diffserv | PHB |Reference | IEEE 802.11 |
> | Service Class | | RFC |User Priority| Access Category |
> |===============+======+==========+=============+====================|
> -->
> 
> [GW] Sure.
> 
> 
> 23) <!-- [rfced] FYI, for the [Custura] reference, we found a PDF for this
> article from the TMA website and added it. Please let us know if you
> have any objections.
> -->
> 
> [GW] Yes, fine.
> 
> 
> 24) <!-- [rfced] FYI, for the [Barik] reference, we found a PDF for
> this article from the International Teletraffic Congress (ITC) website
> (https://itc-conference.org/itc-library/itc30.html <https://itc-conference.org/itc-library/itc30.html>) and added it.
> -->
> 
> [GW] ok.
> 
> 
> 
> 
> 25) <!--[rfced] Please review the [SA-5G] reference entry. According to
> the URL, the most current version is 20.0.0. Should the
> reference entry be updated to point to that version? -->
> 
> [GW] Only if Table 5.7.4-1 is still:  Standardized 5QI to QoS characteristics mapping
> 
> 
> 
> 26) <!-- [rfced] Please review reference entry [IEEE802-11]. This
> reference points to a superseded version of IEEE Std 802.11 from
> 2020. The most current version is IEEE Std 802.11-2024. Would you
> like this reference to point to the most current version? -->
> 
> [GW] Yes, that’s fine.
> 
> 
> 27) <!-- [rfced] The date for the [TR-369] reference is January 2022;
> however, the URL for this reference points to a Broadband Forum
> specification with an issue date of July 2025.
> 
> 
> We have updated this reference to match the information provided at
> the URL. Please let us know if you have any objections.
> -->
> 
> [GW] Yes, that is fine.
> 
> 
> 
> 28) <!-- [rfced] The [Gettys2021] reference points to an article from
> the "Communications of the ACM"; however, the DOI provided for this
> reference (https://doi.org/10.1145/2063166.2071893 <https://doi.org/10.1145/2063166.2071893>) points
> to an article from "ACM Queue" with a different publication date.
> 
> 
> We updated this reference to point to the DOI for the "Communications
> of the ACM" version of this article (note that this version is also
> free access): https://dl.acm.org/doi/10.1145/2063176.2063196 <https://dl.acm.org/doi/10.1145/2063176.2063196>.
> -->
> 
> [GW] Yes, that is fine.
> 
> 
> 29) <!-- [rfced] Please review reference [Cardwell2017]. The author
> information provided for this reference did not match in the
> information at the URL. We have updated this reference to match
> what was available at the URL.
> 
> 
> Original:
> [Cardwell2017]
> Cardwell, N., Cheng, Y., Jacobson, V., Iyengar, J., Swett,
> I., and B. Yan, "BBR: Congestion-Based Congestion
> Control", Communications of the ACM Vol. 60, No. 2, pp.
> 58-66, DOI 10.1145/3009824, February 2017,
> <https://doi.org/10.1145/3009824> <https://doi.org/10.1145/3009824&gt;>.
> Current:
> [Cardwell2017]
> Cardwell, N., Cheng, Y., Gunn, C. S., Yeganeh, S. H., and
> V. Jacobson, "BBR: Congestion-Based Congestion Control",
> Communications of the ACM, vol. 60, no. 2, pp. 58-66,
> DOI 10.1145/3009824, February 2017,
> <https://doi.org/10.1145/3009824> <https://doi.org/10.1145/3009824&gt;>.
> -->
> 
> [GW] Yes, that is fine.
> 
> 
> 30) <!--[rfced] We had the following questions related to terminology used
> throughout the document:
> 
> 
> a) Please review how terms with bearer are treated in the Mobile
> Networks section. For instance, we see:
> 
> 
> "bearer"
> "dedicated bearer"
> "best effort" bearer
> "best effort" default bearer
> default EPS bearer
> Data Radio Bearer
> 
> 
> Should these be made more similar in terms of quotation and
> capitalization? If so, please let us know which forms are preferred.
> 
> [GW] See #21 above.
> 
> b) Please review the use of the following similar values:
> 
> 
> i) DSCP value 45 (decimal) vs. DSCP 45 (decimal) vs. DSCP 45
> 
> 
> May these be made consistently:
> 
> 
> DSCP value 45 (decimal)
> 
> 
> ii) NQB DSCP 45 (decimal) vs. NQB DSCP (45 decimal) vs. NQB (45)
> vs. NQB DSCP (45) vs. NQB (45) value
> 
> 
> May these be made consistently:
> 
> 
> NQB DSCP 45 (decimal)
> 
> 
> iii) 45 (decimal)
> 
> 
> Can you review these uses and let us know if they refer to i or ii above?
> 
> 
> [GW] These all refer to the same concept, and many (though not all) of them could be normalized. I found 31 instances, here is the accounting:
> 
>  10 NQB DSCP 45 (decimal)
>   6 DSCP value 45 (decimal)
>   5 DSCP 45 (decimal)
>   2 45 (decimal)
>   2 DSCP 45
>   1 NQB DSCP (45 decimal)
>   1 NQB DSCP (45)
>   1 NQB DSCP value 45
>   1 NQB (45)
>   1 Diffserv Code Point (DSCP) 45 (decimal)
>   1 DSCP value other than 45 (decimal)
> 
> Do you prefer "DSCP value 45 (decimal)" when that fits?
> 
> Here are the 31 occurences:
> 
> In accordance with this, applications are <bcp14>RECOMMENDED</bcp14> to use the Diffserv Code Point (DSCP) 45 (decimal) to mark microflows as NQB.
> 
> The choice of the DSCP value 45 (decimal) is motivated, in part, by the desire to achieve separate queuing in existing Wi-Fi networks (see <xref target="wifi"/>) and by the desire to make implementation of the PHB simpler in network equipment that has the ability to classify traffic based on ranges of DSCP values (see <xref target="aggregation2"/> for further discussion). </t>
> 
> <t>By default, a node supporting the NQB PHB <bcp14>SHOULD</bcp14> by classify packets marked with the NQB DSCP 45 (decimal) into the queue for Non-Queue-Building traffic.
> 
> The assigned NQB DSCP (45 decimal) is recommended for use as the default classifier to distinguish NQB traffic from traffic classified as Default (DSCP 0) (see Sections <xref target="sender" format="counter"/> and <xref target="primary" format="counter"/>).</t>
> 
> As noted in <xref target="sender"/>, the choice of the DSCP value 45 (decimal) is motivated in part by the desire to make this aggregation simpler in network equipment that can classify packets via comparing the DSCP value to a range of configured values.</t>
> 
> <t>If NQB support is extended across a DiffServ domain boundary, the interconnected networks agreeing to support NQB <bcp14>SHOULD</bcp14> use the DSCP value 45 (decimal) for NQB at network interconnection, unless a different DSCP is explicitly documented in the TCA (Traffic Conditioning Agreement, see <xref target="RFC2475"/>) for that interconnection.
> 
> Similar to the handling of DSCPs for other PHBs (and as discussed in <xref target="RFC2475"/>), networks can re-mark NQB traffic to a DSCP value other than 45 (decimal) for internal usage.
> 
> <t>In addition to the requirements provided in other sections of this document, to support the NQB PHB, Wi-Fi equipment (including equipment compliant with <xref target="RFC8325"/>) <bcp14>SHOULD</bcp14> map the NQB DSCP 45 (decimal) into a separate queue in the same Access Category as the queue that carries Default traffic (i.e., the Best Effort Access Category).
> 
> It is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment provide a separate queue in UP 0 and map the NQB DSCP 45 (decimal) to that queue.
> 
> If a separate queue in UP 0 cannot be provided (due to hardware limitations, etc.), a Wi-Fi device <bcp14>MAY</bcp14> map the NQB DSCP 45 (decimal) to UP 3.</t>
> 
> <t>The DSCP value 45 (decimal) is recommended for NQB (see <xref target="sender"/>).
> 
> The rationale for the choice of DSCP 45 (decimal) as well as its ramifications and remedies for its limitations are discussed further below.</t>
> 
> <li>Application instances on Wi-Fi client devices are already free to choose any Access Category that they wish, regardless of their sending behavior, without any policing of usage. So, the choice of using DSCP 45 (decimal) for NQB creates no new avenues for non-NQB-compliant client applications to exploit the prioritization function in Wi-Fi. </li>
> 
> <li>For application traffic that originates outside of the Wi-Fi network, and, thus, is transmitted by the Access Point, the choice of DSCP 45 does create a potential for abuse by non-compliant applications.  However, opportunities exist in the network components upstream of the Wi-Fi Access Point to police the usage of the NQB DSCP and potentially re-mark traffic that is considered non-compliant, as is recommended in <xref target="unmanaged"/>.
> 
> <t>As stated above, the use of DSCP 45 (decimal) for NQB is not expected to create incentives for abuse by non-compliant applications in the Wi-Fi uplink direction.
> 
> This conclusion is not expected to be disturbed by network support for NQB increasing the likelihood of DSCP 45 traffic traversing network boundaries without change to the DSCP, as that likelihood of increased network boundary traversal is balanced by a likelihood of NQB traffic encountering the traffic-limiting aspects of NQB support, traffic protection, and shallow buffers, which limit the potential for abuse.</t>
> 
> <t>Systems that utilize <xref target="RFC8325"/> but cannot provide a separate AC_BE queue for NQB traffic <bcp14>SHOULD</bcp14> map the NQB DSCP 45 (decimal) (or the locally determined alternative) to UP 5 in the "Video" Access Category as well (see <xref target="updates_to_8325"/>).</t>
> 
> <blockquote>RFC 9956 defines a shallow-buffered, best-effort service for traffic marked with the NQB DSCP 45 (decimal) and recommends the following treatment in Wi-Fi equipment.
> 
> It is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment map the NQB DSCP 45 (decimal) into a separate queue in the same Access Category as the queue that carries Default traffic (i.e., the Best Effort Access Category).
> 
> It is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment provide a separate queue in UP 0 and map the NQB DSCP 45 (decimal) to that queue.
> 
> If a separate queue in UP 0 cannot be provided (due to hardware limitations, etc.), a Wi-Fi device <bcp14>MAY</bcp14> map the NQB DSCP 45 (decimal) to UP 3. If neither of these options provides a separate queue from Default traffic, it is <bcp14>RECOMMENDED</bcp14> that Wi-Fi equipment map the NQB DSCP 45 (decimal) to UP 5
> 
> <blockquote>An exception to this is the NQB DSCP 45 (decimal), which encodes for best-effort service.</blockquote>
> 
> <t>IANA has assigned the Differentiated Services Field Codepoint (DSCP) 45 from the "Differentiated Services Field Codepoints (DSCP)" registry (<eref target="https://www.iana.org/assignments/dscp-registry/%22/>) ("DSCP Pool 3 Codepoints", Codepoint Space xxxx01, Standards Action (<xref target="RFC8126" format="default"/>) for Non-Queue-Building behavior.</t>
> 
> These existing Wi-Fi networks currently provide priority to half of the DSCP space, whether or not 45 (decimal) is assigned to the NQB DSCP.
> 
> <t>Regarding the DSCP value 45 (decimal), there were no observations of DSCP manipulation reported in which traffic was marked 45 (decimal) by any of these policies.
> 
> Thus, it appears that these re-marking policies would be unlikely to result in QB traffic being marked as NQB (45).
> 
> <t>In the policies where the top three bits are overwritten (see <xref target="RFC9435" section="4.2"/>), the NQB DSCP (45) would receive the same marking as would the currently unassigned Pool 3 DSCPs (5, 13, 21, 29, 37, 53, and 61), with all of these DSCPs getting re-marked to DSCP = 5, 13, or 21 (depending on the overwrite value used).
> 
> If networks in which this sort of re-marking occurs or networks downstream classify the resulting DSCP (i.e., 5, 13, or 21) to the NQB PHB or re-mark such traffic as 45 (decimal), they risk giving NQB treatment to other traffic that was not originally marked as NQB.
> 
> <t>For the policy in which the low three bits are set to 0b000, the NQB DSCP value 45 (decimal) would be re-marked to CS5 and would be indistinguishable from CS5, VA, and EF (and the currently unassigned DSCPs 41, 42, and 43).
> 
> <t>In networks where the DSCP 45 (decimal) is already in use for another (e.g., a local-use) purpose or where specialized PHBs are available that can meet specific application requirements (e.g., a guaranteed-delay path for voice traffic), use of another DSCP value could be preferred.</t>
> 
> <t>In end systems where the choice of using DSCP 45 (decimal) is not available to the application, the CS5 DSCP (40 decimal) could be used as a fallback.
> 
> [GW] I've made no changes on this yet. If you can confirm the preferred terminology, I will review each instance and check whether it works.
> 
> 
> iv) May we treat other DSCP numbers similarly? Some examples:
> 
> 
> Current:
> ...DSCPs 41, 42, 43).
> 
> 
> Perhaps:
> ...DSCP values 41, 42, and 43 (all decimal)).
> 
> [GW] Yes.
> 
> 
> Current:
> ...CS5 DSCP (40 decimal)
> 
> 
> Perhaps:
> ... CS5 DSCP value 40 (decimal)
> 
> [GW] Yes.
> 
> c) Please review these similar uses for consistency:
> 
> 
> classic congestion control algorithm
> "classic congestion control" (capped because introducing a term)
> 
> 
> In the companion document (draft-briscoe-docsis-q-protection-07), we see:
> 
> 
> 'Classic" congestion control (and 'Scalable' congestion control)
> Classic queue
> Classic traffic
> classic congestion controllers
> 
> 
> Should these be made more consistent within the cluster?
> 
> [GW] In this document, the term is used as it was defined in RFC9330 (which it references). For draft-briscoe-docsis-q-protection-07, it would be worth reviewing those instances to see if they could be made more consistent with this document and with RFC9330.
> 
> 
> 
> Further, is the Classic queue the same as the Default queue? Or are these different things?
> 
> [GW] They are slightly different, but overlapping ideas.  There are some related features in these three documents that discuss DualQ networking:
> A.  L4S DualQ Coupled AQM (RFC9332) [defines "L4S queue" (aka "L queue", aka "low-latency queue") and "Classic queue" (aka "C queue")]
> B.  NQB PHB (this document) [defines "NQB queue" and "Default queue"]
> C. QProt (draft-briscoe-docsis-q-protection-07) [uses "L4S queue"/"L queue" and "Classic queue"/"C queue"]
> A particular piece of network equipment could support A and/or B, and optionally C. If it supports both A & B, then the L queue and the NQB queue can be one and the same, similarly the C queue and the Default queue can be one and the same (this is discussed a bit in section 2.3 of RFC9332, in section 3.3 of this document, and in section 3 of QProt).
> The DOCSIS Specification that was the source material for QProt, was drafted to describe a system that supports all 3, and it adopted the terminology of RFC 9332 (or perhaps the early drafts that became RFC9332).
> The NQB PHB draft was drafted to be separable from the L4S functionality, so used distinct terms NQB queue and Default queue (where Default is a term from RFC 2474).
> 
> 
> 
> d) We several uses like the following:
> 
> 
> Original:
> ...that are relatively low data rate...
> 
> 
> ...be relatively low data rate...
> 
> 
> Where we would have expected "have a relatively low data rate". May
> we update these as such?
> 
> [GW] Yes.
> 
> [GW] In addition, in Appendix A, I see:  " the same general properties as NQB traffic (non-capacity-seeking and very low data rate, relatively low data rate, and consistent data rate).", which probably looks strange to a reader.  The descriptions inside the parentheses were intended to map directly to the list "CS5, VA, and EF" one-for-one.
> So perhaps:
> " the same general properties as NQB traffic (non-capacity-seeking and very low data rate, relatively low data rate, and consistent data rate, respectively)."
> Or:
> " the same general properties as NQB traffic (non-capacity-seeking and very low data rate for CS5, relatively low data rate for VA, and consistent data rate for EF)."
> 
> 
> e) Please let us know if the following terms should be made consistent
> and if so which of the following forms is preferred with relation to
> capitalization, quotation, spelling, etc.
> 
> 
> Note: "Diffserv" (rather than "DiffServ") is preferred, as noted
> on the Terms list (https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms <https://www.rfc-editor.org/rpc/wiki/doku.php?id=terms>).
> 
> 
> Best Effort Access Category vs. "Best Effort" Access Category
> (see also best-effort service
> [GW] Yes, done. For consistency, I also removed quotation marks from "Video" Access Category.
> 
> Default vs. default
> [GW] These are correct in the document as written, and used in a consistent manner as in RFC2474.
> 
> differentiated service class vs. DiffServ Service Classes
> [GW] correct as written.
> 
> differentiated services vs. Differentiated Services
> [GW] done.
> 
> Diffserv Domain vs. DiffServ domain vs. Diffserv domain
> [GW] I'm unsure.  RFC2474 defines "Differentiated Services Domain", but then uses "DS domain" throughout.
> 
> Field vs. field (when describing Diffserv or DSCP)
> [GW] RFC 2474 seems to use "DS field"
> 
> higher-than-necessary vs. higher-than-needed
> [GW] done.
> 
> low data rate applications vs. low-rate applications
> [GW] I see no instances of the latter.
> 
> quality of experience vs. Quality of Experience
> [GW] done
> 
> Video Access Category vs. "Video" Access Category
> [GW] done, see above.
> 
> f) We'd like to add hyphens to these terms, so they would appear as
> follows. Please let us know if this is acceptable.
> 
> 
> delay-sensitive applications / traffic
> high-capacity interior nodes
> low-data-rate microflow / application
> low-delay performance / variation services
> low-latency queue (both forms are used in RFCs 9330-9332)
> rate-shaped capacity
> rate-shaping function
> -->
> [GW] all are ok, except "low-delay variation services".   That one should be "low-delay-variation services" (low modifies variation which modifies delay).
> 
> 
> 
> 31) <!-- [rfced] We had the following comments/questions related to
> abbreviation use throughout the document:
> 
> 
> a) We have added expansions for abbreviations upon first use per
> Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness.
> 
> 
> b) How may we expand the following abbreviations on first use?
> 
> 
> CE
> AS
> 
> [GW] CE = Congestion Experienced; AS appears once but is practically a lexicalized initialism in the IETF, so I wouldn't replace it with "Autonomous System".
> 
> c) FYI - We will remove expansions (i.e., use the abbreviation) for
> instances of the expanded form of abbreviations on uses subsequent to
> initial expansion for the following (per the guidance at
> https://www.rfc-editor.org/styleguide/part2/#exp_abbrev <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>):
> 
> 
> NQB
> QB
> DSCP
> TCA
> CS
> QoS
> EDCA
> EF
> -->
> 
> [GW] ok.
> 
> 
> 32) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language&gt;>
> and let us know if any changes are needed. Updates of this nature typically
> result in more precise language, which is helpful for readers.
> 
> 
> Note that our script did not flag any words in particular, but this
> should still be reviewed as a best practice.
> 
> 
> 
> 
> In addition, please consider whether "traditional" and "traditionally"
> should be updated for clarity. While the NIST website
> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1&gt;>
> indicates that this term is potentially biased, it is also ambiguous.
> "Tradition" is a subjective term, as it is not the same for everyone.
> -->
> 
> [GW] The first instance: "has traditionally been defined." can be replaced by "has previously been defined."
> The second instance: "a more traditional Traffic Conditioning approach and police the application of the NQB DSCP" can be replaced by "a Traffic Conditioning approach that polices the application of the NQB DSCP"
> 
> 
> 
> Thank you.
> 
> 
> Megan Ferguson and Alice Russo
> RFC Production Center
> 
> 
> 
> 
> On Apr 6, 2026, [e-mail] <mailto:[e-mail]> wrote:
> 
> 
> *****IMPORTANT*****
> 
> 
> Updated 2026/04/06
> 
> 
> RFC Author(s):
> --------------
> 
> 
> Instructions for Completing AUTH48
> 
> 
> Your document has now entered AUTH48. Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/ <https://www.rfc-editor.org/faq/>).
> 
> 
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
> 
> 
> Planning your review
> ---------------------
> 
> 
> Please review the following aspects of your document:
> 
> 
> * RFC Editor questions
> 
> 
> Please review and resolve any questions raised by the RFC Editor
> that have been included in the XML file as comments marked as
> follows:
> 
> 
> <!-- [rfced] ... -->
> 
> 
> These questions will also be sent in a subsequent email.
> 
> 
> * Changes submitted by coauthors
> 
> 
> Please ensure that you review any changes submitted by your
> coauthors. We assume that if you do not speak up that you
> agree to changes submitted by your coauthors.
> 
> 
> * Content
> 
> 
> Please review the full content of the document, as this cannot
> change once the RFC is published. Please pay particular attention to:
> - IANA considerations updates (if applicable)
> - contact information
> - references
> 
> 
> * Copyright notices and legends
> 
> 
> Please review the copyright notice and legends as defined in
> RFC 5378 and the Trust Legal Provisions
> (TLP – https://trustee.ietf.org/license-info <https://trustee.ietf.org/license-info>).
> 
> 
> * Semantic markup
> 
> 
> Please review the markup in the XML file to ensure that elements of
> content are correctly tagged. For example, ensure that <sourcecode>
> and <artwork> are set correctly. See details at
> <https://authors.ietf.org/rfcxml-vocabulary> <https://authors.ietf.org/rfcxml-vocabulary&gt;>.
> 
> 
> * Formatted output
> 
> 
> Please review the PDF, HTML, and TXT files to ensure that the
> formatted output, as generated from the markup in the XML file, is
> reasonable. Please note that the TXT will have formatting
> limitations compared to the PDF and HTML.
> 
> 
> 
> 
> Submitting changes
> ------------------
> 
> 
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
> 
> 
> * your coauthors
> 
> 
> * [e-mail] <mailto:[e-mail]> (the RPC team)
> 
> 
> * other document participants, depending on the stream (e.g.,
> IETF Stream participants are your working group chairs, the
> responsible ADs, and the document shepherd).
> 
> 
> * [e-mail] <mailto:[e-mail]>, which is a new archival mailing list
> to preserve AUTH48 conversations; it is not an active discussion
> list:
> 
> 
> * More info:
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc <https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc>
> 
> 
> * The archive itself:
> https://mailarchive.ietf.org/arch/browse/auth48archive/ <https://mailarchive.ietf.org/arch/browse/auth48archive/>
> 
> 
> * Note: If only absolutely necessary, you may temporarily opt out
> of the archiving of messages (e.g., to discuss a sensitive matter).
> If needed, please add a note at the top of the message that you
> have dropped the address. When the discussion is concluded,
> [e-mail] <mailto:[e-mail]> will be re-added to the CC list and
> its addition will be noted at the top of the message.
> 
> 
> You may submit your changes in one of two ways:
> 
> 
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
> 
> 
> Section # (or indicate Global)
> 
> 
> OLD:
> old text
> 
> 
> NEW:
> new text
> 
> 
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
> 
> 
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes. Information about stream managers can be found in
> the FAQ. Editorial changes do not require approval from a stream manager.
> 
> 
> 
> 
> Approving for publication
> --------------------------
> 
> 
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication. Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
> 
> 
> 
> 
> Files
> -----
> 
> 
> The files are available here:
> https://www.rfc-editor.org/authors/rfc9956.xml <https://www.rfc-editor.org/authors/rfc9956.xml>
> https://www.rfc-editor.org/authors/rfc9956.html <https://www.rfc-editor.org/authors/rfc9956.html>
> https://www.rfc-editor.org/authors/rfc9956.pdf <https://www.rfc-editor.org/authors/rfc9956.pdf>
> https://www.rfc-editor.org/authors/rfc9956.txt <https://www.rfc-editor.org/authors/rfc9956.txt>
> 
> 
> Diff file of the text:
> https://www.rfc-editor.org/authors/rfc9956-diff.html <https://www.rfc-editor.org/authors/rfc9956-diff.html>
> https://www.rfc-editor.org/authors/rfc9956-rfcdiff.html <https://www.rfc-editor.org/authors/rfc9956-rfcdiff.html> (side by side)
> 
> 
> Diff of the XML:
> https://www.rfc-editor.org/authors/rfc9956-xmldiff1.html <https://www.rfc-editor.org/authors/rfc9956-xmldiff1.html>
> 
> 
> 
> 
> Tracking progress
> -----------------
> 
> 
> The details of the AUTH48 status of your document are here:
> https://www.rfc-editor.org/auth48/rfc9956 <https://www.rfc-editor.org/auth48/rfc9956>
> 
> 
> Please let us know if you have any questions.
> 
> 
> Thank you for your cooperation,
> 
> 
> RFC Editor
> 
> 
> --------------------------------------
> RFC9956 (draft-ietf-tsvwg-nqb-33)
> 
> 
> Title : A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
> Author(s) : G. White, T. Fossati, R. Geib
> WG Chair(s) : Martin Duke, Zaheduzzaman Sarker
> Area Director(s) : Gorry Fairhurst, Mike Bishop
> 
> 
>