Dear Authors, Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about this document:
https://datatracker.ietf.org/doc/html/draft-ietf-grow-bmp-tlv-20 I'm guessing the plans for this are still in flux, but it should be noted that the IANA Considerations section is currently a little scrambled: 1) It starts with "This document requests IANA to rename of the "BMP Peer Up Message TLVs" registry defined by BMP Peer Up Message Namespace [RFC9736] into "BMP Peer Up and Peer Down TLVs" and the definition of one new registry "BMP Route Monitoring TLVs"." However, it then asks us to create two more registries, along with making other changes. Something like this intro would be fine: "This document asks IANA to rename, create, change registration procedures and available values for, and add assignments to registries." 2) It would be helpful for us to have this IANA Considerations section divided into subsections. These should at least include a subsection for renaming a registry, one subsection for each registry that's being created, and at least one that covers identical changes being made to a set of registries (possibly one subsection for each type of change, or one subsection for each set of related changes, as long as the grouping is clear). 3) There's some ambiguous language here. I don't know what "The top most bit of each registry will be reserved to the E-bit" means. Is the top-most bit value 0 or value 65535? "Reserved" has a specific meaning in IANA Considerations sections (i.e., set aside and not available for assignment). If a value is being assigned for the E-bit, please use the word "assigned." If you want to see the description "Reserved for the E-Bit" in the registry, and this should genuinely be considered a reservation instead of an assignment, please provide the exact text you want to see. 4) Another issue is that it's not at all clear what you actually want new registries to look like. For example, should "Type = 1: Support for Sequence TLV. The value field is defined in Section 5.6.2" be rendered as A) 1 | Support for Sequence TLV | RFC XXXX, Section 5.6.2 or B) 1 | Support for Sequence TLV. The value field is defined in RFC XXXX, Section 5.6.2. | RFC XXXX or C) 1 | Sequence TLV | RFC XXXX, Section 5.6.2 It would be useful to provide tables with field names here. 5) This text suggests that above, the option C is correct: "Finally, for the same registries, this document requests IANA to allocate the codepoints for Timestamp TLV (TBD1), Sequence Number TLV (TBD2) and Extended Flags TLV (TBD3). It is recommended that the code points are assigned consistently to the registry seeded in this document (ie. Timestamp TLV = 3 , etc.)" However, it also refers to "the registry seeded in this document," while this document is creating and initializing three registries. 6) In "Flag = 7: X Flag (Extended Flags)", please change "7" to "7 (suggested)". 7) Are you sure that the BMP Timestamp Types registry should use hex, when all the other registries use decimal? No issue for IANA, just checking that this is intentional. 8) Please specify the registry group name for the new registries. This could be a new or existing group. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at [email protected]. For more information about IANA Considerations section requirements, please see https://www.iana.org/help/protocol-registration Best regards, Amanda Baber IANA _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
