| Network Working Group | O. Kolkman, Ed. |
| Internet-Draft | NLnet Labs |
| Intended status: Informational | November 04, 2013 |
| Expires: May 08, 2014 |
A Framework for the Evolution of IANA
draft-kolkman-iana-framework-00
This document provides a framework for describing the management of Internet Registries managed by IANA. It defines terminology describing the various roles and responsibilities associated with management of Internet Registry functions.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 08, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Internet registries hold identifiers consisting of constants and other well-known values used by Internet protocols. Such values define a common vocabulary that protocols understand when communicating with each other. For example, the TCP port number of "80" is globally understood to denote "http" service. Almost every protocol in existence makes use of registries in some form.
Internet registries are critical to the operation of the Internet. They are needed to record the definitive value and meaning of identifiers that protocols use when communicating with each other. Management of Internet registries must be operated in a predictable, stable and secure manner in order to ensure that protocol identifiers have consistent meanings and interpretations across all implementations and deployments.
Protocol identifier values can be numbers, strings, addresses, and so on. They are uniquely assigned for one particular purpose or use. They can be maintained in centrally maintained lists (such as, for instance, lists of cryptographic algorithms in use in a particular protocol) or hierarchically allocated and assigned by separate entities at different points in the hierarchy (such as for IP addresses and domain names). At the time of writing, IANA maintains hundreds of protocol parameter registries.
Stable and predictable assignment and registration of protocol identifiers for Internet protocols is of great importance to many stakeholders, including developers, vendors, and customers, as well as users of devices, software, and services on the Internet. These actors use and depend on registries and implicitly trust the registry system to be stable and predictable. The registry system is built on trust and mutual cooperation, not on mandates and policing.
Stability and consistency of Internet registries is achieved through the definition of appropriate and clear policies for making additions to or updating existing entries. Such policies must take into account the technical and operational properties of the technology that makes use of the registry. At the same time, it most be possible to evolve the systems and policies for managing registry contents as the Internet itself evolves.
The IETF and its predecessors have traditionally separated the publication mechanism of its protocol specifications, published in immutable RFCs, from the registries containing protocol parameters maintained by the so called Internet Assigned Numbers Authority (IANA). Dating back to the earliest days of the Internet, the specification publication function and the registry maintenance functions were tightly coupled: Jon Postel of ISI, USC was responsible for both the RFC publications and the IANA function.
To properly understand Internet Registry management it is important to distinguish between the who and the what. The IANA function is a specific set of responsibilities within the context of Internet Registries (the what); in this document we use the term IANA or IANA functions independent of the entity that implements the function. When we refer to the IANA entity (the who) we will do so explicitly. Also, unless otherwise mentioned, the IANA entity is the entity as is currently operated by ICANN.
This document provides a framework for describing the management of Internet Registries as they are currently implemented. It defines terminology describing the various roles and responsibilities associated with management of those roles.
This document can be read independent of [RFC6220] which documents the IETF's requirements specific to a subset of all current IANA function registries, namely the IETF protocol parameter registries. The framework presented herein is intended to be applicable to all registration functions that are currently considered to be IANA functions in terms generic enough to be applicable for the future.
The words must, should, shall, required, may and such should not be interpreted as normative language, but in their plain English meaning.
In this section we discuss the roles relevant to Internet Registries in terms of an abstract registry that is defined as part of a technical specification. Registry management involves 3 roles. First, a policy development role defines the purpose of the registry and the process and requirements for making additions or updates. Second, an implementation role refers to the the operational process itself for processing change requests to a registry and for publishing its contents. Finally, an oversight role refers to a high-level responsibility for ensuring that the other two roles are operating satisfactorily, stepping in if significant changes are needed in the policies or implementation of a registry. Each of these roles is described in more detail in the following subsections.
Description:
Registries may need to have additional values added, or an existing entry may need to be clarified or updated in some manner. The policy development role describes who can make updates or additions, what sort of review (if any) is needed, the conditions under which update requests would normally be granted or when they might not, etc. The entity performing this role may transfer its responsibility for part or all of the registry to others which may include the responsibility for defining policies.
Key Responsibilities:
The policy development role refers to governing policies that define how and when a registry can be updated or modified.
Primary Output:
A set of policies by which registries can be populated.
Example 1:
IETF acts in this role when "IANA Considerations" sections specify the creation of a new registry, specify initial entries, and specify a policy for adding additional entries to the registry in the future. For instance, RFC5226 [RFC5226] provides terminology that has proven useful within the IETF for describing common policies for managing its registries. Those terms include "Private Use", "Hierarchical allocation", "First Come First Served", "Expert Review", "Specification Required", "IESG Approval", "IETF Consensus", and "Standards Action". The IETF can uses this, and if needed other policies to define the policy through wich registries are populated.
Example 2:
The Domain Name System (DNS) protocol is hierarchical and the maintenance of the registries, and publication thereof, has been organized hierarchically. ICANN is currently responsible for change control at the 'root' which includes setting and maintaining policies for that root zone. Change control, policy control, and publication responsibility follows the DNS hierarchy. Although ICANN is responsible for the root zone, it is not responsible for all domains below the root. For example the IETF sets the policy for determining which names are allocated in the ietf.org zone. For ccTLDs the policies are set by the ccTLD registry in coordination with local regulator, and/or other national bodies.
Example 3:
IP address allocation and its policy development is hierarchical too. For instance, the IETF has defined an IPv6 address range called unicast addresses. For a fraction of that address range ICANN and the NRO have been delegated change control (see [RFC3513] section 4 for details). The change control is further delegated to the Regional Internet Registries (RIRs) which, guided by policies set by the regional communities, delegate change control even further e.g., to Local Internet Registries.
Not coincidentally, these 3 areas map to how IANA currently organizes its registration responsibilities: Domain Names, Number Resources, and Protocol Assignments.
The implementation role refers to the actual day-to-day operation of a registry in terms of servicing requests for registry additions or updates and publishing the contents of the registry. The implementation role carries out the policies as defined by the policy development role. The implementation role has two distinct key aspects: Evaluation Coordination, and the maintenance and publication of registry content. We discuss them separately.
Key Responsibility:
Coordinate, operate and process the timely evaluation of registration requests based on policies set by the Policy Role.
Primary Output:
A smoothly functioning system in which requests for registry updates come in, are evaluated and processed in a manner consistent with the policy guidance with the results recorded and published as appropriate. In some cases, the evaluation of requests is a straightforward task requiring little subjective evaluation, whereas in other cases evaluation is more complex and requires subject matter experts as defined by the relevant policy guidance.
Relation to other roles and activities:
The output of the evaluations is input to the process of assignment, delegation, and/or population of the registries (the other key responsibility for this role). The evaluations are performed based on the policies as defined by the Policy role. The coordination of the evaluation is different from the evaluation of a request itself: The Implementation Role handles the request for allocation or maintenance of a record and may delegate the actual evaluation to a third party.
Example 1:
As mentioned above, RFC5226 [RFC5226] provides terminology to define common policies used by IETF registries associated with IETF protocols. One of the policies that the Policy Role can impose for allocation from a registry is expert review. In this case a subject matter expert will evaluate the allocation request and determine whether an allocation will be made.
An alternative policy for allocation is the requirement for IETF Consensus. This is where the IETF has first, in its Policy Development role, set the policy and then, in its Policy Evaluation role implements it by determining consensus for a particular registry modification.
The IANA entity is the entity that, for the IETF, coordinates the evaluation of registration requests against policies as set by the IETF.
Example 2:
IP address allocation policy is developed bottom-up through the Regional Internet Registry (RIR) communities. The RIR communities perform the Policy Role while at the RIRs the Policy Evaluation Role is performed by the so called IP-Resource Analysts (or similar) that assess allocation requests agains the policies developed in the Region.
RIR staff often support the policy development process.
[OK: This assumes no policy development by the RIRs themselves, correct? Should this clarification that RIR staff has a supporting role for the development process, be refined?]
Example 3:
The evaluation of requests for the creation of new gTLDs as performed by ICANN staff and the evaluation of redelegation requests for existing Top Level Domains.
Key Responsibility:
The maintenance of the registries content: allocating or assigning parameters after positive evaluation and based on established policies, keeping appropriate record of transaction, and publishing the registries publicly.
Primary Output:
Easy and convenient access to registry contents, with additions and updates appearing in a timely manner.
Note:
The maintenance and publication are strictly mechanical functions. In practice the entity that performs those functions will perform some or all of the responsibilities of the Policy Evaluation Coordination. For instance, even verification that an application/ registration request is correct is a Policy Evaluation responsibility that should be explicitly assigned to the entity performing the IANA function by entity that performs the Policy Development Role.
Example 1:
ICANN publishes the protocol parameters registries on the IANA website. Recently the information the plain-text tables thereon have been augmented with tables in a structured machine-readable format. The coordination of the requirements for publication and the implementation of the technical systems is part of the publication and maintenance responsibility.
Example 2:
[EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of publication and maintenance]
Description:
The oversight role refers to a high-level responsibility for ensuring that the other two roles are operating satisfactorily, stepping in if significant changes are needed in the policies or implementation of a registry.
Key Responsibility:
Ensure on a long-term basis that policies and implementation registries are aligned in a way that supports the coherent long-term development and use of shared Internet resources. Coordinate with entities with similar roles for other registries.
Example 1:
The IAB is responsible for overseeing the policy development (in the context of the IETF, the standards process) and coordinates with the other entities that have the oversight role for Internet Registries.
Example 2:
The NRO is responsible for overseeing the policy development for global Internet address allocation policies.
[OK: these observations need refinement and reality checks]
Stable and predictable policy development, allocation, publication are key requirements in any vision about the the Internet Registries function.
For many registries there is a de-facto separation of the Policy Development and the Evaluation coordination that takes place at implementation. While this has never been an explicit requirement it seems that splitting those roles forces problems with unclarities in policies to surface. Besides, having the policy setting, oversight and evaluation roles separated prevents the evaluation role from being burdened with perceptions of favoritism and unfairness.
As discussed in Section Section 1.1 Internet Registries and the model discussed in this document are critical to elements of Internet security. However, this document simply discusses that model rather than changing it and consequently does not directly affect the security of the Internet.
This text [is being] developed within the IAB IANA strategy program. The ideas and many, if not most, text fragments came from or were inspired on comments from: Jari Arkko, Marcelo Bagnulo, Leslie Daigle, Russ Housley, John Klensin, Danny McPherson, Thomas Narten, Andrei Robachevsky and various meetings with IETF and other I* leadership.
This memo does not contain any specific instruction to any entity in the Implementer Role.
| [1] | Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. |
| [2] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [3] | McPherson, D., Kolkman, O., Klensin, J., Huston, G., Internet Architecture Board, "Defining the Role and Function of IETF Protocol Parameter Registry Operators", RFC 6220, April 2011. |
[Text between square brackets starting with initials are editor notes. Any other text between square brackets assumes an action by the RFC editor prior to publication as an RFC. In most cases this will be removal, sometimes a stylistic or editorial choices ore question is indicated] [This section and its subsections should be removed at publication as RFC]
This draft is the result of a set of brainstorms in the IAB IANA program, it does claim to reflect any consensus.
$Id: draft-kolkman-iana-framework-00.xml 17 2013-11-04 21:21:49Z olaf $