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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 16 Feb 2021 20:40:33 -0800

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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 17 Feb 2021 14:53:07 +0800

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

> 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.
> 
> 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
> 
> 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
> 
> 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: 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
> 
> 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
> 
> 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
> 
> 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
> 
> 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.
> |
> 
> | 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.
> |
> 
> | 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
> 
> 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/mpls
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Feb 2021 07:51:59 -0800

Hi Loa,

>       8029) called 'Specification Required' and (RFC 8611) "RFC

I think so, thanks.

>       needed if a TLV or sub-TLV is not understood on pages 15 and 16 in

+1

>        changed to "RFC Required", the comment "Experimental RFC Required"

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

> Table 22 should look like this:

I think 7759 is the existing reference, not 7555.

>     |             |               |                 | document, section |

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

Sounds good.

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

Happy to help.

-Ben

---

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Feb 2021 00:45:44 +0800

Benjamin,

There is a little glitch in that RFC 8029 and RFC 8611 are not fully 
aligned.

See inline.

>        been removed and replaced with "First Come, First Served" code

NEW:
       o RFC 8029 was published before RFC 8126 and uses the old
         terminology for some registration procedures, e.g "Vendor
         Private Use". RFC 8611 was published after RFC 8126 and uses
         the new terminology, e.g. "Private Use". Both "Vendor Private
         Use" and "Private Use has been removed and replaced with "First
         Come, First Served" code points.
/Loa

--

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Feb 2021 09:06:38 -0800

>          Come, First Served" code points.

That looks accurate to me, and well phrased.
I was not entirely sure whether we need the full complexity of it given
that the text in question is in Section 6.2.3 that is scoped to a single
sub-registry, and that sub-registry (IIRC) only lists the one RFC (8611) as
reference, which hopefully means that it's currently only using a single
set of terminology.

But to be clear, I am not objecting to your NEW version :)

Thanks,

Ben

---

From: Loa Andersson <[email-masked]>
Date: Thu, 18 Feb 2021 12:55:11 +0800

Ben,

On 18/02/2021 01:06, Benjamin Kaduk wrote:
> But to be clear, I am not objecting to your NEW version:)
> 
> Thanks,
> 
You maybe right, I will think about iot a bit and might use this text in 
the Introduction, and tweak what I right in Section 6.2.3 RFC 8611 and 
sub-TLV 6 specific.

/Loa

--