Hi Michael, Regarding the Change Controller role for the new IANA registry, I believe the IETF (and thus the IESG) should be the Change Controller for registry elements created by this IETF consensus document, such as the registry definition and entries for reserved, private use, or deprecated values.
However, the initial allocations being grandfathered in from external projects are a separate case. Since these definitions did not originate within the IETF community, I am uncertain if it is appropriate for the IETF/IESG to assume the role of Change Controller/registrant for those specific entries. As per RFC 8126, IANA must know who is authorized to manage changes or deprecations for a registered value. I suggest we avoid listing the IETF/IESG as the Change Controller for those external allocations. I defer to Amanda and the IANA team for their guidance on the correct procedure here. Thanks, Ketan On Tue, Dec 2, 2025 at 4:34 AM Michael Richardson <[email protected]> wrote: > > Ketan Talaulikar <[email protected]> wrote: > > Michael/Guy, I would suggest the easiest way to proceed is that one > of you > > (or anyone else involved from the projects involved) becomes the > Change > > Controller for the actual registered entries in the initial > allocation > > - > > okay, so I've never seen a person listed in an RFC like this. > Why can't it be the IESG, and the IESG delegates? > > > basically you become the registrants. For further requests, the DEs > would > > enter the registrant(s) as the change controllers for their > respective > > entries. > > sure. > > > Amanda, do you see an issue with this or do you have a better > suggestion? > > Once that is done, this is ready to ship. > > ?tell me? > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
