A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services
draft-ietf-tsvwg-nqb-33

[Ballot comment]
Thanks for addressing my previous DISCUSS issue and many of my COMMENT points.

For archive: https://mailarchive.ietf.org/arch/msg/tsvwg/hA1lxiGldJ7dtzp7x4aFT5zGm78/

Let me repeat the thanks to the authors and to the shepherd (Zahed) for an interesting piece of work.

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-tsvwg-nqb-30
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tsvwg-nqb-30.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## No Objection

I have no objections to the publication of this document as an RFC.

Many thanks to Robert Sparks for his ARTART review.

[Ballot comment]
Several abbreviations are used in this document without expansion or definition, or where the definition/expansion occurs later in the document. For example, "EF" is used in 6.3 without expansion or reference. Section 10 contains the reference to RFC3246, but the expansion to Expedited Forwarding isn't until Appendix B. (There is also a definition in RFC 4594, which is referenced in 6.3, but it's not clear from the text that the definition of these abbreviations can be found there.) DSCP is expanded in the abstract and again mid-way through Section 4, but used in abbreviated form throughout Section 1 and the preceding paragraphs of Section 4. The same could be said for VA, MSB, CSx, etc. and the equivalence between "Diffserv" and "Differentiated Services."

The use of "gear" rather than "equipment" feels at odds with the otherwise formal tone of the specification, but that's a stylistic choice.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-tsvwg-nqb-30
CC @evyncke

Thank you for the work put into this document.

