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

["Chip Sharp (chsharp)" <[e-mail]>]

Dear Russ,

Thank you for sharing for review.  I will not be at IETF, but have some comments below for consideration.

I've noticed that a number of people involved in various discussions on this issue don't seem to understand the connection between the IETF and the IANA.  I'm concerned that this could result in collateral damage to functions important to IETF and IETF's role.  Therefore I support efforts at educating those involved in the current Internet Governance debate regarding the IETF's role and position regarding the IANA.  

In general I believe the principles below need to be strengthened to assert IETF's role regarding managing the Protocol Parameter registry.  The principles below seem to leave open the possibility that the IANA's operation of the Protocol Parameter Registry could be modified without the involvement of the IETF (or IRTF).

Question for clarification, is the Time Zone database operated under RFC2860?  I think so, but want to check.

Other comments below. 

Consider moving item 6 up to at least item 2 

On Feb 24, 2014, at 12:28 PM, IAB Chair <[e-mail]> wrote:

> 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

Item 6 and Item 4 with proposed modifications should be moved to the top of this list.  The principles should start out with a clear statement of the controlling documents and process for any changes.


> 1. The IETF protocol parameters function has been and continues to be
> capably provided by the Internet community.

Here and through the rest of the principles I recommend using the term "Protocol Parameters Registries" or "Protocol Parameter Registry functions" instead of "protocol parameters function".  This maps more closely to the terminology in RFC6220 and on IANA's web site and emphasizes the role as a registry.

> 
> 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.

This statement should be strengthened to be more assertive and should be moved to the top.
RFC2860 is not just a "good model to work from", it is the controlling document for the IANA's Protocol Parameter Registry operation along with RFC6220.  Item 4 should state that any contemplated changes to the IANA functions should respect current RFCs and agreements with the IETF (especially RFC 2860) and any changes to the operation of the Protocol Parameter Registry should be done through the IETF as per RFC 2860 and RFC 6220.  And don't forget about the IRTF.

Below is possible replacement text:

4. Contemplated changes to the protocol parameters registry function should respect agreements between IETF, IRTF and ICANN as per RFC2860, the IETF's processes and the relevant RFCs (e.g., RTF 6220).

The IANA protocol parameters registry function is working well, and as a result
wholesale changes to the role of the IETF, IRTF [and the IANA] vis a vis the function are not
warranted. The Memorandum of Understanding between IETF, IRTF and IANA [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." Modifications to the protocol parameters registry function should be made via the IETF process updating RFC 6220 and other relevant RFCs.  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.

I don't disagree with this statement, but it mixes the DNS and IP address functions with the Protocol Parameter Registry functions and could be confusing.

> 
> 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.

As mentioned previously, I recommend moving this up to the top.


> 
> [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


Thanks,
Chip



** I am employed by Cisco Systems, Inc, but these comments reflect my own opinion and not any position of Cisco. **