[ispcp] Fwd: [council] Guiding the Evolution of the IANA Protocol Parameter Registries

Tue Feb 25 22:45:57 UTC 2014

Begin forwarded message:

> From: Bruce Tonkin <Bruce.Tonkin at melbourneit.com.au>
> Subject: [council] Guiding the Evolution of the IANA Protocol Parameter Registries
> Date: February 25, 2014 at 3:01:16 PM CST
> To: "council at gnso.icann.org" <council at gnso.icann.org>
> 
> 
> For info:
> 
> The IETF is trying to document a set of principles for Evolution of the IANA Protocol Parameter Registries,  as part of input into the current Internet Governance debates:
> 
> From: IAB Chair 
> 
> To: IETF Announce
> 
> Subject: Guiding the Evolution of the IANA Protocol Parameter Registries
> 
> Existing IETF and IAB consensus concerning Internet registry functions
> and IANA are documented in a variety of RFCs and IAB communications
> [RFC2860,RFC6220,IAB1,IAB2].  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.
> 
> 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.
> 
> The IAB are planning to use part of the time in the IGOVUPDATE session at
> IETF 89 (6 March 2014, 17:00-18:30 GMT) for a discussion of such operating
> principles.  But we wanted to kick-start that discussion with a few
> thoughts about principles that the IAB and IETF have articulated in
> various documents already and some that have emerged over time but may
> not have been written down.  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.
> 
> This is a first cut of making the principles more explicit for which we
> seek your views.
> 
> Some of these 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
> 
> 1. The IETF protocol parameters function has been and continues to be
> capably provided by the Internet community.
> 
> The strength and stability of the function and its foundation within the
> Internet 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 parameters function
> needs be strong enough that they can be offered independently by the
> Internet 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 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.
> 
> 
> 3. The IETF protocol parameters function requires openness,
> transparency, and accountability.
> 
> Existing documentation of how the function is administered and overseen
> is good [RFC2860,RFC6220], but 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.
> 
> 
> 4. Any contemplated changes to the protocol parameters function should
> use the current RFCs and model as the starting point.
> 
> The protocol parameters function is working well, and as a result
> wholesale changes to the role of the IETF vis a vis the function are not
> warranted. The IETF/IANA Memorandum of Understanding [RFC2860] is a good
> model to work from in the event that other parties do want to contemplate
> changes. Put quite simply: evolution, not revolution.
> 
> 
> 5. 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.
> 
> 
> 6.  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.
> 
> 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.
> 
> [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
> 

PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ispcp/attachments/20140225/4d8117df/attachment.html>