Hi Ketan, all,
There is a change controller problem here, and we missed it: There is only one point that I consider at a level of DISCUSS - the Change Authority. I believe, IESG/IETF cannot be the change authority for allocations that are being grandfathered-in from open source projects (e.g., libpcap, tcpdump, etc.). IESG/IETF will also not like to be the change controller for new allocations - that should be the person(s) requesting the allocation. Refer https://www.rfc-editor.org/rfc/rfc8126.html#section-2.3 [rfc-editor.org] - someone from the IANA team can correct me if I'm wrong. I don’t actually know what the criteria are for listing a party other than the IETF as the change controller for registrations made by an IETF-stream RFC. It happens, but RFC 8126 (which calls the IETF the “default” here) doesn’t talk about when it can/should. Section 2.3 of RFC 8126 talks about change control for the registry itself, which would cover, e.g., updating its registration procedures or adding an extra column. These changes would require an IETF-stream RFC, so we wouldn’t expect the experts to have a change control role. For the actual registrations: I agree, we would expect that the registrants would be the change controllers. The expert’s role is to approve change requests initiated/authorized by the change controller. (The exception being contact updates, which IANA typically verifies without bringing in the experts, unless there’s some issue we need them to advise on.) Thanks, Amanda
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