Please find below one blocking DISCUSS point (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Zaheduzzaman Sarker for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 4

Unsure how to parse `R * T + 1 MTU` ? In which unit is the MTU ? is it (R * T) + MTU (my guess) ? or (R * T) + 1 + MTU ? or R * (T + MTU) or ???

This is somehow unclear and it should not be so in a proposed standard.

[Ballot comment]

## COMMENTS (non-blocking)

### Section 3.3

How can this I-D specify the behavior described in another document RFC 9330 without formally updating RFC 9330 ? `the L4S network functions SHOULD treat packets marked with the NQB DSCP ` ?

As a comment (no need to reply), I wonder how can the IETF TSVWG specify two PHBs (NQB & L4S) for the same use case without clear guidance for end-users/implementers (if I read this correctly in the access network mainly from residential to the core of Internet).

### Section 4

How can an application discover the R for `if a microflow's traffic exceeds the rate equation provided in the first paragraph of this section` ?

### Section 5.1

Should there be a reference for the value of 10 ms in `It is RECOMMENDED to configure an NQB buffer size less than or equal to 10 ms at the shared NQB/Default egress rate.`?

`EDCA` is only expanded in section 7.3, please expand it here or provide a forward reference.

### Section 5.2

Should there be some operational considerations about metering all flows (I guess per source or by 5-tuple) to protect the traffic ? Will this require too many states in forwarders ?

### Section 5.3

About `250 us burst duration for links within the public Internet`

Please use "250 µs" as documents support non-ASCII character sets.

Also, I do not think that 250 µs represents 10% of average global Internet RTT, this would be 2.5 msec. Suggest to rephrase the sentence.

### Section 6.1

`as Default (DSCP 0) is recommended to be the assigned NQB DSCP (45 decimal)` does not parse well, "NQB traffic is recommended to be ..." would parse better.

### Sections 7.2 and 7.3

Were 'for information' liaison statements sent to 3GPP & IEEE 802.11 ?

[Ballot discuss]
** Section 6.2
  Networks and nodes that do not support the NQB PHB ought to only
  classify packets with the NQB DSCP value into the appropriate
  treatment aggregate, or encapsulate such packets for purposes of
  aggregation, and SHOULD NOT re-mark them with a different DSCP.  This
  preservation of the NQB DSCP value enables hops further along the
  path to provide the NQB PHB successfully.  This aligns with
  recommendations in [RFC5127].

The intent of this specification appears to be describing the normative behavior for NQB PHB for DiffServ.  However, the text above appears to be providing normative guidance to “networks and nodes that do not support NQB PHB”.  If those network elements never intended to be conformant to NQB PHB, how can this document impose behavior on them?  Is this document intended to provide guidance to all DiffServ implementations?

The alignment to the recommendations in RFC5127 appears to be from Section 4.1.3 (of RFC5127), “In addition, the class selector DSCP value should not be changed.”  Is this informational status document mandatory to implement for DiffServ implementations?  If not, then relying on it to motivate particular behavior seems challenging.

** Section 8
  This document requests that IANA assign the Differentiated Services
  Field Codepoint (DSCP) 45 ('0b101101', 0x2D) from the "Differentiated
  Services Field Codepoints (DSCP)" registry
  (https://www.iana.org/assignments/dscp-registry/) ("DSCP Pool 3
  Codepoints", Codepoint Space xxxx01, Standards Action) as the
  RECOMMENDED codepoint for Non-Queue-Building behavior.

What does the normative phrase “… as the RECOMMENDED codepoint for …” mean in the context of an IANA action.  There is no preference information reflected in the registry.

[Ballot comment]
Thank you to Vijay Gurbani for the GENART review.

** Section 5.2
  To prevent this situation from harming the performance of the
  microflows that comply with the requirements in Section 4, network
  elements that support the NQB PHB SHOULD support a "traffic
  protection" function that can identify microflows or packets that are
  inconsistent with the sender requirements in Section 4, and either
  reclassify those microflows/packets to the QB queue or discard the
  offending traffic.
…
  This is the
  motivation for the "SHOULD" requirement to support traffic protection
  (in the previous paragraph).  An NQB PHB implementation that does not
  support traffic protection risks being limited to deployment
  situations where traffic protection is potentially not necessary.

When is it acceptable for a NQB PHB NOT to support a “traffic protection” function?  Isn’t this critical to the approach?

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

I have one question about the (lack of discussion of) impact of this new DiffServ codepoint behavior to MPLS. Specifically whether or not the mapping from NQB codepoint to the MPLS EXP would be done properly per RFC3270 or if something more/different is needed. Given that MPLS is an IETF technology, I would expect that this document at least covers some discussion (operational consideration?) of this topic.

I contemplated if this would be a DISCUSS criteria, but sharing this as a comment instead as I am not a QOS expert and leaving this to the responsible AD's judgement.

I also have the same question as Med if the liaisons were sent to IEEE 802.1, 3GPP and other SDOs that need to be made aware of this work at the IETF and to get their inputs.

[Ballot comment]
Hi Greg, Thomas, and Ruediger,

Thank you for the effort put into this interesting piece of work. I strongly support the direction of this work.

Thanks to Giuseppe Fioccola for the OPSDIR review and to Greg for engaging and structuring “Operational Considerations” content.

Please find below some comments, fwiw:

# Other SDOs

The document cites many SDOs and includes a discussion about how the mapping is supposed to be undertaken for technologies not owned by the IETF. I wonder whether LSes were sent to these SDOs to seek for their review of these parts?

If not done, I suggest we do so.

# (abstract) NQ or NQB?

OLD:
  In particular, the
  application of NQ PHB to cable broadband links, Wi-Fi links, and
                  ^^^^^^
  mobile network radio and core segments are discussed. 

NEW:
  In particular, the
  application of NQB PHB to cable broadband links, Wi-Fi links, and
  mobile network radio and core segments are discussed. 

# Terminology

We do say the following in the introduction:

  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 [RFC2475]) that are relatively low data rate and that do not

I think that it is better to cite rfc2475#section-1.2.

As a general note, consider pointing readers to that terminology list.

# Applicable to access network, but not only

I suggest to make the following change to not exclude other segments where bottleneck may be experienced as well (interco, for example).

OLD:
  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.

NEW:
  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. 
 
# Applicability

CURRENT:
  This PHB is designed
  for broadband access network links, where there is minimal
  aggregation of traffic, and especially when buffers are deep. 

Please point to Section 3.4 where applicability is discussed with more details.

# NQB DSCP

CURRENT:
  To be clear, a network implementing the NQB PHB solely provides
  isolation for traffic classified as behaving in conformance with the
  NQB DSCP. 

Not introduced yet. Maybe add a pointer to the section that defines that DSCP?

# Regulation

CURRENT:
  Finally, some jurisdictions impose regulations that limit the ability
  of networks to provide differentiation of services, in large part
  this seems to be based on the belief that doing so necessarily
  involves prioritization or privileged access to network capacity, and
  thus a benefit to one class of traffic always comes at the expense of
  another.

Why is this mentioned here? How does this impact this spec?

Also, when that point is linked to

  In contrast, the NQB PHB has been designed with the goal that it
  avoids many of these issues, and thus could conceivably be deployed
  across the Internet. 

I don’t see how this is different from any other PHB (for example, the regulation point).

# Jitter & Cie

CURRENT:
  Instead, the sole
  goal of the NQB PHB is to isolate NQB traffic from other traffic that
  degrades loss, latency, and jitter performance, given that the NQB
  traffic is itself only an insignificant contributor to those
  degradations. 

Many words for the same thing (e.g., Latency variation, jitter). Unless there are subtle differences assumed by the author, please use a consistent term here. I have a preference of IPPM terms (delay variation) to be aligned with the IETF terminology.

# Access control & trust

CURRENT:
  In this context, the NQB
  PHB provides a better network environment for applications that send
  data at relatively low and non-bursty data rates.

Still the network decides which flows to bind to a PHB, right?

How the new PHB changes the trust practices out there? How classification will be done?

# Not L4S specific (Section 3.3)

CURRENT:
  NQB network functions MUST treat packets marked with the NQB DSCP
  uniformly, regardless of the value of the ECN field.  Here, NQB
  network functions refers to the traffic protection function (defined
  in Section 5.2) and any re-marking/traffic policing function designed
  to protect unmanaged networks (as described in Section 6.4.1).

## What is meant by “NQB network function”?

## I think this behavior is independent of the use of L4S. If so, is this the right place to have this recommendation? I would move this till the PHB is defined first.

# Eligible flows

Section 4 says:
  Microflows that are eligible to be marked with the NQB DSCP are ones
  that send non-bursty traffic at a low data rate relative to typical
  network path capacities. 

How these are identified and who decides these meet the conditions? Is this a local application choice? A provisioning action?

# Marking bidirectionality

Section 4 states:
  Microflows marked with the NQB DSCP are expected to comply with
  existing guidance for safe deployment on the Internet,

As this reasons about “microflow”, is there a bidirectionality need/assumptions? That is, do packets in both directions need to have the same marking?

I’m asking this question because some deployments uses a model where the marking from the host-to-the network is inherited from the marking set in network-to-host direction.

# Primary Requirements

I would rename Section 5.1 to “Provisioning Requirements”

# Per user or per subscriber?

Section 5.1 says:

  To prevent propagation of degradation of service for NQB traffic
  caused by potential mis-marking of QB traffic, network equipment that
  supports this PHB and handles traffic for multiple users (e.g.,
  subscribers) SHOULD support provisioning of capacity and related
  forwarding resources on a per-user (e.g., subscriber) basis and
  SHOULD support enforcement of the resulting per-user limits on the
  aggregate of NQB and QB traffic for each user. 

I guess this is per subscriber. Multiple users may share the same subscription.

At least, you should define “user”.

# Policy

Section 5.2 says:
  In the case of a traffic protection algorithm
  that reclassifies offending traffic, the implementation MAY
  additionally re-mark such traffic to Default (or possibly to another
  local use code point) so that the result of the traffic protection
  decision can be used by further hops.  This sort of re-marking could
  provide a limited layer of protection in situations where downstream
  network nodes support separate queuing for NQB marked packets but
  lack support for traffic protection.

This behavior should be policy-based.

# Application-layer constructs might be useful in some cases, however relying on them exclusively should not be recommended

I suggest to make this change in Section 5.2

OLD:
  The traffic protection function SHOULD NOT base its decisions upon
  application-layer constructs (such as the port number used by the
  application or the source/destination IP address).  Instead, it ought
  to base its decisions on the actual behavior of each microflow (i.e.
  the pattern of packet arrivals).

NEW:
  The traffic protection function SHOULD NOT base its decisions solely upon
                                                                ^^^^^^
  application-layer constructs (such as the port number used by the
  application or the source/destination IP address).  Instead, it ought
  to base its decisions on the actual behavior of each microflow (i.e.,
  the pattern of packet arrivals).

# Resource exhaustion

Section 5.2 says:

CURRENT:
  The traffic protection function described here might require that the
  network element maintains microflow state.  The traffic protection
  function MUST be designed such that the node implementing the NQB PHB
  does not fail (e.g. crash) in the case that the microflow state is
  exhausted.

Which is great… but can we be more explicit how to do that? For example, can we say “control/limit the resources dedicated to tracking misbehaving flows”?

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tsvwg-nqb-29. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the DSCP Pool 3 Codepoints registry in the Differentiated Services Field Codepoints (DSCP) registry group located at:

https://www.iana.org/assignments/dscp-registry/

the early allocation for:

Name: NQB
Value (Binary): 101101
Value: (Decimal): 45

will be made permanent and its reference changed to [ RFC-to-be ].

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-06-18):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tsvwg-nqb@ietf.org, gorry@erg.abdn.ac.uk, tsvwg-chairs@ietf.org, tsvwg@ietf.org, zahed.sarker.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Non-Queue-Building Per-Hop Behavior (NQB PHB) for Differentiated Services) to Proposed Standard


