Hi, In reading this was was interested to understand what changed from the presentation at the ietf (http://www.ietf.org/proceedings/89/slides/slides-89-igovupdate-0.pdf) and what stayed (more or less) the same? So what follows below is my take on the edits following the IETF session in order to understand how the feedback from the meeting was incorporated into this announcement. Principle 6 is almost there, but I still find myself voicing a note of dissent - in so far as it avoids mentioning copyright or any similar term relating to intellectual property but instead states their availability and the ability to include registry contents into other works without permission. My concern rests in observations related to previous handovers of this function in past times. Relating this to today, in my understanding were the IAB to exercise its ability under RFC6220 and re-designate a protocol parameter registry operator it is logically necessary for the previous registry operator to cooperate and synchronise the movement of registry to the new operator. It's hard to set this out this obligation as a principle, but any observer of the first few months of operation of Network Solutions taking over the registry role from the previous operator back then in the early 90's would've been painfully aware of a certain hiatus in service. Now all this could be finessed (in my view) by a stronger statement in principle 6 about the intellectual property of the contents of the protocol parameter registries, and the principle that while the registry operator is given license to modify these registries in line with the directions from the IETF, the contents of these (modified) registries remains the intellectual property of the IETF and not the property of the registry operator. But I have the sense that assertions of copyright and intellectual property appear to be concepts that are too "strong" for this enumeration of principles. Why is this? Kind regards, Geoff > > 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. > unchanged removed: The administration of the protocol parameters function by ICANN is working well for the Internet and the IETF. We are pleased with the publication and maintenance of the protocol parameter function and the coordination of the evaluation of registration requests through the IANA function provided by ICANN. > 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. unchanged > > 3. Any contemplated changes to the protocol parameter registry function > should respect existing Internet community agreements. (was: ... should use the current RFCs and model as the starting point.) > > 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. > more or less the same > 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. > unchanged > 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. change "its direction and stewardship" to "management" > > 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. > this is altered wording (used to read: "RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. We see no need to revisit or reconsider our current approach with regard to protocol parameters, including the ability to delegate operational responsibility for registries to other organizations."_ > 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. > unchanged > 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. > this was the second principle > [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 >