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

[Loa Andersson <[e-mail]>]

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

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

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



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

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

/Loa
> 
> 
> ----------------------------------------------------------------------
>
> 
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]