Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry
draft-ietf-mpls-lsp-ping-registries-update-11

[Ballot discuss]
A few super-boring inconsistencies that make the document unfit to
publish as-is but should be mostly trivial to resolve ((3) and (4) might
be a little tedious but should be mechanical):

(1) Section 3.3.1 says:

      be silently dropped if not recognized.  The code points for
      experimental use are taken from the ranges previously called
      'Vendor Private Use', the remainder of which now form part of 'RFC
      Required'.

but I don't think this sentence matches what's proposed in Section 6.  I
am seeing the code points for experimental use coming out of the range
that is currently described as "specification required", with the
entirety of the range currently described as "vendor private use" being
converted to FCFS.

(2) Section 4.1 says:

  Mandatory and optional are used to indicate whether a response is
  needed if a TLV or sub-TLV is not understood on pages 14 and 15 in
  Section 3 of RFC 8029.

but I think the text being modified is on pages 15 and 16 of RFC 8029
(the page numbers are in the footer, not the header, of the plain text
output format).

(3) Section 6.2.3 describes changes to the procedures for the Sub-TLVs
for TLV 6 sub-registry, but the changes described assume that the
registration procedures are as described by RFC 8029.  However, the
registration procedures have already been changed by RFC 8611, so the
changes described no longer make sense.  (E.g., there is not currently a
"specification required" procedure active for any range of this
sub-registry.)  We do, however, still need to make some changes to the
registration procedures, specifically to convert the "Private Use"
ranges to FCFS and carve out the "Experimental Use" blocks.

(4) Table 22 (for Sub-TLVs for TLV 27 Assignments) seems to be a copy of
Table 20 and does not reflect the current state of the sub-registry in
question.

[Ballot comment]
A big thanks for putting this together; if it had been around in 2019
when I was reviewing what became RFC 8611 it probably would have spared
me some confusion.

As a general note, it's not entirely clear to me that there's a huge
need to have the standards-action range be 16 times as big as the FCFS
range (in the security area our trend has been to generally make it
easier to get codepoints since people just squat otherwise).  But
neither range is filling up quickly, and we could of course change the
rules again in the future if needed, so I don't see much need to try to
deviate from the current path.

There is perhaps some overlap between the contents of Sections 3.2 and
3.3.1, but this does not seem to inherently cause great harm so may not
be worth changing.

What follows is basically a pile of nit- and editorial-level comments;
individual responses are not expected.

Abstract

Is there more that could be said about where the "recent developments"
occurred (or even what they are)?

Section 1

  Third, some code points (TLVs and sub-TLVs) are "mandatory" or
  "optional".  Contrary to how other RFCs use these words, indicating

I suggest tweaking the wording to clarify that the marking of code
points as "mandatory" or "optional" is in the text of RFC 8029 prior to
the modifications made by this document (assuming I understand correctly
the intent), perhaps as "in RFC 8029, some code points (TLVs and
sub-TLVs) were marked as 'mandatory' or 'optional".

Section 1.2

  This section list terms that are just to discuss IANA registers
  (Section 1.2.1) and abbreviations used in IANA registries update in
  this document (Section 1.2.2).

some nits here; I suggest
NEW:
> This section lists terms that are used when discussing IANA registries
> (Section 1.2.1), and abbreviations used in the IANA registry updates
> made by this document (Section 1.2.2).

Section 1.2.1

      IANA Registry,
      an IANA registry holds code points, and lists the registration
      procedures and allocation of code points these code points.  One
      example would be the "TLVs" registry [IANA-TLV-reg].

nit: maybe a duplicated phrase in "of code points these code points"?

Section 1.2.2

  This section list abbreviations used in the unchanged part of the
  registries updated by this document, these abbreviations were
  originally expanded in the document defining the registries.  [...]

nit: comma splice (change to either semicolon or full stop at your
discretion).

  are listed here following the requirement to expand any abbreviation
  that is not well-known.  All these abbreviations are from the same
  registry (Assignments for the Return Codes registry).

nit: I think the registry is just the "Return Codes" registry, but we
reference them in the table entitled "Assignments for the Return Codes
registry".

(Side note) I'm a bit surprised that a couple of these aren't marked as
"well known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt ... and now
that I'm looking, I see that there is an entry for "O&M" attributed to
one two-ell-ed "Adrian Farrell"?!  Hopefully the RFC Editor can remedy
the surplus of ells.

Section 3.1

  The following principles apply to the processing of any TLV from any
  of the LSP Ping TLV and sub-TLV IANA registries.

nit(?): it looks like the "TLVs" registry (and sub-TLVs) are spelled as
the plural on the IANA page, so maybe we should say "the LSP Ping TLVs
and sub-TLVs IANA registries"

Section 3.1.1

  o  If the unrecognized TLV or sub-TLV is from the Experimental Use
      range (64508-64511)or from the FCFS range (64512-65535) the TLVs

nit: s/)or/) or/

  The IETF does not prescribe how recognized or unrecognized
  Experimental Use and Private Use TLVs and sub-TLVs are handled in
  experimental or private networks, that is up to the agency running
  the experimental or the private network.  [...]

nit: comma splice (semicolon probably preferred over full stop, here).