The IESG has received a request from the Transport and Services Working Group
WG (tsvwg) to consider the following document: - 'A Non-Queue-Building
Per-Hop Behavior (NQB PHB) for Differentiated
  Services'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-06-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies characteristics of a Non-Queue-Building Per-
  Hop Behavior (NQB PHB).  The NQB PHB provides a shallow-buffered,
  best-effort service as a complement to a Default deep-buffered best-
  effort service for Internet services.  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 latency, latency variation and loss caused by such traffic.
  This PHB is implemented without prioritization and can be implemented
  without rate policing, making it suitable for environments where the
  use of these features is restricted.  The NQB PHB has been developed
  primarily for use by access network segments, where queuing delays
  and queuing loss caused by Queue-Building protocols are manifested,
  but its use is not limited to such segments.  In particular,
  applications to cable broadband links, Wi-Fi links, and mobile
  network radio and core segments are discussed.  This document
  recommends a specific Differentiated Services Code Point (DSCP) to
  identify Non-Queue-Building microflows, and updates the RFC8325
  guidance on mapping Diffserv to IEEE 802.11 for this codepoint.

  [NOTE (to be removed by RFC-Editor): This document references an ISE
  submission draft (I-D.briscoe-docsis-q-protection) that is approved
  for publication as an RFC.  This draft should be held for publication
  until the queue protection RFC can be referenced.]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was broad agreement on developing this work within the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This document defines a PHB and allocates a DSCP. The choice of allocated DSCP
