Internet DRAFT - draft-kolkman-iana-framework
draft-kolkman-iana-framework
Network Working Group O. Kolkman, Ed.
Internet-Draft NLnet Labs
Intended status: Informational November 04, 2013
Expires: May 06, 2014
A Framework for the Evolution of IANA
draft-kolkman-iana-framework-00
Abstract
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.
Status of this Memo
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 06, 2014.
Copyright Notice
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.
Kolkman Expires May 06, 2014 [Page 1]
Internet-Draft IANA framework November 2013
1. Introduction
1.1. Internet Registries and Interoperability on the Internet
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.
1.2. The IANA function and Internet Registries
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.
Kolkman Expires May 06, 2014 [Page 2]
Internet-Draft IANA framework November 2013
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.
1.3. An IANA Framework
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.
2. Roles in Relation to Internet Registries.
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.
2.1. The Policy Development Role
Description:
Kolkman Expires May 06, 2014 [Page 3]
Internet-Draft IANA framework November 2013
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:
Kolkman Expires May 06, 2014 [Page 4]
Internet-Draft IANA framework November 2013
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.
2.2. The Implementation Role
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.
2.2.1. Implementation Role - Evaluation Coordination
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:
Kolkman Expires May 06, 2014 [Page 5]
Internet-Draft IANA framework November 2013
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.
2.2.2. Implementation Role - Maintenance and Publication of Registry
Content
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.
Kolkman Expires May 06, 2014 [Page 6]
Internet-Draft IANA framework November 2013
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]
2.3. The Oversight Role
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:
Kolkman Expires May 06, 2014 [Page 7]
Internet-Draft IANA framework November 2013
The NRO is responsible for overseeing the policy development for
global Internet address allocation policies.
3. Observations
[OK: these observations need refinement and reality checks]
3.1. Stable and Predictable implementation of the Internet Registries
Function
Stable and predictable policy development, allocation, publication
are key requirements in any vision about the the Internet Registries
function.
3.2. Separation of the roles
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.
4. Security Considerations
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.
5. Contributors and Acknowledgemetns
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.
6. IANA Considderations
This memo does not contain any specific instruction to any entity in
the Implementer Role.
7. References
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
Kolkman Expires May 06, 2014 [Page 8]
Internet-Draft IANA framework November 2013
[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.
Appendix A. Document Editing Details
[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]
Appendix A.1. Version Infromation
Appendix A.1.1. This version
This draft is the result of a set of brainstorms in the IAB IANA
program, it does claim to reflect any consensus.
Appendix A.1.2. TODO
o Possibly add a terminology section with terms like maintenance,
coordination, etc further explained.
Appendix A.2. Subversion information
$Id: draft-kolkman-iana-framework-00.txt 16 2013-11-04 21:16:33Z olaf $
Author's Address
Olaf Kolkman, editor
Stichting NLnet Labs
Science Park 400
Amsterdam, 1098 XH
The Netherlands
Email: olaf@nlnetlabs.nl
URI: http://www.nlnetlabs.nl/
Kolkman Expires May 06, 2014 [Page 9]
