Considerations for Assigning a New Recommended Differentiated Services Code Point (DSCP)
draft-ietf-tsvwg-dscp-considerations-13

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-tsvwg-dscp-considerations-12
CC @jgscudder

## COMMENTS

Thanks for this interesting document, I enjoyed reading it. I have a number of comments that I hope will be helpful; I'm somewhat concerned they may come off as nitpicking but in some of the cases I really did find that (for example) lack of a comma seriously impeded my ability to understand the material.

### Section 1, Expand "BA"

Please expand "BA" on first use, presumably you'd do this by putting "(BA)" next to your first and only use of "Behavior Aggregates".

### Section 2, The term 'remarking'

You might mention in your Terminology section that you use the term "remarking" in a nonstandard (with respect to the normal rules of English orthography) way, pronounced and construed as "re-marking". Then again, maybe the entire document set around DSCP already has this quirk so the ship has sailed? Your call, but you do say in Section 6 that your intended audience is the entire IETF and IESG, so it might be worth erring on the side of generosity here.

### Section 3.1, Unclear clause

The parenthetical

where 'x' refers to either a bit position with value '0' or '1'

Is unclear, probably what you mean is

where 'x' refers to a bit position with value either '0' or '1'

### Section 3.1, Pool 3

I found the discussion of 0x01, 0x03, 0x05, 0x07 under the heading of Pool 3 to be confusing, considering that we are told Pool 3 has format 0bxxx01, and so 0x03 and 0x07 are by definition not part of it. Would it make sense to end the description of Pool 3 right after "... if Pool 1 is ever exhausted" and make the remaining text a standalone paragraph and not part of the Pool 1/2/3 hanging list?

### Section 3.2, For want of a comma, the point was lost

I wasn't able to unambiguously construe

```
Similarly, another study found many routers remark all traffic except those packets with a DSCP that sets the higher order bits to 0b11 (see Section 4 of this document).
```

until I finally found the answer in the final paragraph of Section 4.2.1. So, at the very least you might update your reference to point the bamboozled reader specifically to that paragraph or at least subsection. I would also suggest at minimum adding a comma between "traffic" and "except", but really why not just rewrite it in a way that's a bit more direct?

### Section 4.2.1, Gnomic entries in Table showing 0b000xxx DSCPs

I was expecting that some later text would help me understand what "ToS Prec B1. of AF11..41", "EXP/LU", "ToS Prec B1 of AF13..EF" and "Exp/LU" mean, but none ever came. I surmise that the "ToS Prec" business means "these are assigned things that ToS-bleach down to the same thing", but really the work to figure that out was greater than the work to just read the preceding "Table of DSCP values" and come to the conclusion myself. And neither "EXP/LU" nor "Exp/LU" (why the different capitalizations?) are ever explained.

It seems to me that this table is too pithy to be of use to the casual reader such as myself, and likely too obvious to be of use to the expert reader.

### Section 4.2.1, Is LE 1, or 4?

You write "The Lower-Effort Per-Hop Behavior PHB (LE) uses a DSCP of 4". But elsewhere (the "Table of DSCP values", other tables, Section 6.2.1) you tell me LE is DSCP 1.

### Section 5.1.1 Including? Included?

"IEEE 802.1Q specified a 3-bit Priority Code Point (PCP) field including in a tag that allows Ethernet frames to be marked as one of eight priority values [IEEE-802-1Q]."

I don't know from 802.1Q, so I can't work out if there's a comma missing before "including", or if "including" should be "included". (Or something else I haven't contemplated.)

## NITS

"as well unassigned DSCPs" -> "as well as unassigned DSCPs" (insert 'as')

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
# GEN AD review of draft-ietf-tsvwg-dscp-considerations-12

CC @larseggert

## Comments

### Missing references