was considered by the WG over many meetings and there was rough consensus on
the use of the chosen DS codepoint (45).

There were objections during the WGLC from people who believed the support for
legacy equipment had not been addressed and there was a need for greater
traffic protection, or a change in the allocated DSCP. The document
was revised to include more explanation, however, one person was not
content with the final text, noting their continued concerns about the
potential impact on deployed equipment that does not comply with the new spec.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. This document defines a new PHB, to complete this the WG needed to
agree to allocate a DSCP, determine the conditioning required and assess
the expected path to deployment. It has been reviewed in several rounds
by the WG.  This involved considerable review from various people.
There was a first WGLC in 2022-11-02, a second WGLC in 2023-02-22
and a final WGLC in 2024-05-20.  All resulted in changes as the document
converged on the final form. A consensus call on the final text was
issued in 2024-10-22 with only one remaining objection to the DSCP
chosen. The document received detailed shepherd reviews
after the second and final call.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, and all authors have confirmed their disclosure obligations to the Chairs.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID NiTs has been checked. NOTE: A section references the obsoleted
RFC2598 instead of its replacement RFC3246, because the former
contains the description of EF performance.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. All have been checked.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates: RFC 8325.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has been reviewed by the Shepherd and this is ready for publication.
The IANA action is clear, and early allocation was requested after WGLC.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?

No new IANA registry is required, but an IANA allocation is requested.

    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was broad agreement on developing this work within the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This document defines a PHB and allocates a DSCP. The choice of allocated DSCP
was considered by the WG over many meetings and there was rough consensus on
the use of the chosen DS codepoint (45).

There were objections during the WGLC from people who believed the support for
legacy equipment had not been addressed and there was a need for greater
traffic protection, or a change in the allocated DSCP. The document
was revised to include more explanation, however, one person was not
content with the final text, noting their continued concerns about the
potential impact on deployed equipment that does not comply with the new spec.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. This document defines a new PHB, to complete this the WG needed to
agree to allocate a DSCP, determine the conditioning required and assess
the expected path to deployment. It has been reviewed in several rounds
by the WG.  This involved considerable review from various people.
There was a first WGLC in 2022-11-02, a second WGLC in 2023-02-22
and a final WGLC in 2024-05-20.  All resulted in changes as the document
converged on the final form. A consensus call on the final text was
issued in 2024-10-22 with only one remaining objection to the DSCP
chosen. The document received detailed shepherd reviews
after the second and final call.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, and all authors have confirmed their disclosure obligations to the Chairs.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID NiTs has been checked. NOTE: A section references the obsoleted
RFC2598 instead of its replacement RFC3246, because the former
contains the description of EF performance.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. All have been checked.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates: RFC 8325.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has been reviewed by the Shepherd and this is ready for publication.
The IANA action is clear, and early allocation was requested after WGLC.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?

