-------- Original Message --------
Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA
Protocol Parameter Registries
Date: Tue, 11 Mar 2014 17:47:06 -0400
From: IAB Chair <[log in to unmask]>
To: IETF Announce <[log in to unmask]>, [log in to unmask]
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
_______________________________________________
Internetgovtech mailing list
[log in to unmask]
https://www.iab.org/mailman/listinfo/internetgovtech
|
