[mpls] Benjamin Kaduk's Discuss on draft-ietf-mpls-lsp-ping-registries-update-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mpls-lsp-ping-registries-update-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-registries-update/



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


----------------------------------------------------------------------
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).