Section 3.3

  This section lists the changes to each MPLS LSP Ping TLV and sub-TLV
  Registry, see section 6.2.1 to 6.2.7 describe how the new versions of
  [...]

some nits here; I suggest
NEW:
> This section lists the changes to each MPLS LSP Ping TLV and sub-TLV
> Registry.  Sections 6.2.1 to 6.2.7 describe how the new versions of
> [...]

Section 3.3.1

  o  Two small sets of code points (4 code points each) for
      Experimental Use, are created.  The first set is for the range
      that requires a response if the TLV or sub-TLV is not recognized;
      the second set is for the range there the TLV or sub-TLV that may

nit: s/there the/where the/

Section 4.1

      The following TLV is a TLV that MAY be included in an echo reply
      to inform the sender of an echo request that includes TLVs or sub-
      TLVs Types less than 32768 (i.e., with the high-order bit equal to
      0) are either not supported by the implementation or parsed and
      found to be in error.

nit: I think there's a missing word before "are either", maybe "that" or
"and".

Section 4.2

  | 64508-64511 | Experimental Use  | Reserved not to be assigned    |
  | 64512-65535 | FCFS              | This range is for sub-TLVs that |
  |            |                  | can be silently dropped if not  |
  |            |                  | recognized.                    |

nit: I think the "This range...not recognized" text needs to be
duplicated for the Experimental Use and FCFS ranges.

Section 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7

  | 64508-64511 | Experimental Use  | Reserved, not to be assigned    |
  | 64512-65535 | FCFS              | This range is for TLVs that can |
  |            |                  | be silently dropped if not      |
  |            |                  | recognized.                    |

nit: I think the "This range...not recognized" text needs to be
duplicated for the Experimental Use and FCFS ranges.

  | 64508-64511 | Experimental  | This document  | Reserved, not to  |
  |            | Use          |                | be assigned      |

Should we have a note about "can be silently dropped" for this range, to
match the other range?

Section 6.2.2

  | 6-8        | EQ            | EQ              | EQ                |
  | 9          | EQ            | EQ              | DEPRECATED        |
  | 10-20      | EQ            | EQ              | EQ                |

It looks like the "Comment" (rightmost) column already says "DEPRECATED"
for sub-TLV 9, so this range could be consolidated into just "6-20 EQ EQ
EQ"?

Section 6.2.3

  | 0          | Reserved      | This document  |                  |

Do we want to keep the reference for this entry as RFC 8611 (it is
already marked as reserved), change it to just [this document], or use
both documents as references?

Section 8.1

It looks like we only reference RFC 8287 because it's in a preexisting
registry entry that we repeat but are not changing.  So it could
probably be just informative for the purposes of this document, like
7110, 7555, etc.

Section 8.2