No reference entries found for these items, which were mentioned in the text:
`[RFC5415]`.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC1349]` to `RFC1349`, which was obsoleted by `RFC2474` (this may
be on purpose).

Reference `[RFC3662]` to `RFC3662`, which was obsoleted by `RFC8622` (this may
be on purpose).

### Grammar/style

#### Section 4, paragraph 2
```
e DSCP field to any value different than 0b000 (replace the 3 bits of the fo
                                    ^^^^
```
Did you mean "different from"? "Different than" is often considered colloquial
style. [DIFFERENT_THAN] (Also elsewhere.)

#### Section 4.2.2, paragraph 5
```
stems and subnetworks can, and do, utilise the DiffServ field in an IP packet
                                  ^^^^^^^
```
Do not mix variants of the same word ("utilise" and "utilize") within a single
text. [EN_WORD_COHERENCY] (Also elsewhere.)

#### Section 4.3, paragraph 2
```
E Ethernet 802.1Q header, the 3-bit WiFi UP field or the 3-bit Traffic Class
                                    ^^^^
```
Did you mean "Wi-Fi"? (This is the officially approved term by the Wi-Fi
Alliance.). [WIFI] (Also elsewhere.)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks to the authors for an easy and very interesting read. It would be nice to provide an open access to Cus17 or at least a summary of the analysed behaviours.

Thanks also to David Blake for the shepherd's write-up.

I have just some questions:

- do the authors have any idea about why 'IPv6 routers were found to perform all the types of remarking described above to a lesser extent than IPv4 ones' ? Could it simply be because they are more recent or better managed than legacy ones ?

- was this I-D reviewed by MPLS WG and by the 3GPP liaison ?

Minor comments:

- it would have been nice to also describe the MEF documents

- the IETF113-IEPG reference is actually for IETF-115 ;-)

Regards

-éric

[Ballot comment]
# Internet AD comments for draft-ietf-tsvwg-dscp-considerations-12
CC @ekline

## Nits

### S5.1.2

* "(wireless-to-wired interconnections," ->
  "(wireless-to-wired interconnections),"

### S6.4

* The term "re-mark" is use here, whereas it seems like "remark"
  (no hyphen) is used throughout the rest of the document.

  (Personally, I prefer "re-mark", to distinguish it from the regular
  English word having to do with observing or commenting, but that's
  just me.)

### S6.5

* In the 4th bullet, I assume "ID" here is actually "I-D" as in "Internet
  draft"?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tsvwg-dscp-considerations-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-02-24):

From: The IESG
To: IETF-Announce
CC: david.black@dell.com, draft-ietf-tsvwg-dscp-considerations@ietf.org, martin.h.duke@gmail.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)) to Informational RFC


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Considerations for Assigning a
new Recommended DiffServ Codepoint
  (DSCP)'
  as Informational RFC

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 2023-02-24. 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 discusses considerations for assigning a new
  recommended DiffServ Code Point (DSCP) for a new standard Per Hop
  Behavior (PHB).  It considers the common observed remarking behaviors
  that the DiffServ field might be subjected to along an Internet path.
  It also notes some implications of using a specific DSCP.




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



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

Document shepherd write-up:

  Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)
                draft-ietf-tsvwg-dscp-considerations-09

1. Summary

Document Shepherd: David Black
Responsible AD: Martin Duke
Intended RFC status: Informational

  This document discusses considerations for assigning a new
  recommended DiffServ Code Point (DSCP) for a new standard Per Hop
  Behavior (PHB).  It considers the common observed remarking behaviors
  that the DiffServ field might be subjected to along an Internet path.
  It also notes some implications of using a specific DSCP.

Many years after publication of the original DiffServ RFCs 2474 and
2475, the operational public Internet does not fully comply with their
DSCP processing provisions.  That has implications on choice of the
recommended DSCP for any new PHB, some of which are subtle.  After
discovering some of these subtleties in assigning recommended DSCPs
for the LE (Lower Effort) PHB and the in-progress NQB (Non Queue
Building) DSCP, the TSVWG WG produced this draft to document the
lessons learned, including summarizing the Internet measurement
results that provide insight into the nature and prevalence of
various DSCP remarking behaviors in the operational public Internet.

This draft's purpose is to provide information for the community on
DSCP assignment considerations, so publication as an Informational RFC
is appropriate.

2. Review and Consensus

The Transport Area WG (tsvwg) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.  The draft has received
significant review and critique from a number of Diffserv experts,
including the draft shepherd.  There is clear consensus in the WG to
document these lessons learned, and this draft has not been
controversial in the WG.

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits pointed out that RFC 1349 is obsolete.  This reference to an obsolete
RFC is deliberate and necessary to describe the history of the bits that
currently constitute the DSCP field.

idnits is using an outdated version of the Copyright Notice boilerplate.
The boilerplate in the draft is correct, even though idnits rejects it.

idnits complained about an IPv4 address in the draft, but there are no IPv4
addresses in the draft.  idnits appears to be mistaking a four-component
section reference (in "see Section 2.3.4.2 of [RFC2475]") for an IPv4
address.

Document shepherd write-up:

  Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)
                draft-ietf-tsvwg-dscp-considerations-09

1. Summary

Document Shepherd: David Black
Responsible AD: Martin Duke
Intended RFC status: Informational

  This document discusses considerations for assigning a new
  recommended DiffServ Code Point (DSCP) for a new standard Per Hop
  Behavior (PHB).  It considers the common observed remarking behaviors
  that the DiffServ field might be subjected to along an Internet path.
  It also notes some implications of using a specific DSCP.

Many years after publication of the original DiffServ RFCs 2474 and
2475, the operational public Internet does not fully comply with their
DSCP processing provisions.  That has implications on choice of the
recommended DSCP for any new PHB, some of which are subtle.  After
discovering some of these subtleties in assigning recommended DSCPs
for the LE (Lower Effort) PHB and the in-progress NQB (Non Queue
Building) DSCP, the TSVWG WG produced this draft to document the
lessons learned, including summarizing the Internet measurement
results that provide insight into the nature and prevalence of
various DSCP remarking behaviors in the operational public Internet.

This draft's purpose is to provide information for the community on
DSCP assignment considerations, so publication as an Informational RFC
is appropriate.

2. Review and Consensus

The Transport Area WG (tsvwg) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.  The draft has received
significant review and critique from a number of Diffserv experts,
including the draft shepherd.  There is clear consensus in the WG to
document these lessons learned, and this draft has not been
controversial in the WG.

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits pointed out that RFC 1349 is obsolete.  This reference to an obsolete
RFC is deliberate and necessary to describe the history of the bits that
currently constitute the DSCP field.

idnits is using an outdated version of the Copyright Notice boilerplate.
The boilerplate in the draft is correct, even though idnits rejects it.

idnits complained about an IPv4 address in the draft, but there are no IPv4
addresses in the draft.  idnits appears to be mistaking a four-component
section reference (in "see Section 2.3.4.2 of [RFC2475]") for an IPv4
address.