Existing IETF and IAB consensus concerning protocol parameter registry functions and IANA are documented in a variety of RFCs and IAB communications [RFC2860,RFC6220,IAB1,IAB2]. Since these functions and IANA are likely to be the subject of discussion in a number of venues outside the IETF over the coming months and years, the IAB sought community feedback about operating principles to use in these discussions. This note incorporates the comments from the mail list discussion and the IGOVUPDATE session at IETF 89. The IAB recognizes significant community support for these principles. Some of these principles might seem a bit generic, but it is difficult to predict the nature of future discussions in which IETF and IAB leaders might find themselves, so generality helps in that regard. On behalf of the IAB, Russ Housley IAB Chair = = = = = = = = Principles Guiding the Evolution of the IANA Protocol Parameter Registries These principles must be taken together. Ordering is not significant. 1. The IETF protocol parameter registry function has been and continues to be capably provided by the Internet technical community. The strength and stability of the function and its foundation within the Internet technical community are both important given how critical protocol parameters are to the proper functioning of IETF protocols. We think the structures that sustain the protocol parameter registry function needs be strong enough that they can be offered independently by the Internet technical community, without the need for backing from external parties. And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made. 2. The protocol parameter registry function requires openness, transparency, and accountability. Existing documentation of how the function is administered and overseen is good [RFC2860,RFC6220]. Further articulation and clarity may be beneficial. It is important that the whole Internet community can understand how the function works, and that the processes for registering parameters and holding those who oversee the protocol parameter function accountable for following those processes are understood by all interested parties. We are committed to making improvements here if necessary. 3. Any contemplated changes to the protocol parameter registry function should respect existing Internet community agreements. The protocol parameter registry is working well. The existing Memorandum of Understanding [RFC2860] defines "the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force." Any modifications to the protocol parameter registry function should be made using the IETF process to update RFC 6220 and other relevant RFCs. Put quite simply: evolution, not revolution. 4. The Internet architecture requires and receives capable service by Internet registries. The stability of the Internet depends on capable provision of not just IETF protocol parameters, but IP numbers, domain names, and other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. Thus we expect the role of the IETF in standards development, architectural guidance, and allocation of certain name/number parameters to continue. IP multicast addresses and special-use DNS names are two examples where close coordination is needed. The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries. We fully understand the need to work together. 5. The IETF will continue management of the protocol parameter registry function as an integral component of the IETF standards process and the use of resulting protocols. RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. The IAB, on behalf of the IETF, has the responsibility to define and manage the relationship with the protocol registry operator role. This responsibility includes the selection and management of the protocol parameter registry operator, as well as management of the parameter registration process and the guidelines for parameter allocation. 6. The protocol parameters registries are provided as a public service. Directions for the creation of protocol parameter registries and the policies for subsequent additions and updates are specified in RFCs. The protocol parameters registries are available to everyone, and they are published in a form that allows their contents to be included in other works without further permission. These works include, but are not limited to, implementations of Internet protocols and their associated documentation. An important observation: The administration of the protocol parameter registry functions by ICANN is working well for the Internet and the IETF. We are pleased with the publication and maintenance of the protocol parameter registries and the coordination of the evaluation of registration requests through the IANA function provided by ICANN. [RFC2860] http://www.rfc-editor.org/rfc/rfc2860.txt [RFC6220] http://www.rfc-editor.org/rfc/rfc6220.txt [IAB1] http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-final.pdf [IAB2] http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.