Subject: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries

From: IAB Chair <[email-masked]>
Date: Mon, 24 Feb 2014 12:28:45 -0500

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

---

From: S Moonesamy <[email-masked]>
Date: Mon, 24 Feb 2014 11:42:54 -0800

Hi Russ,

First of all, I would like to thank the IAB for 
requesting feedback before taking a position.

>involved in those discussions.

I suggest adding RFC 3172 to the above list of RFCs.

I suggest not mentioning Point 2.

>changes. Put quite simply: evolution, not revolution.

If I am not mistaken the stated position has been 
that the protocol parameters registry is an IETF 
matter.  I would suggest caution before even 
considering any contemplated 
changes.    Evolution tends to have unintended consequences. :-)

>process and the use of resulting protocols.

The word "stewardship" has been overused for a while.  According to RFC 6220:

    "the IETF asserts authority and responsibility for
    the management of all of its protocol parameters and their
    registries, even while it generally remains isolated from the
    selection of particular values once a registration is approved."

Point 6 might sent the wrong message.

>operational responsibility for registries to other organizations.

The responses to the NOIs mention "IANA Functions".  From the ICANN bylaws:

   "The mission of The Internet Corporation for Assigned Names and Numbers
    ("ICANN") is to coordinate, at the overall level, the global Internet's
    systems of unique identifiers, and in particular"

   "1. Coordinates the allocation and assignment of the three sets of unique
       identifiers   for the Internet, which are"

      "c. Protocol port and parameter numbers."

The above is inconsistent with what is written in 
RFC 6220.  According to an (old) contract ( 
http://www.icann.org/en/about/agreements/iana/iana-contract-17mar03-en.htm ):

   "C.2.1.1 DoC NTIA has a requirement for a Contractor to maintain the
    operation of the Internet by performing the IANA functions. In performance
    of this purchase order, the Contractor shall 
furnish the necessary personnel,
    material, equipment, services, and facilities 
(except as otherwise specified),
    to perform the following IANA requirements."

      "C.2.1.1.1 Coordinate the assignment of technical protocol parameters
       – This function involves the review and assignment of unique values to
       various parameters (e.g., operation codes, port numbers, object
       identifiers, protocol numbers) used in various Internet protocols.
       This function also includes the 
dissemination of the listings of assigned
       parameters through various means (including on-line publication) and the
       review of technical documents for consistency with assigned values."

It wopuld be good if the IETF considers the above 
as it is inconsistent which its stated position.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Feb 2014 11:42:00 +1300

On 25/02/2014 08:42, S Moonesamy wrote:
> Hi Russ,
> 
> First of all, I would like to thank the IAB for requesting feedback
> before taking a position.

Agreed. My feedback is that I support the text as written. I'm sure
some small improvements can be made, but IMHO it's good enough
already.

   Brian