That said, I think I would support moving RFC 8126 to the normative list
(but it doesn't make much difference one way or the other).

[Ballot comment]
§6 asks IANA to add a header mentioning the designated experts for several registries.  Some of those registries already mention the same 2 experts, but that is not the case for all.  I have 2 points around this:

(1) It doesn't seem like a good idea to include the experts' names in the document.  They will at some point change, and updating an RFC is too heavyweight for that change.

(2) I have no objections to naming the 2 experts as DEs for all registries, but that action should be approved by the IESG (and not simply mentioned in the document).


In summary, the explicit text about the experts' names should be removed.  Instead, there should be a Management Item for the IESG to approve them for the remaining registries.

[Ballot comment]
Thank you for the work put into this document.

Thanks to Adrian Farrel for writing about the WG consensus.

Using "namespace" for code points in a registry sounded weird to me; but it appears that it is used indeed by MPLS even for numbers.

Regards,

-éric

[Ballot discuss]
Hi,

I have a couple of concerns regarding the change from part of the registry from "Private Use" to "FCFS":

(1) Am I right in thinking that this could, at least in theory, break existing deployments?  E.g., two separate implementations could both be using TLV value 31744 under "private use", whereas now they would both be expected to register that TLV with IANA under FCFS, and obviously only one of them would be able to get the registration?  Are the authors/WG/ADs aware with high confidence that no such deployments exist?

(2) I find the "updates" tag for RFCs to be somewhat ambiguous as to what it means.  Specifically, is someone who implements RFC 8611 obliged to also implement draft-ietf-mpls-lsp-ping-registries-update when this becomes an RFC?  Or are they allowed to take the previous interpretation of the "private use" in the IANA registries?  Probably too late to change this now, but I wonder if it would have been better to bis RFC 8611 instead so that RFC 8611 could have been formally obsoleted by draft-ietf-mpls-lsp-ping-registries-update instead.

An alternative solution would be to keep the "Private Use" space as defined in RFC 8611, and allocate new space for FCFS (24 entries) from the 15,000 entry "RFC Required" section of the TLV Id space instead.  These would seem to make the new allocation scheme in draft-ietf-mpls-lsp-ping-registries-update entirely backwards compatible with any existing deployments.  Was this approach considered and dismissed for some reason?

Regards,
Rob

[Ballot comment]
[[ comments ]]

[ section 1.2.1 ]

* I find it slightly odd that this section even exists.

  RFC 8126 section 1 seems to provide a definition for "namespace" and
  for "assignment"/"registration".  My reading of 8126s1's definition
  of namespace doesn't seem to quite match this document's use of namespace
  (seems more like the definition of registry without the existence of
  a definition for "sub-registry"), but maybe I haven't spent enough time
  thinking about it.

  If IANA review is fine with this text here, I've no objection.


[[ nits ]]

[ section 1 ]

* "there hav been" -> "there have been"

[Ballot comment]
Thank you for writing this clarifying document.

** Section 3.1.  Per “All TLVs and sub-TLVs in the range 32768-65535 may be silently dropped, stepped over or an error message sent …”, is “stepped over” the same as ignored?

** Section 3.1.1.
-- “If the unrecognized TLV and sub-TLV is from … a Return Code of 2 … must be …”, should a normative MUST be used here?”

-- “If the unrecognized TLV and sub-TLV is from … the TLVs may be …”, should a normative MAY be used here?

[Ballot comment]
At first I was puzzled by the move from Specification Required to RFC Required, until I looked in RFC 8209 at this:

  Values from "Specification Required" ranges MUST be registered with
  IANA.  The request MUST be made via an RFC that describes the format
  and procedures for using the code point; the actual assignment is
  made during the IANA actions for the RFC.

In other words, it's really always been RFC Required, but specified in an odd way and with a designated expert looking at it.

So, yes, this is a useful cleanup and clarification, and thanks for doing this.  And, as you have in the Acknowledgments, thanks to Michelle for working with you to make sure this came out right.

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

The IANA Functions Operator has completed its review of draft-ietf-mpls-lsp-ping-registries-update-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

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

All of the modifications listed below affect registries that are on the Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters registry page located at:

https://www.iana.org/assignments/mpls-lsp-ping-parameters/

IANA understands that the following registries on that page are to be modified:

Message Types
Reply Modes
Return Codes
TLVs
Sub-TLVs for TLV Types 1, 16, and 21
Sub-TLVs for TLV Type 6
Sub-TLVs for TLV Type 11
Sub-TLVs for TLV Type 20
Sub-TLVs for TLV Type 23
Sub-TLVs for TLV Type 27

IANA Question --> In each one of these registries should the new reference, [ RFC-to-be ], replace the existing reference (for instance RFC8029) or should [ RFC-to-be ] be added to the existing references.

IANA Question --> Are there any other registries beyond the ten specified above where existing references to RFC 8029 and 8611 should either be replaced by or have [ RFC-to-be ] added?

IANA Question --> In the texts for the Sub-TLV modifications the words "sun-TLV" often appear. Is this a typo for "sub-TLV?" As an example see the text in section 6.2.2 of the current draft.

First, the Message Type registry is modified as follows:

1. Code Point 0 (zero) is marked Reserved.
2. The registration procedure "Specification Required" is changed to "RFC Required" and the comment "Experimental RFC needed" is removed.
3. Four code point have been taken from what was earlier "Specification Required" to form a set of code points for "Experimental Use."

The registration procedures for the revised registry are as follows:

+---------+--------------------+------------------------------------+
| Range | Registration | Note |
| | Procedures | |
+---------+--------------------+------------------------------------+
| 0-191 | Standards Action | |
| 192-247 | RFC Required | |
| 248-251 | Experimental Use | Reserved, not to be assigned |
| 252-255 | Private Use | Reserved, not to be assigned |
+---------+--------------------+------------------------------------+

After completion of this task the registry will appear as follows:

+---------+---------------------------------+-----------------------+
| Value | Meaning | Reference |
+---------+---------------------------------+-----------------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1 | MPLS Echo Request | [RFC8029] |
| 2 | MPLS Echo Reply | [RFC8029] |
| 3 | MPLS Proxy Ping Request | [RFC7555] |
| 4 | MPLS Proxy Ping Reply | [RFC7555] |
| 5 | MPLS Relayed Echo Reply | [RFC7743] |
| 6-247 | Unassigned | |
| 248-251 | Reserved for Experimental Use | [ RFC-to-be ] |
| 252-255 | Reserved for Private Use | [RFC8029] |
+---------+---------------------------------+-----------------------+

Second, the Reply Modes registry will be modified as follows:

1. Code Point 0 (zero) is marked Reserved.
2. The registration procedure "Specification Required" is changed to "RFC Required" and the comment "Experimental RFC needed" is removed.
3. Four code point have been taken from what was earlier "Specification Required" to form a set of code points for "Experimental Use".

The registration procedures for the revised registry are as follows:

+---------+--------------------+------------------------------------+
| Range | Registration | Note |
| | Procedures | |
+---------+--------------------+------------------------------------+
| 0-191 | Standards Action | |
| 192-247 | RFC Required | |
| 248-251 | Experimental Use | Reserved, not to be assigned |
| 252-255 | Private Use | Reserved, not to be assigned |
+---------+--------------------+------------------------------------+

After completion of this task the registry will appear as follows:

+---------+---------------------------------+-----------------------+
| 0 | Reserved | [ RFC-to-be ] |
| 1 | Do not reply | [RFC8029] |
| 2 | Reply via an IPv4/IPv6 UDP | [RFC8029] |
| | packet | |
| 3 | Reply via an IPv4/IPv6 UDP | [RFC8029] |
| | packet with Router Alert | |
| 4 | Reply via application-level | [RFC8029] |
| | control channel | |
| 5 | Reply via Specified Path | [RFC7110] |
| 6-247 | Unassigned | |
| 248-251 | Reserved for Experimental Use | [ RFC-to-be ] |
| 252-255 | Reserved for Private Use | [RFC8029] |
+---------+---------------------------------+-----------------------+

Third, the Return Codes registry will be modified as follows:

1. The registration procedure "Specification Required" is changed to "RFC Required" and the comment "Experimental RFC needed" is removed.
2. Four code point have been taken from what was earlier "Specification Required" to form a set of code points for "Experimental Use".

The registration procedures for the revised registry are as follows:

+---------+--------------------+------------------------------------+
| Range | Registration | Note |
| | Procedures | |
+---------+--------------------+------------------------------------+
| 0-191 | Standards Action | |
| 192-247 | RFC Required | |
| 248-251 | Experimental Use | Reserved, not to be assigned |
| 252-255 | Private Use | Reserved, not to be assigned |
+---------+--------------------+------------------------------------+

After completion of this task the registry will appear as follows:

+---------+----------------------------------+----------------------+
| Value | Meaning | Reference |
+---------+----------------------------------+----------------------+
| 0 | No Return Code | [ RFC-to-be ] |
| 1 | Malformed echo request received | [RFC8029] |
| 2 | One or more of the TLVs was not | [RFC8029] |
| | understood | |
| 3 | Replying router is an egress for | [RFC8029] |
| | the FEC at stack-depth (RSC) | |
| 4 | Replying router has no mapping | [RFC8029] |
| | for the FEC at stack-depth (RSC) | |
| 5 | Downstream Mapping Mismatch (See | [RFC8029] |
| | [1]) | |
| 6 | Upstream Interface Index Unknown | [RFC8029] |
| | (See [1]) | |
| 7 | Reserved | [RFC8029] |
| 8 | Label switched at stack-depth | [RFC8029] |
| | (RSC) | |
| 9 | Label switched but no MPLS | [RFC8029] |
| | forwarding at stack-depth (RSC) | |
| 10 | Mapping for this FEC is not the | [RFC8029] |
| | given label at stack-depth (RSC) | |
| 11 | No label entry at stack-depth | [RFC8029] |
| | (RSC) | |
| 12 | Protocol not associated with | [RFC8029] |
| | interface at FEC stack-depth | |
| | (RSC) | |
| 13 | Premature termination of ping | [RFC8029] |
| | due to label stack shrinking to | |
| | a single label | |
| 14 | See DDMAP TLV for meaning of | [RFC8029] |
| | Return Code and Return Subcode | |
| | (See [2]) | |
| 15 | Label switched with FEC change | [RFC8029] |
| 16 | Proxy Ping not authorized | [RFC7555] |
| 17 | Proxy Ping parameters need to be | [RFC7555] |
| | modified | |
| 18 | MPLS Echo Request could not be | [RFC7555] |
| | sent | |
| 19 | Replying router has FEC mapping | [RFC7555] |
| | for topmost FEC | |
| 20 | One or more TLVs not returned | [RFC7743] |
| | due to MTU size | |
| 21 | OAM Problem/Unsupported BFD | [RFC7759] |
| | Version | |
| 22 | OAM Problem/Unsupported BFD | [RFC7759] |
| | Encapsulation format | |
| 23 | OAM Problem/Unsupported BFD | [RFC7759] |
| | Authentication Type | |
| 24 | OAM Problem/Mismatch of BFD | [RFC7759] |
| | Authentication Key ID | |
| 25 | OAM Problem/Unsupported | [RFC7759] |
| | Timestamp Format | |
| 26 | OAM Problem/Unsupported Delay | [RFC7759] |
| | Mode | |
| 27 | OAM Problem/Unsupported Loss | [RFC7759] |
| | Mode | |
| 28 | AM Problem/Delay variation | [RFC7759] |
| | unsupported | |
| 29 | OAM Problem/Dyadic mode | [RFC7759] |
| | unsupported | |
| 30 | OAM Problem/Loopback mode | [RFC7759] |
| | unsupported | |
| 31 | OAM Problem/Combined mode | [RFC7759] |
| | unsupported | |
| 32 | OAM Problem/Fault management | [RFC7759] |
| | signaling unsupported | |
| 33 | OAM Problem/Unable to create | [RFC7759] |
| | fault management association | |
| 34 | OAM Problem/PM Configuration | [RFC7759] |
| | Error | |
| 35 | Mapping for this FEC is not | [RFC8287] sec 7.4 |
| | associated with the incoming | |
| | interface | |
| 36-247 | Unassigned | [RFC7759] |
| 248-251 | Reserved for Experimental Use | [ RFC-to-be ] |
| 252-255 | Reserved for Private Use | [RFC8029] |
+---------+----------------------------------+----------------------+

IANA understands that the footnotes in this registry are not to be changed upon the approval of [ RFC-to-be ].

Fourth, the TLVs registry will be modified as follows:

1. The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed.
2. The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points.
3. Two small sets, 4 code points each, have been created for Experimental Use.
4. Code points that are reserved are clearly marked as such.
5. The assignments have been updated to match the new registration procedures.
6. The notes related to the registration procedures have been changed to reflect when a response is required or not if a TLV is not recognized.

The registration procedures for the revised registry are as follows:

+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 16384-31739 | RFC Required | This range is for TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31740-31743 | Experimental Use | Reserved, not to be assigned. |
| | | This range is for sub-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31744-32767 | FCFS | This range is for TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 32768-49161 | Standards Action | This range is for TLVs that can |
| | | be silently dropped if not |
| | | recognized. |
| 49162-64507 | RFC Required | This range is for TLVs that can |
| | | be silently dropped if not |
| | | recognized. |
| 64508-64511 | Experimental Use | Reserved, not to be assigned |
| 64512-65535 | FCFS | This range is for TLVs that can |
| | | be silently dropped if not |
| | | recognized. |
+-------------+-------------------+---------------------------------+

After completion of this task the registry will appear as follows:

When a field in this table is marked with the characters "EQ", it means that no change to the existing registration should be made during the update of the registry.

+-------------+---------------+-----------------+-------------------+
| Type | TLV Name | Reference | Sub-TLV Registry |
+-------------+---------------+-----------------+-------------------+
| 0 | Reserved | [ RFC-to-be ] | |
| 1-7 | EQ | EQ | EQ |
| 8 | Unassigned | | |
| 9-16 | EQ | EQ | EQ |
| 17-19 | unassigned | | |
| 20-27 | EQ | EQ | EQ |
| 28-31739 | Unassigned | | |
| 31740-31743 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned. This |
| | | | range is for sub- |
| | | | TLVs that require |
| | | | an error message |
| | | | if not |
| | | | recognized. |
| | | | [ RFC-to-be; |
| | | | Section 3.1 ] |
| 31744-32767 | Unassigned | | |
| 32768-32770 | EQ | EQ | EQ |
| 32771-64507 | EQ | EQ | EQ |
| 64508-64511 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned |
| 64512-65535 | Unassigned | | |
+-------------+---------------+-----------------+-------------------+

Fifth, the SubTLVs for TLVs 1, 16 and 21 registry will be modified as follows:

1. The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed.
2. The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points.
3. Two small sets, 4 code points each, have been created for Experimental Use.
4. Code points that are reserved are clearly marked as such.
5. The assignments have been updated to match the new registration procedures.
6. The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not.

The registration procedures for the revised registry are as follows:

+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 16384-31739 | RFC Required | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31740-31743 | Experimental Use | Reserved, not to be assigned. |
| | | This range is for sub-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31744-32767 | FCFS | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 32768-49161 | Standards Action | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 49162-64507 | RFC Required | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 64508-64511 | Experimental Use | Reserved, not to be assigned |
| 64512-65535 | FCFS | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
+-------------+-------------------+---------------------------------+

After completion of this task the registry will appear as follows:

When a field in this table is marked with the characters "EQ", it means that no change to the existing registration should be made during the update of the registry.

+-------------+---------------+-----------------+-------------------+
| Type | TLV Name | Reference | Comment |
+-------------+---------------+-----------------+-------------------+
| 0 | Reserved | [ RFC-to-be ] | |
| 1-4 | EQ | EQ | EQ |
| 5 | Unassigned | | |
| 6-8 | EQ | EQ | EQ |
| 9 | EQ | EQ | DEPRECATED |
| 10-20 | EQ | EQ | EQ |
| 21 | unassigned | | |
| 22-37 | EQ | EQ | EQ |
| 38-31739 | Unassigned | | |
| 31740-31743 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned. This |
| | | | range is for sub- |
| | | | TLVs that require |
| | | | an error message |
| | | | if not |
| | | | recognized. |
| | | | [ RFC-to-be; |
| | | | Section 3.1 ] |
| 31744-64507 | Unassigned | | |
| 64508-64511 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned |
| 64512-65535 | Unassigned | | |
+-------------+---------------+-----------------+-------------------+

Sixth, the SubTLVs for TLV 6 registry will be modified as follows:

1. The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed.
2. The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points.
3. Two small sets, 4 code points each, have been created for Experimental Use.
4. Code points that are reserved are clearly marked as such.
5. The assignments have been updated to match the new registration procedures.
6. The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not.

The registration procedures for the revised registry are as follows:

+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 16384-31739 | RFC Required | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31740-31743 | Experimental Use | Reserved, not to be assigned. |
| | | This range is for sub-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31744-32767 | FCFS | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 32768-49161 | Standards Action | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 49162-64507 | RFC Required | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 64508-64511 | Experimental Use | Reserved, not to be assigned |
| 64512-65535 | FCFS | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
+-------------+-------------------+---------------------------------+

After completion of this task the registry will appear as follows:

When a field in this table is marked with the characters "EQ", it means that no change to the existing registration should be made during the update of the registry.

+-------------+---------------+-----------------+-------------------+
| Type | TLV Name | Reference | Comment |
+-------------+---------------+-----------------+-------------------+
| 0 | Reserved | [ RFC-to-be ] | |
| 1-2 | EQ | EQ | EQ |
| 3-31739 | Unassigned | | |
| 31740-31743 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned. This |
| | | | range is for sub- |
| | | | TLVs that require |
| | | | an error message |
| | | | if not |
| | | | recognized. |
| | | | [ RFC-to-be; |
| | | | Section 3.1 ] |
| 31744-64507 | Unassigned | | |
| 64508-64511 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned |
| 64512-65535 | Unassigned | | |
+-------------+---------------+-----------------+-------------------+

Seventh, the SubTLVs for TLV 11 registry will be modified as follows:

1. The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed.
2. The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points.
3. Two small sets, 4 code points each, have been created for Experimental Use.
4. Code points that are reserved are clearly marked as such.
5. The assignments have been updated to match the new registration procedures.
6. The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not.

The registration procedures for the revised registry are as follows:

+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 16384-31739 | RFC Required | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31740-31743 | Experimental Use | Reserved, not to be assigned. |
| | | This range is for sub-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31744-32767 | FCFS | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 32768-49161 | Standards Action | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 49162-64507 | RFC Required | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 64508-64511 | Experimental Use | Reserved, not to be assigned |
| 64512-65535 | FCFS | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
+-------------+-------------------+---------------------------------+

After completion of this task the registry will appear as follows:

When a field in this table is marked with the characters "EQ", it means that no change to the existing registration should be made during the update of the registry.

+-------------+---------------+-----------------+-------------------+
| Type | TLV Name | Reference | Comment |
+-------------+---------------+-----------------+-------------------+
| 0 | Reserved | [ RFC-to-be ] | |
| 1-4 | EQ | EQ | EQ |
| 5-31739 | Unassigned | | |
| 31740-31743 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned. This |
| | | | range is for sub- |
| | | | TLVs that require |
| | | | an error message |
| | | | if not |
| | | | recognized. |
| | | | [ RFC-to-be; |
| | | | Section 3.1 ] |
| 31744-64507 | Unassigned | | |
| 64508-64511 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned |
| 64512-65535 | Unassigned | | |
+-------------+---------------+-----------------+-------------------+

Eighth, the SubTLVs for TLV 20 registry will be modified as follows:

IANA Question --> There appears to be a typo below. In the sentence "Two small sets, 4 code ve been created for Experimental Use," it appears it should be "Two small sets, 4 code points each, have been created for Experimental Use." Is this correct?

1. The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed.
2. The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points.
3. Two small sets, 4 code ve been created for Experimental Use.
4. Code points that are reserved are clearly marked as such.
5. The assignments have been updated to match the new registration procedures.
6. The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not.

The registration procedures for the revised registry are as follows:

+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 16384-31739 | RFC Required | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31740-31743 | Experimental Use | Reserved, not to be assigned. |
| | | This range is for sub-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31744-32767 | FCFS | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 32768-49161 | Standards Action | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 49162-64507 | RFC Required | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 64508-64511 | Experimental Use | Reserved, not to be assigned |
| 64512-65535 | FCFS | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
+-------------+-------------------+---------------------------------+

After completion of this task the registry will appear as follows:

When a field in this table is marked with the characters "EQ", it means that no change to the existing registration should be made during the update of the registry.

+-------------+---------------+-----------------+-------------------+
| Type | TLV Name | Reference | Comment |
+-------------+---------------+-----------------+-------------------+
| 0 | Reserved | [ RFC-to-be ] | |
| 1-5 | EQ | EQ | EQ |
| 6-31739 | Unassigned | | |
| 31740-31743 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned. This |
| | | | range is for sub- |
| | | | TLVs that require |
| | | | an error message |
| | | | if not |
| | | | recognized. |
| | | | [ RFC-to-be; |
| | | | Section 3.1 ] |
| 31744-64507 | Unassigned | | |
| 64508-64511 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned |
| 64512-65535 | Unassigned | | |
+-------------+---------------+-----------------+-------------------+

Ninth, the SubTLVs for TLV 23 registry will be modified as follows:

1. The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed.
2. The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points.
3. Two small sets, 4 code points each, have been created for Experimental Use.
4. Code points that are reserved are clearly marked as such.
5. The assignments have been updated to match the new registration procedures.
6. The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not.

The registration procedures for the revised registry are as follows:

+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 16384-31739 | RFC Required | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31740-31743 | Experimental Use | Reserved, not to be assigned. |
| | | This range is for sub-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31744-32767 | FCFS | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 32768-49161 | Standards Action | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 49162-64507 | RFC Required | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 64508-64511 | Experimental Use | Reserved, not to be assigned |
| 64512-65535 | FCFS | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
+-------------+-------------------+---------------------------------+

After completion of this task the registry will appear as follows:

When a field in this table is marked with the characters "EQ", it means that no change to the existing registration should be made during the update of the registry.

+-------------+---------------+-----------------+-------------------+
| Type | TLV Name | Reference | Comment |
+-------------+---------------+-----------------+-------------------+
| 0 | Reserved | [RFC7555] | |
| 1 | EQ | EQ | EQ |
| 2-31739 | Unassigned | | |
| 31740-31743 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned. This |
| | | | range is for sub- |
| | | | TLVs that require |
| | | | an error message |
| | | | if not |
| | | | recognized. |
| | | | [ RFC-to-be; |
| | | | Section 3.1 ] |
| 31744-64507 | Unassigned | | |
| 64508-64511 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned |
| 64512-65535 | Unassigned | | |
+-------------+---------------+-----------------+-------------------+

Tenth, the SubTLVs for TLV 27 registry will be modified as follows:

1. The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed.
2. The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points.
3. Two small sets, 4 code points each, have been created for Experimental Use.
4. Code points that are reserved are clearly marked as such.
5. The assignments have been updated to match the new registration procedures.
6. The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not.

The registration procedures for the revised registry are as follows:

+-------------+-------------------+---------------------------------+
| Range | Registration | Note |
| | Procedures | |
+-------------+-------------------+---------------------------------+
| 0-16383 | Standards Action | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 16384-31739 | RFC Required | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31740-31743 | Experimental Use | Reserved, not to be assigned. |
| | | This range is for sub-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 31744-32767 | FCFS | This range is for sun-TLVs that |
| | | require an error message if not |
| | | recognized. [[ RFC-to-be ], |
| | | section 3.1] |
| 32768-49161 | Standards Action | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 49162-64507 | RFC Required | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
| 64508-64511 | Experimental Use | Reserved, not to be assigned |
| 64512-65535 | FCFS | This range is for sun-TLVs that |
| | | can be silently dropped if not |
| | | recognized. |
+-------------+-------------------+---------------------------------+

After completion of this task the registry will appear as follows:

When a field in this table is marked with the characters "EQ", it means that no change to the existing registration should be made during the update of the registry.

+-------------+---------------+-----------------+-------------------+
| Type | TLV Name | Reference | Comment |
+-------------+---------------+-----------------+-------------------+
| 0 | Reserved | [RFC7555] | |
| 1 | EQ | EQ | EQ |
| 2-31739 | Unassigned | | |
| 31740-31743 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned. This |
| | | | range is for sub- |
| | | | TLVs that require |
| | | | an error message |
| | | | if not |
| | | | recognized. |
| | | | [ RFC-to-be; |
| | | | Section 3.1 ] |
| 31744-64507 | Unassigned | | |
| 64508-64511 | Experimental | [ RFC-to-be ] | Reserved, not to |
| | Use | | be assigned |
| 64512-65535 | Unassigned | | |
+-------------+---------------+-----------------+-------------------+

The IANA Functions 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 2021-01-26):

