Update to IANA Registration Procedures for Pool 3 Values in the Differentiated Services Field Codepoints (DSCP) Registry
draft-ietf-tsvwg-iana-dscp-registry-08

[Ballot comment]
Hello,

Alissa's question also came to my mind, so I support her COMMENT.

Twice in the document you give a definition to "Standards Action", but it is not strictly identical to the one of 8126.
Citing RFC 8126 should be sufficient.

[Ballot comment]
- The use of 2119/8174 keywords seem unneeded for this document. As far as I can tell, there's just a MAY that talks about IANA behavior.

- Please define "bleaching".

[Ballot comment]
Is there a good reference already for the security considerations of
bleaching the TOS field?  That's not really the main point of this
document, so I don't want to make you write something from scratch,
but since we mention the issue in passing it might be nice to have
a reference if one exists.

Section 3

  The new registry contents are shown in Figure 2.

nit: Figure 2 does not show the registry *contents*, but rather the
assignment policies.

Section 5

  The Registration Procedure for use of Pool 3 is "Standards Action"
  [RFC8126].  IANA is expected to normally make assignments from Pool
  1, until this Pool is exhausted, but MAY make assignments from Pool 3
  where the format of the codepoint has properties that are needed for
  a specific PHB. The required characteristics for choosing the DSCP
  value MUST be explained in the IANA considerations of the document
  that requests any assignment from Pool 3

Does/should this requirement go away when Pool 1 is completely
allocated?

[Ballot comment]
The only question this raises for me is whether there are widespread experimental uses of Pool 3 codepoints. If so, will the people using those will be aware of this change, or is the likely impact of collisions not viewed as terribly problematic, or both?

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

The IANA Services Operator has completed its review of draft-ietf-tsvwg-iana-dscp-registry-05. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the Differentiated Services Field Codepoints located at:

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

the registration procedure for pool 3 is to be changed from Experimental or Local Use to Standards Action as defined by RFC 8126.

Second, also in the Differentiated Services Field Codepoints located at:

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

the reference for Pool 1 Codepoints will change from RFC2474 to RFC3260 and [ RFC-to-be ].

Third, also in the Differentiated Services Field Codepoints located at:

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

the note for Pool 3 is changed from:

3 xxxx01 Experimental or Local Use May be utilized for future Standards Action allocations as necessary

to:

3 xxxx01 Standards Action.

Fourth, also in the Differentiated Services Field Codepoints located at:

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

a registry will be created for Pool 3 Codepoints.

Pool 3 Codepoints on the Differentiated Services Field Codepoints registry page will be created initially empty, with a format identical to that used for "Pool 1 Codepoints". The reference for the new registry will be RFC3260 and [ RFC-to-be ].

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions 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 list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-05-25):

From: The IESG
To: IETF-Announce
CC: tsvwg@ietf.org, draft-ietf-tsvwg-iana-dscp-registry@ietf.org, david.black@dell.com, spencerdawkins.ietf@gmail.com, David Black , tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track or Best Current Practice RFC) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'IANA Assignment of DSCP Pool 3
(xxxx01) Values to require Publication
  of a Standards Track or Best Current Practice RFC'
  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
ietf@ietf.org mailing lists by 2018-05-25. 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


  The Differentiated Services (Diffserv) architecture specifies use of
  a field in the IPv4 and IPv6 packet headers to carry Diffserv
  Codepoint (DSCP) values.  The Internet Assigned Numbers Authority
  (IANA) maintains a registry of assigned DSCP values.

  This update to RFC2474 changes the IANA assignment method for Pool 3
  of the registry (i.e., DSCP values of the form xxxx01) to Standards
  Action, i.e., values are assigned through a Standards Track or Best
  Current Practice RFC. The update also removes permission for
  experimental and Local Use of the Codepoints that form Pool 3 of the
  DSCP registry; Pool 2 Codepoints (i.e., DSCP values of the form
  xxxx11) remain available for these purposes.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3260: New Terminology and Clarifications for Diffserv (Informational - IETF stream)

Document shepherd write-up:

IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Publication of
            a Standards Track or Best Current Practice RFC
                draft-ietf-tsvwg-iana-dscp-registry-04

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins

The Transport Area WG (tsvwg) is in the process of updating the RFC 3662
specification of the Diffserv Lower Effort (LE) PHB/PDB, which provides
a less than best effort or scavenger forwarding behavior.  This update
includes assignment of a new default Diffserv Codepoint (DSCP) to
replace use of the CS1 DSCP (001000) for that purpose.  The IANA
registration policy for part of the IANA DSCP registry has to be changed
in order to make that assignment; this draft makes that necessary IANA
registration policy change.

The number of possible DSCPs for the LE PHB is surprisingly limited:
  - The three most significant bits have to be '000' to accommodate
    legacy (non-Diffserv) routers whose forwarding behavior is based
    upon only those three bits, the former IP Precedence field
  - The least significant bit must be '1' in order to avoid priority
    inversion that could result from legacy router zeroing of the former
    IP Precedence field in a DSCP that is intended to provide better
    than best effort forwarding.  That IP Precedence zeroing behavior
    has been observed in the Internet.  This requirement excludes
    DSCP Pool 1 (xxxxx0) values.
  - DSCP values whose two least significant bits are '11' are not
    available because DSCP Pool 2 (xxxx11) values have been reserved
    for Experimental or Local Use.
The only remaining DSCPs that could be assigned to the LE PHB are
000001 and 000101, both of which are in DSCP Pool 3 (xxxx01).

DSCP Pool 3 was originally specified for experimental or local use with
a note (in the IANA registry) indicating that they may be utilized for
future Standards Action allocations as necessary.  That has now become
necessary for the LE PHB.  The tsvwg WG's consensus is that it is
better to reclassify the entire DSCP Pool 3 all at once for assignment
by Standards Action rather than incrementally remove individual
DSCPs from that Pool as needed, as a one-time change to the entire
Pool is more likely to have consistent implementation results.

The tsvwg WG intends to assign DSCP 000001 to the updated LE PHB.
That assignment will be made by draft-ietf-tsvwg-le-phb, which specifies
the updated LE PHB.  The IANA registry policy change made by this
draft is a necessary prerequisite to that assignment.

The WG has requested Proposed Standard status because this draft
modifies IANA assignment policy for part of the DSCP registry.

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 tsvwg WG consensus on
the need to assign a pool 3 DSCP to the LE PHB, and that consensus
is supported by Internet path measurements that indicate that zeroing
of the former IP Precedence field, while rare, occurs often enough to
be an important design consideration in assignment of a default DSCP
to the updated LE PHB.

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

There is a downref to RFC 3260, an Informational RFC that contains new
Diffserv terminology and clarifications.  This downref needs to be
normative, as this draft requests IANA to add that as a reference to
both the new registry table that is created and an existing registry table.
That downref needs to be noted at IETF Last Call.

The shepherd has checked the IANA Considerations, which include updates
to the references for the Pool 1 DSCP table (sub-registry) in addition to
creating a new Pool 3 table (sub-registry).