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

[Benjamin Kaduk <[e-mail]>]

Hi Loa,

On Wed, Feb 17, 2021 at 02:53:07PM +0800, Loa Andersson wrote:
> Benjamin,
> 
> Tnx for review and suggestions.
> 
> Response to the Discuss. I'm a bit embarrassed over table 22, I don't
> what happened.
> 
> On 17/02/2021 12:40, Benjamin Kaduk via Datatracker wrote:
> > 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.
> 
> Yes you are right, this was a late change because taking the
> "Experimental Use" code point from "RFC Required" made sure that we did
> not have any collisions with code points in use.
> 
> Would the following be OK?
> 
> NEW
>       be silently dropped if not recognized.  The code points for
>       experimental use are taken from the ranges previously (RFC
>       8029) called 'Specification Required' and (RFC 8611) "RFC
>       Required".

I think so, thanks.

> > 
> > (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).
> 
> My mistake, will change  to:
> 
> NEW:
>       Mandatory and optional are used to indicate whether a response is
>       needed if a TLV or sub-TLV is not understood on pages 15 and 16 in
>       Section 3 of RFC 8029.

+1

> > 
> > (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.
> 
> If I read this correctly the one thing we need to do is to remove one
> bullet:
> 
> 
>     o  The "Specification Required" registration procedure has been
>        changed to "RFC Required", the comment "Experimental RFC Required"
>        has been removed.

I don't think that's quite everything; we also want.

OLD:
   o  The code points registration procedure "Vendor Private Use" has
      been removed and replaced with "First Come, First Served" code
      points.
NEW:
   o  The code points registration procedure "Private Use" has
      been removed and replaced with "First Come, First Served" code
      points.

On a quick look the other points should be okay, but I haven't had my
morning coffee yet :)

> 
> 
> > 
> > (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.
> 
> Table 22 should look like this:
> 
> NEW
> 
>     +-------------+---------------+-----------------+-------------------+
>     | Type        | TLV Name      | Reference       | Comment           |
>     +-------------+---------------+-----------------+-------------------+
>     | 0           | Reserved      | [RFC7555]       |                   |

I think 7759 is the existing reference, not 7555.

>     | 1-99        | Unassigned    | EQ              | EQ                |
>     | 100-104     | EQ            | EQ              | EQ                |
>     | 105-199     | Unassigned    |                 |                   |
>     | 200-202     | EQ            | EQ              | EQ                |
>     | 203-299     | Unassigned    |                 |                   |
>     | 300         | EQ            | EQ              | EQ                |
>     | 301-399     | Unassigned    |                 |                   |
>     | 400         | EQ            | EQ              | EQ                |
>     | 401-31739   | Unassigned    |                 |                   |
>     | 31740-31743 | Experimental  | This Document   | Reserved, not to  |
>     |             | Use           |                 | be assigned. This |
>     |             |               |                 | range is for sub- |
>     |             |               |                 | TLVs that require |
>     |             |               |                 | an error message  |
>     |             |               |                 | if not            |
>     |             |               |                 | recognized. [This |
>     |             |               |                 | document, section |
>     |             |               |                 | 3.1]              |
>     | 31744-64507 | Unassigned    |                 |                   |
>     | 64508-64511 | Experimental  | This document   | Reserved, not to  |
>     |             | Use           |                 | be assigned       |

(My generic comment about the "comment" column for the 64508-64511 range
would apply here as well, but please defer dealing with/responding about
that until you get to those comments.)

>     | 64512-65535 | Unassigned    |                 |                   |
>     +-------------+---------------+-----------------+-------------------+
> 
>                   Table 22: Sub-TLVs for TLV 27 Assignments
> 
> If you can ack today I will update before the IESG meeting. I will also
> according to the nits.

Sounds good.

> Thanks for a good review and the support in "Comment".

Happy to help.

-Ben

> > 
> > 
> > ----------------------------------------------------------------------
> >
> > 
> 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).
> > 
> > 
> > 
> > _______________________________________________ mpls mailing list 
> > [e-mail] https://www.ietf.org/mailman/listinfo/mpls
> > 
> 
> -- 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Bronze Dragon Consulting             phone: [phone]