From: The IESG
To: IETF-Announce
CC: Adrian Farrel , adrian@olddog.co.uk, db3546@att.com, draft-ietf-mpls-lsp-ping-registries-update@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Updating the IANA MPLS LSP Ping Parameters) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'Updating the IANA MPLS LSP Ping
Parameters'
  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 2021-01-26. 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 updates RFC 8029 and RFC 8611 that both define IANA
  registries for MPLS LSP Ping.  It also updates the description of the
  procedures for the responses sent when an unknown or erroneous code
  point is found.  The updates are to clarify and align this name space
  with recent developments.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/



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

Shepherd write-up for draft-ietf-mpls-lsp-ping-registries-update-06

> (1) What type of RFC is being requested

The MPLS working group requests that this document is published as an
RFC on the Standards Track.  This is appropriate as it updates RFCs
8029 and 8611 both of which are Standards Track RFCs.  Furthermore, the
document requests IANA action applied to registries that need Standards
Action.

The document clearly indicates "Standards Action."

> (2) Please provide a Document Announcement Write-Up.
>
> Technical Summary:

This document updates RFC 8029 and RFC 8611 that both define IANA
registries for MPLS LSP Ping.  It also updates the description of the
procedures for the responses sent when an unknown or erroneous code
point is found.  The updates are to clarify and align this name space
with recent developments.

