[mpls] Shepherd's pre-adoption-poll review of draft-andersson-lsp-ping-registries-update

["Adrian Farrel" <[e-mail]>]

Hi authors,

I'm the designated driver for your draft.

I know this is not last call, but there are a couple of things I think you
should sort out before we go for adoption.

---

This document needs to be Standards Track: it updates two existing Standards
Track documents.

---

Idnits points out...

> -- The draft header indicates that this document updates RFC8029, but the
>     abstract doesn't seem to mention this, which it should.
>
> -- The draft header indicates that this document updates RFC8611, but the
>     abstract doesn't seem to mention this, which it should.

Easy fix such as...

OLD
   This document updates some registries in the LSP Ping IANA name
   space.  The updates are mostly for clarification and to align this
   registry with recent developments.
NEW
   This document updates RFC 8029 and RFC 8611 that define IANA
   registries for MPLS LSP Ping.  The updates are mostly for clarification
   and to align this registry with recent developments.
END

---

Section 1 doesn't mention 8611, and it should. It should also make the
"updates 8029" statement.

OLD
   When RFC 8029 [RFC8029] where published it contained among other
   things updates to the "Multiprotocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" IANA name space
   [IANA-LSP-PING].

   The LSP Ping IANA registries were partly updated to match RFC 8029,
   but the there were some ambiguity in the RFC, that were reflected in
   the registries.

   This document updates two groups of registries.
NEW
   When RFC 8029 [RFC8029] where published it contained among other
   things updates to the "Multiprotocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" IANA name space
   [IANA-LSP-PING].

   RFC 8126 [RFC8126] updated the LSP Ping IANA registries to match 
   RFC 8029, but there were still some ambiguities, that were
   reflected in the registries.

   This document updates [RFC8029] and [RFC8126] by updating two
   groups of registries.
END

---

Section 3.
Not sure of the value of describing how the registry is now. Anyone who
cares (while reviewing the document) can look at the registries themselves.
And once this becomes an RFC, all you care about is the description of how
the registry is rebuilt.
(You don't have to make this change now).

---

3.1 has

   IETF does not prescribe how the Experimental Use and Private Use sub-
   TLVs are handled; however, if a packet containing a sub-TLV from the
   Experimental Use or Private Use ranges is received by an LSR that
   does not recognize the sub-TLV, an error message MAY be returned if
   the sub-TLV is from the range 31744-32767, and the packet SHOULD be
   silently dropped if it is from the range 64512-65535.

Is this a new normative definition of implementation behaviour? If so, this
document is doing more than updating the registries. That would be OK, but
you'd need to say so up front.

If this is simply a restatement of established fact, then perhaps you don't
need to say it here, but could use a reference. And then you wouldn't need
section 1.1.

---

Some text in Section 4 will be needed, but you can leave that for later if
you like.

---

I think the appendix text should be moved into Section 5. Appendices are
usually non-normative.

---

Thanks,
Adrian