<<<
Chronological Index
>>> <<<
Thread Index
>>>
[ispcp] Fwd: [council] Guiding the Evolution of the IANA Protocol Parameter Registries
- To: ispcp@xxxxxxxxx
- Subject: [ispcp] Fwd: [council] Guiding the Evolution of the IANA Protocol Parameter Registries
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Tue, 25 Feb 2014 16:45:57 -0600
- List-id: ispcp@xxxxxxxxxxxxxx
- References: <263EE96C7DADD44CB3D5A07DBD41D0E8629A4F85@bne3-0001mitmbx.corp.mit>
- Sender: owner-ispcp@xxxxxxxxxxxxxx
Begin forwarded message:
> From: Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
> Subject: [council] Guiding the Evolution of the IANA Protocol Parameter Registries
> Date: February 25, 2014 at 3:01:16 PM CST
> To: "council@xxxxxxxxxxxxxx" <council@xxxxxxxxxxxxxx>
>
>
> 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.)
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|