> Working Group Summary:

It has been somewhat hard to get WG review for what is a dry procedural
document.  However, after poking the group several times we got enough
review to know that the document is sound, and there were no negative
comments.

> Document Quality:

There's nothing here to implement.  The judge of the document is whether
IANA can understand it well enough to implement it, and whether the WG
agrees with the intention.  That seems to be achieved.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Deborah Brungard (dbrungard@att.com) is the Responsible Area Director

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I have reviewed this document several times and the authors made changes
to address my comments.  This version is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

As noted in the WG Summary, more reviews would have been reassuring, but
there was enough review for this type of document.

> (5) Do portions of the document need review from a particular or from
> broader perspective.  If so, describe the review that took place.

We sent the -04 revision to IANA for review.  They sent minor comments
and stated that the document was clear.

> (6) Describe any specific concerns or issues that the Document
> Shepherd has with this document that the Responsible Area Director
> and/or the IESG should be aware of?

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors confirmed. See https://mailarchive.ietf.org/arch/msg/mpls/jGlcQAYdKaiW7xbmrN36bcqeqm0/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (9) How solid is the WG consensus behind this document?

No dissenting voices.  A few voices of solid support, and a few voices
of minor support.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?

No discontent.

> (11) Identify any ID nits the Document Shepherd has found in this
> document.