No new IANA registry is required, but an IANA allocation is requested.

    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was broad agreement on developing this work within the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This document defines a PHB and allocates a DSCP. The choice of allocated DSCP
was considered by the WG over many meetings and there was rough consensus on
the use of the chosen DS codepoint (45).

There were objections during the WGLC from people who believed the support for
legacy equipment had not been addressed and there was a need for greater
traffic protection, or a change in the allocated DSCP. The document
was revised to include more explanation, however, a small number were not
content with the final text, noting their continued concerns about the
potential impact on deployed equipment that does not comply with the new spec.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. This document defines a new PHB, to complete this the WG needed to
agree to allocate a DSCP, determine the conditioning required and assess
the expected path to deployment. It has been reviewed in several rounds
by the WG.  This involved considerable review from various people.
There was a first WGLC in 2022-11-02, a second WGLC in 2023-02-22
and a final WGLC in 2024-05-20.  All resulted in changes as the document
converged on the final form. A consensus call on the final text was
issued in 2024-10-22 with only one remaining objection to the DSCP
chosen. The document received detailed shepherd reviews
after the second and final call.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, and all authors have confirmed their disclosure obligations to the Chairs.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID NiTs has been checked. NOTE: A section references the obsoleted
RFC2598 instead of its replacement RFC3246, because the former
contains the description of EF performance.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. All have been checked.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates: RFC 8325.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has been reviewed by the Shepherd and this is ready for publication.
The IANA action is clear, and early allocation was requested after WGLC.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?

No new IANA registry is required, but an IANA allocation is requested.

    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

There was broad agreement on developing this work within the working group.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

This document defines a PHB and allocates a DSCP. The choice of allocated DSCP
was considered by the WG over many meetings and there was rough consensus on
the use of the chosen DS codepoint (45).

There were objections during the WGLC from people who believed the support for
legacy equipment had not been addressed and there was a need for greater
traffic protection, or a change in the allocated DSCP. The document
was revised to include more explanation, however, a small number were not
content with the final text, noting their continued concerns about the
potential impact on deployed equipment that does not comply with the new spec.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

N/A.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. This document has been reviewed in several rounds by chairs and the WG.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Standards Track.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Yes, and all authors have confirmed their disclosure obligations to the Chairs.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID NiTs has been checked. NOTE: A section references the obsoleted
RFC2598 instead of its replacement RFC3246, because the former
contains the description of EF performance.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No. All have been checked.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document updates: RFC 8325.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document has been reviewed by the Shepherd and this is ready for publication.
The IANA action is clear, and early allocation was requested after WGLC.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?

No new IANA registry is required, but an IANA allocation is requested.

    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

This email completes the Consensus Call following the Working Group LC. This document has consensus to proceed. The text will be reviewed by the shepherd and a document shepherd writeup will be prepared requesting publication.

This is a brief update on NQB status and a short call to allow people to confirm the final text:

1. Publication of of draft-ietf-tsvwg-nqb-26 closes the WGLC for NQB. Thanks to all who provided feedback.

2. The WG plans to request IANA to allocate DSCP 45 to this PHB. The WG has rough consensus on the use of this codepoint, and the chairs will note tin their writeup that some people are not content with this allocation based on the methods defined in this I-D, noting their concerns about the potential impact on deployed equipment that does not comply with the new spec.

3. The chairs are now preparing a writeup requesting the publication of this document. There are a number of steps to now complete this. The text was updated as a result of the WGLC, and we are now asking the WG to confirm the consensus to publish this finasl text by sending an email to the WG before midnight GMT on 30th November 2024.

Note: If you do have new concerns with the final text at this stage, please send requests for a change using the format OLD: text, NEW: text.

Request for Early review by INTDIR Completed: On the Right Track. Reviewer: Benson Muite. Sent review to list. Submission of review completed at an earlier date.

This ID needs to be revised as a result of the WGLC. We expect first that the editors propose a revised ID that addresses the NiTs and comments to improve the document. We then  expect the Chairs and Editors to list any issues that remain to be resolved as a result of this WGLC, and seek to agree wording that can finalise a revision of this document.

This email starts a 3 week WG Last Call to determine if the following TSVWG ID is ready:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/

This document targets: PROPOSED STANDARD.
The document shepherd will be: Gorry Fairhurst.

The WGLC will end at midnight UTC on 10th June 2024 (2024-06-27)

Please do read the draft, and please send any comments/concerns to  the TSVWG mailing list, including notes on whether these are ready to publish (or send an email directly to the chairs).

Best wishes,
Gorry and Marten
(tsvwg co-chairs)