Hi Ketan, Michael, all,
If the RFC were the listed reference for those registrations, it could be awkward to list another organization as the change controller. How would updates be approved? However, in this case, it looks like we’re not listing the RFC as the reference for the affected registrations. Instead we’ll be pointing to different locations at tcpdump.org, so it’s not clear to us that listing the IETF as the change controller would be appropriate (although we can really only address practical issues here, and would have to defer to the IESG re: what is/isn’t appropriate). Our primary concern here is whether the change controller is reachable. We generally prefer listing an organization to listing a person (the contact information tends to be more stable), but if that’s nonsensical for tcpdump.org-associated registrations in a change-request-approval context, a person would be fine. For the registrations in the new registry that are going to refer to the RFC rather than tcpdump.org, we’d expect to list the IETF (although we do have examples to the contrary, at least for a few older media type registrations). Thanks, Amanda From: Ketan Talaulikar <[email protected]> Date: Tuesday, December 2, 2025 at 2:57 AM To: Michael Richardson <[email protected]> Cc: Amanda Baber <[email protected]>, Mahesh Jethanandani <[email protected]>, "Joe Clarke (jclarke)" <[email protected]>, Guy Harris <[email protected]>, The IESG <[email protected]>, "[email protected]" <[email protected]>, opsawg-chairs <[email protected]>, opsawg <[email protected]> Subject: Re: [Ext] Re: [OPSAWG]Ketan Talaulikar's Discuss on draft-ietf-opsawg-pcaplinktype-12: (with DISCUSS and COMMENT) 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