idnits warns about normative references to IANA registries. Otherwise
no issues.

> (12) Describe how the document meets any required formal review
> criteria.

None needed.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes

> (14) Are there normative references to documents that are not ready
> for advancement or are otherwise in an unclear state?

None such.

> (15) Are there downward normative references references (see RFC
> 3967)?

None such (but see the answer to 11).

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction?

This document Updates RFC 8029 and RFC 8611.
This is noted in the header.
The Abstract observes that this document updates those RFCs and
describes the nature of the update.
The Introduction expands on the details of the update.

> (17) 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 protocol extensions
> that the document makes are associated with the appropriate
> reservations in IANA registries. Confirm that any referenced IANA
> registries have been clearly identified. Confirm that newly created
> IANA registries include a detailed specification of the initial
> contents for the registry, that allocations procedures for future
> registrations are defined, and a reasonable name for the new registry
> has been suggested (see RFC 8126).

This document is all about IANA actions, and is clear. The IANA
Considerations section explicitly directs IANA and is consistent with
the explanations in the rest of the document.

There are no new registries, but there are changes to allocation
procedures for several registries. These are clearly described and all
registries are clearly indicated.

> (18) List any new IANA registries that require Expert Review for
> future allocations.

No Expert Review is needed for any parts of any of the registries.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language.

