[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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


   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

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


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

   The IANA entity is the entity that, for the IETF, coordinates the
   evaluation of registration requests against policies as set by the

   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

   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

   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.


   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


   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

   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

   Stable and predictable policy development, allocation, publication
   are key requirements in any vision about the the Internet Registries

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*

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]