Skip to main content

Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry
draft-ietf-mpls-lsp-ping-registries-update-11

Yes

(Deborah Brungard)

No Objection

(Magnus Westerlund)

Note: This ballot was opened for revision 07 and is now closed.

Erik Kline
No Objection
Comment (2021-02-14 for -08) Sent
[[ comments ]]

[ section 1.2.1 ]

* I find it slightly odd that this section even exists.

  RFC 8126 section 1 seems to provide a definition for "namespace" and
  for "assignment"/"registration".  My reading of 8126s1's definition
  of namespace doesn't seem to quite match this document's use of namespace
  (seems more like the definition of registry without the existence of
  a definition for "sub-registry"), but maybe I haven't spent enough time
  thinking about it.

  If IANA review is fine with this text here, I've no objection.


[[ nits ]]

[ section 1 ]

* "there hav been" -> "there have been"
Murray Kucherawy
No Objection
Comment (2021-02-18 for -08) Sent
None of the URLs for [IANA-Sub-*] in the References section work.  Better check 'em.
Roman Danyliw
No Objection
Comment (2021-02-14 for -08) Sent
Thank you for writing this clarifying document.

** Section 3.1.  Per “All TLVs and sub-TLVs in the range 32768-65535 may be silently dropped, stepped over or an error message sent …”, is “stepped over” the same as ignored?

** Section 3.1.1.
-- “If the unrecognized TLV and sub-TLV is from … a Return Code of 2 … must be …”, should a normative MUST be used here?”

-- “If the unrecognized TLV and sub-TLV is from … the TLVs may be …”, should a normative MAY be used here?
Éric Vyncke
No Objection
Comment (2021-02-16 for -08) Not sent
Thank you for the work put into this document. 

Thanks to Adrian Farrel for writing about the WG consensus.

Using "namespace" for code points in a registry sounded weird to me; but it appears that it is used indeed by MPLS even for numbers.

Regards,

-éric
Barry Leiba Former IESG member
Yes
Yes (2021-02-03 for -07) Sent
At first I was puzzled by the move from Specification Required to RFC Required, until I looked in RFC 8209 at this:

   Values from "Specification Required" ranges MUST be registered with
   IANA.  The request MUST be made via an RFC that describes the format
   and procedures for using the code point; the actual assignment is
   made during the IANA actions for the RFC.

In other words, it's really always been RFC Required, but specified in an odd way and with a designated expert looking at it.

So, yes, this is a useful cleanup and clarification, and thanks for doing this.  And, as you have in the Acknowledgments, thanks to Michelle for working with you to make sure this came out right.
Deborah Brungard Former IESG member
Yes
Yes (for -07) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2021-02-16 for -08) Sent
§6 asks IANA to add a header mentioning the designated experts for several registries.  Some of those registries already mention the same 2 experts, but that is not the case for all.  I have 2 points around this:

(1) It doesn't seem like a good idea to include the experts' names in the document.  They will at some point change, and updating an RFC is too heavyweight for that change.

(2) I have no objections to naming the 2 experts as DEs for all registries, but that action should be approved by the IESG (and not simply mentioned in the document).


In summary, the explicit text about the experts' names should be removed.  Instead, there should be a Management Item for the IESG to approve them for the remaining registries.
Benjamin Kaduk Former IESG member
(was Discuss) No Objection
No Objection (2021-02-23 for -10) Sent for earlier
Thanks for getting things tidied up so I can resolve my Discuss points!
Magnus Westerlund Former IESG member
No Objection
No Objection (for -08) Not sent

                            
Robert Wilton Former IESG member
(was Discuss) No Objection
No Objection (2021-02-28 for -10) Sent
Thanks for addressing my discuss issue.

Regards,
Rob