Subject: [mpls] Shepherd review of draft-ietf-mpls-lsp-ping-registries-update-03

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Aug 2020 22:26:35 +0100

Hi,

I am reviewing this document as Document Shepherd. My comments (below)
are mainly nits, but there are rather a lot of them. In order that the 
WG can get a good view of the document in last call, I think you should
post an update (it should be fairly mechanical) and then I can start the
last call.

Thanks,
Adrian

===

Bullet points

You have a variety of styles. I think you can harmonise:

- All bullet points to begin with a capital letter
- If any bullet point in a list ends with a full stop, then all should

---

Correct capitalisation for section headings.
I see issues with 3, 3.1, 3.1.1, 3.2.1, 6.2

---

Section 1

s/RFC 8029 use the words/RFC 8029 uses these words/

---

Section 1

OLD
   This document drops the words "mandatory and
   "optional" and the text is changed to focus on what should be done.
NEW
   This document updates RFC 8029 to drop the words "mandatory" and
   "optional", and the text is changed to focus on what should be done.
END

---

Section 2

OLD
   In the Return Codes [IANA-RC] [IANA-RC] registry
NEW
   In the Return Codes registry [IANA-RC]
END

However, for clarity since this sub-bullet does not reflect a change to
the registry, maybe...

NEW
   Note that in the Return Codes registry [IANA-RC]
END

---

Section 2

s/will be found/are found/

---

3.1 Title

s/General principles the/General Principles for the/

---

3.1

   The following principles are valid for all the LSP Ping TLV and sub-
   TLV IANA registries

Missing punctuation
However, I think this is not quite right. While the registries track
this information, they are not responsible for the protocol rules. So
how about:

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

---

3.1

   o  all TLVs and sub-TLVs in the range 32768-65535 may be silently
      dropped if they are not recognized

When you have a "may" you need to give the alternative. In fact, you do 
this in the paragraph that follows, so how about

   o  all TLVs and sub-TLVs in the range 32768-65535 may either be
      silently dropped or stepped over if they are not recognized

---

3.1

s/The other block in the range/The other block has the range/
s/dropped, possibly stepped over, if/dropped or stepped over if/
s/are found in [RFC8126]/are found in [RFC8126]./

---

3.1

Section 2 has a useful final paragraph that points at Section 6.1.

I think that 3.1 could benefit from a pointer in a similar way.

---

3.1 and 3.1.1

You have a slight tonal disconnect...

3.1 has

   o  all TLVs and sub-TLVs in the range 32768-65535 may be silently
      dropped if they are not recognized

and

   The other block in the range
   from 32768 to 65535 for TLVs and sub-TLVs that may be silently
   dropped, possibly stepped over, if not recognized.

While 3.1.1 has

   o  If the unrecognized TLV or sub-TLV is from the Experimental Use
      range (64508-64511) or from the Private Use range (64512-65535)
      the TLVs SHOULD be silently ignored and possibly be stepped over.

Is the use of normative language appropriate/necessary in 3.1.1? I
suspect not. That would make it easy to bring everything into line by
changing 3.1.1 to read...

   o  If the unrecognized TLV or sub-TLV is from the Experimental Use
      range (64508-64511) or from the Private Use range (64512-65535)
      the TLVs will be silently ignored or possibly stepped over.

---

3.1.1

s/IETF does not/The IETF does not/

---

3.2

s/outline/describe/

---

3.2.1

      The first set are for the range
      that requires a response if the TLV or sub-TLV is not recognised;
      the sedond set are for the range there the TLV or sub-TLV that MAY
      be silently dropped if not recognized.

I don't think this is the right place for normative language. Lower case
"may" would be fine here.
s/sedond/second/

---

3.2.1

s/the list that capture/the list that captures/
s/Use are/Use, are/

---

4.

s/are using/use/
s/below are intended to align/below align/

---

4.1

I think?

OLD
   Mandatory and optional is used to indicate whether are response ir
   needed or if at TLV or sub-TLV is not understoond page 14 and 15 in
   Section 3 of RFC 8029.
NEW
   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.
END

---

4.1

   In Section 3.8 of RFC 8029 "mandatory" is used in the same way.  The
   first two paragraphs of this section are now updated to read as
   follows:

      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 greater than or equal to 32768 (i.e., with the high-
      order bit equal to 1) are either not supported by the
      implementation or parsed and found to be in error.

The old text was...

   The following TLV is a TLV that MAY be included in an echo reply to
   inform the sender of an echo request of mandatory TLVs either not
   supported by an implementation or parsed and found to be in error.