No formal language used, no checks performed.

> (20) If the document contains a YANG module, has the module been
> checked with any of the recommended validation tools?

No YANG.

Shepherd write-up for draft-ietf-mpls-lsp-ping-registries-update-06

> (1) What type of RFC is being requested

The MPLS working group requests that this document is published as an
RFC on the Standards Track.  This is appropriate as it updates RFCs
8029 and 8611 both of which are Standards Track RFCs.  Furthermore, the
document requests IANA action applied to registries that need Standards
Action.

The document clearly indicates "Standards Action."

> (2) Please provide a Document Announcement Write-Up.
>
> Technical Summary:

This document updates RFC 8029 and RFC 8611 that both define IANA
registries for MPLS LSP Ping.  It also updates the description of the
procedures for the responses sent when an unknown or erroneous code
point is found.  The updates are to clarify and align this name space
with recent developments.

> Working Group Summary:

It has been somewhat hard to get WG review for what is a dry procedural
document.  However, after poking the group several times we got enough
review to know that the document is sound, and there were no negative
comments.

> Document Quality:

There's nothing here to implement.  The judge of the document is whether
IANA can understand it well enough to implement it, and whether the WG
agrees with the intention.  That seems to be achieved.

> Personnel:

Adrian Farrel (adrian@olddog.co.uk) is the Document Shepherd
Deborah Brungard (dbrungard@att.com) is the Responsible Area Director

> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd. If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.

I have reviewed this document several times and the authors made changes
to address my comments.  This version is ready for publication.

> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

As noted in the WG Summary, more reviews would have been reassuring, but
there was enough review for this type of document.

> (5) Do portions of the document need review from a particular or from
> broader perspective.  If so, describe the review that took place.

We sent the -04 revision to IANA for review.  They sent minor comments
and stated that the document was clear.

> (6) Describe any specific concerns or issues that the Document
> Shepherd has with this document that the Responsible Area Director
> and/or the IESG should be aware of?

No concerns.

> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why?

All authors confirmed. See https://mailarchive.ietf.org/arch/msg/mpls/jGlcQAYdKaiW7xbmrN36bcqeqm0/

> (8) Has an IPR disclosure been filed that references this document?

No IPR disclosed.

> (9) How solid is the WG consensus behind this document?

No dissenting voices.  A few voices of solid support, and a few voices
of minor support.

> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent?

No discontent.

> (11) Identify any ID nits the Document Shepherd has found in this
> document.

idnits warns about normative references to IANA registries. Otherwise
no issues.

> (12) Describe how the document meets any required formal review
> criteria.

None needed.

> (13) Have all references within this document been identified as
> either normative or informative?

Yes

> (14) Are there normative references to documents that are not ready
> for advancement or are otherwise in an unclear state?

None such.

> (15) Are there downward normative references references (see RFC
> 3967)?

None such (but see the answer to 11).

> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction?

This document Updates RFC 8029 and RFC 8611.
This is noted in the header.
The Abstract observes that this document updates those RFCs and
describes the nature of the update.
The Introduction expands on the details of the update.

> (17) 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 protocol extensions
> that the document makes are associated with the appropriate
> reservations in IANA registries. Confirm that any referenced IANA
> registries have been clearly identified. Confirm that newly created
> IANA registries include a detailed specification of the initial
> contents for the registry, that allocations procedures for future
> registrations are defined, and a reasonable name for the new registry
> has been suggested (see RFC 8126).

This document is all about IANA actions, and is clear. The IANA
Considerations section explicitly directs IANA and is consistent with
the explanations in the rest of the document.

There are no new registries, but there are changes to allocation
procedures for several registries. These are clearly described and all
registries are clearly indicated.

> (18) List any new IANA registries that require Expert Review for
> future allocations.

No Expert Review is needed for any parts of any of the registries.

> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal
> language.

No formal language used, no checks performed.

> (20) If the document contains a YANG module, has the module been
> checked with any of the recommended validation tools?

No YANG.