Hi, Please see one additional comment inline.
On Oct 23, 2025, at 2:25 PM, Mahesh Jethanandani <[email protected]> wrote: Hi Michael, This I-D was on the telechat agenda today, and I sought some clarification from Roman that might help move this draft forward. On Oct 20, 2025, at 1:01 PM, Michael Richardson <[email protected]<mailto:[email protected]>> wrote: Roman Danyliw via Datatracker <[email protected]<mailto:[email protected]>> wrote: ** Section 3.2 * Values from 0 to 65000 are allocated following a First-Come First- Served policy (Section 4.4 of [RFC8126]). Values in the ranges 0-10, 50-51, and 98-301 are already assigned; values in the ranges 11-49 and 52-97 MUST NOT be assigned. -- Why are 11-49 and 52-97 not just reserved? The text has been updated slightly. They are not assignable because they may have been used by OSes awhile ago. -- Per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, please remove the BCP14 key words from the IANA Considerations section. changed in -13. ** Section 3.2.2. What is the purpose of this section? The two registration policies for this registry are FCFS and experimental, neither of which have a designated expert. Yes, it's because the registration policy was split before. The comment here refers to the FCFS registration policy, which in RFC 8126 can be described as “light touch”. Meaning, IANA will apply very little overview to a FCFS registration request. As the RFC states: "There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment.” It further states that: "However, requests must include a minimal amount of clerical information, such as a point of contact (including an email address, and sometimes a postal address) and a brief description of how the value will be used.” All the rest of the information is optional. This particular I-D states in Section 3.2.2: "When the contents of the link type can contain an IPv4 or IPv6 header, then the octets between the beginning of the link type and the IP header needs to be clearly specified.” or "Specifications that are not publicly available, but which may be obtained via liaison agreements (such as to ITU-T, 3GPP, IEEE, etc.) are acceptable particularly if the specification document will be public eventually, but are discouraged." 3GPP specifications are publicly available. Please remove 3GPP from your list of examples. Thanks, Charles Text like this goes against the concept of “light touch”. IANA is in no position to determine if the registration request meets this or any other such criteria specified in the I-D. I would suggest that the authors take another look at the registration policy specified and determine if it is the right one for the document. If the intent is to keep FCFS, the guidance for registration should be minimal, as specified in the RFC 8126, and make it clear that the all the other information is optional to provide/obtain. Cheers. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected]<mailto:[email protected]> http://www.sandelman.ca/ | ruby on rails [ Mahesh Jethanandani [email protected]<mailto:[email protected]> _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