I thought that "mandatory" was consistent with the top bit being clear.
The fact that this TLV is optional doesn't change the fact that the TLV
is "mandatory". So I think your text should read...

      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.

---

4.2

The title of this section is about updates to RFC 8611. The text is
worded in terms of updates to the registry not the RFC.

I think you should change the text consistent with the title (which
would also be consistent with the rest of Section 4).

Should be easy enough because it's just Section 13.4.1 of RFC 8611

---

5.

s/related to the/related to, the/

---

6.

   IANA is requested to update the LSP Ping name space as described in
   this document.

Not sure what the "LSP Ping name space" will mean to IANA.

Meanwhile in Section 6.1 you have...

   This section details the updated registration procedures and
   allocations for Message Type, Reply Mode and Return Codes registries.

Are you sure that IANA will know which registries these are? If I go to
https://www.iana.org/protocols and search for "Message Type" I find 76
matches.

So maybe, if Section 6 can set the context in terms of "the family of
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping 
Parameters" then 6.1 can talk about those three registries but using
quotes about their names (as "Message Type", "Reply Mode", and "Return
Codes" registries).

Alternatively (or as well) you can use the references that you have at 
the top of Section 8.1 to add clarity.

---

6.1

I feel that this section would be clearer for IANA and historians if 
you could break it into three subsections, one for each registry. I know
this would require a little duplication of text, but it would be a
better read.

It would also resolve the complication/contradiction with 0 in the
Return Codes registry.

---

6.1

   | 1-247   | No changes to the existing      |                       |
   |         | assignments                     |                       |

I believe you could make it clearer to IANA that this is an action you
want them to take, not text you want them to put in the registry.

---

6.2

s/([IANA-Sub-9] is/([IANA-Sub-9]) is/

---

6.2

Can you help IANA by being more explicit about the changes you want them
to make? I think there is the main "TLVs" registry to be updated and 
then there are a number of sub-TLV registries to be updated as well. I
see:
- 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
And explicitly not:
- Sub-TLVs for TLV Type 9

---

Are you sure that this document doesn't also update the RFCs that 
created some of the sub-TLV registries? For example, RFC 7759 creates
the "Sub-TLVs for TLV Type 27" registry and includes text that says:

   Registration procedures for Sub-TLVs from ranges 0-16383 and
   32768-49161 are by Standards Action.  Ranges 16384-31743 and
   49162-64511 are through Specification Required (Experimental RFC
   Needed).

---

6.3 

s/([IANA-Sub-9] is not changed./([IANA-Sub-9] is not changed).

---

6.3

   +-------------+-------------------------------+---------------------+
   | Type        | TLV name                      | Reference           |
   +-------------+-------------------------------+---------------------+
   | 0           | Reserved                      | This document       |
   | 1-31739     | [any]                         | No changes to the   |
   |             |                               | current registry    |
   | 37140-37143 | Reserved for Experimental Use | This document       |
   | 31744-32767 | FCFS                          | This document       |
   | 32768-64507 | [any]                         | No changes to the   |
   |             |                               | current registry.   |
   | 64508-64511 | Reserved for Experimental Use | This document       |
   | 64512-65535 | FSFC                          | This document       |
   +-------------+-------------------------------+---------------------+

Similar things: 
- Please make it clear what you want IANA to do. In particular that you
  don't want IANA to reproduce the "[any]" text in the registries
- I think it is worth listing the registries just like in 6.2

---

7.

s/Eatlake/Eastlake/

---

From: Loa Andersson <[email-masked]>
Date: Sat, 29 Aug 2020 10:48:15 +0800

Adrian,

Tnx, very useful. One small point. 

Sent from my iPhone

> On 29 Aug 2020, at 05:26, Adrian Farrel <[email-masked]> wrote:
> 
> <snip>

In your comments on section 6.  
> quotes about their names (as "Message Type", "Reply Mode", and "Return

I thought this was done  by listing the “in scope registries” in section 1. 

I can repeat the information in section 6 if necessary. 

/Loa
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 29 Aug 2020 09:51:32 +0100

The point with this issue is that you can't expect IANA to read and process the whole document. They go straight to the IANA considerations section and work on that. It should, as far as possible (which is usually all the way) be a stand-alone section.

A

-----Original Message-----
From: Loa Andersson <[email-masked]> 
Sent: 29 August 2020 03:48
To: [email-masked]
Cc: [email-masked]; mpls <[email-masked]>
Subject: Re: [mpls] Shepherd review of draft-ietf-mpls-lsp-ping-registries-update-03

Adrian,

Sent from my iPhone

/Loa