Guiding the Evolution of the IANA Protocol Parameter Registries

1. Guiding the Evolution of the IANA Protocol Parameter Registries Russ Housley 6 March 2014

2. Need for Community Discussion • Existing IETF and IAB consensus concerning Internet registry functions and IANA are documented in a variety of RFCs and IAB communications • Since registry 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 is seeking community feedback about operating principles to use when they find themselves involved in those discussions

3. Existing Documents • RFC2860 http://www.rfc-editor.org/rfc/rfc2860.txt • RFC6220 http://www.rfc-editor.org/rfc/rfc6220.txt • IAB Response to NTIA NOI http://www.iab.org/wp-content/IAB-uploads/2011/03/2009-06-08-IAB-NTIA-NOI-final.pdf • IAB Response to NTIA FNOIhttp://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf

4. Move Toward Explicit Principles • While dealing with these issues the IAB has consistently approached the issues from a set of (implicit) principles • Since the registry functions are subject of discussion in various fora, the IAB has tried to make these operating principles explicit and seeks to confirm these with the community

5. Generality • 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

6. Focus on IETF Values • What we are interested in is an articulation of what the IETF community values • What other parties (ICANN, RIRs, governments, etc.) value when they think about registry functions is interesting, but we want to focus this discussion on the IETF and not those other parties

7. Six Principles • The six principles were shared with the IETF community ten days ago • The intent was to “send text” so that we could have a productive discussion at this session

8. The IETF protocol parameters function has been and continues to be a capably provided by the Internet community. • The administration of the protocol parameters function by ICANN is working well for the Internet and the IETF. • The IETF protocol parameters function requires openness, transparency, and accountability.

9. Any contemplated changes to the protocol parameters function should use the current RFCs and model as the starting point. • The Internet architecture requires and receives capable service by Internet registries. • The IETF will continue its direction and stewardship of the protocol parameters function as an integral component of the IETF standards process and the use of resulting protocols.

10. Discussion !!!