Internet Architecture Board(IAB)                                     IAB
Intended status: Informational                           O. Kolkman, Ed.
Expires: September 20, 2014                                   NLnet Labs
                                                          March 19, 2014

A Framework for Describing the Internet Assigned Numbers Authority(IANA)


   This document provides a framework for describing the management of
   Internet registries managed by the Internet Assigned Numbers
   Authority.  It defines terminology describing the various roles and
   responsibilities associated with management of Internet registry

   [ Note: This is a work in progress and documents the thoughts
   developed by the IAB in its IAB iana-evolution program ( http:// is the list which the IAB will be monitoring
   for the discussion of this draft.  See
   listinfo/internetgovtech for subscription details. ]

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

   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 September 20, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

IAB & Kolkman          Expires September 20, 2014               [Page 1]

Internet-Draft               IANA framework                   March 2014

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Internet Registries and Interoperability on the Internet    3
     1.2.  The IANA function and Internet Registries . . . . . . . .   4
     1.3.  Framework for Internet Registries . . . . . . . . . . . .   5
   2.  Roles in Relation to Internet Registries  . . . . . . . . . .   6
     2.1.  The Policy Role . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Evaluation Coordination Role  . . . . . . . . . . . . . .   7
     2.3.  Maintenance/Publication Role  . . . . . . . . . . . . . .   8
     2.4.  The Oversight Role  . . . . . . . . . . . . . . . . . . .   8
   3.  Key principles of the IANA framework  . . . . . . . . . . . .   9
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  On Separation of the roles  . . . . . . . . . . . . . . .   9
     4.2.  On Delegation . . . . . . . . . . . . . . . . . . . . . .  10
     4.3.  Accountability  . . . . . . . . . . . . . . . . . . . . .  10
     4.4.  On the Ability to create Internet Registries  . . . . . .  11
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Policy Examples . . . . . . . . . . . . . . . . . . . . .  11
       5.1.1.  IETF Protocol Parameter Registries  . . . . . . . . .  12
       5.1.2.  Number Resources  . . . . . . . . . . . . . . . . . .  12
       5.1.3.  Domain Names  . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Evaluation Coordination Role Examples . . . . . . . . . .  13
       5.2.1.  IETF Protocol Parameters  . . . . . . . . . . . . . .  13
       5.2.2.  Nubmer Resources  . . . . . . . . . . . . . . . . . .  13
       5.2.3.  Domain Names  . . . . . . . . . . . . . . . . . . . .  13
     5.3.  Maintenance and Publication of Registry Content . . . . .  13
       5.3.1.  IETF Protocol Parameters  . . . . . . . . . . . . . .  14
       5.3.2.  Alternative publication mechanisms  . . . . . . . . .  14
     5.4.  Oversight Examples  . . . . . . . . . . . . . . . . . . .  14
       5.4.1.  IETF Protocol Parameters  . . . . . . . . . . . . . .  14
       5.4.2.  Nubmer Resources  . . . . . . . . . . . . . . . . . .  14
       5.4.3.  Coordination - gTLDs vs special domain names  . . . .  14
       5.4.4.  Coordination - ccTLD Administration . . . . . . . . .  14
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  Contributors and Acknowledgemetns . . . . . . . . . . . . . .  15
   8.  IANA Considderations  . . . . . . . . . . . . . . . . . . . .  15
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  15

IAB & Kolkman          Expires September 20, 2014               [Page 2]

Internet-Draft               IANA framework                   March 2014

   Appendix A.  Document Editing Details . . . . . . . . . . . . . .  18
     A.1.  Version Information . . . . . . . . . . . . . . . . . . .  18
       A.1.1.  draft-iab-iana-framework-01 -> draft-iab-iana-
               framework-02  . . . . . . . . . . . . . . . . . . . .  18
       A.1.2.  draft-iab-iana-framework-00 -> draft-iab-iana-
               framework-01  . . . . . . . . . . . . . . . . . . . .  18
       A.1.3.  draft-kolkman-iana-framework-00 -> draft-iab-iana-
               framework-00  . . . . . . . . . . . . . . . . . . . .  19
       A.1.4.  draft-kolkman-iana-framework-00 . . . . . . . . . . .  19
       A.1.5.  TODO  . . . . . . . . . . . . . . . . . . . . . . . .  19
     A.2.  Subversion information  . . . . . . . . . . . . . . . . .  19

1.  Introduction

1.1.  Internet Registries and Interoperability on the Internet

   Internet registries are critical to the operation of the Internet,
   since they provide a definitive record of the value and meaning of
   identifiers that protocols use when communicating with each other.
   Almost every Internet protocol makes use of registries in some form.
   At the time of writing, the Internet Assigned Numbers Authority
   (IANA) maintains over one thousand protocol parameter registries.

   Management of Internet registries must be predictable, stable and
   secure, in order to ensure that protocol identifiers have consistent
   meanings and interpretations across all implementations and
   deployments.  For example, TCP port number 80 is globally understood
   to denote the "http" service.

   Internet registries hold identifiers consisting of constants and
   other well-known values used by Internet protocols.  These values can
   be numbers, strings, addresses, etc.  They are uniquely assigned for
   one particular purpose or use.  Identifiers can be maintained in
   within a central list (e.g. a list of cryptographic algorithms for
   use in a particular protocol) or they can be hierarchically allocated
   and assigned by separate entities at different points in the
   hierarchy (such as for IP addresses and domain names).

   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
   stakeholders 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; the use of the registries is
   voluntary and is not enforced by mandates or certification policies.
   While the use of registries is voluntary, it is noted that the
   success of the Internet (e.g. as an enabler of social and economic

IAB & Kolkman          Expires September 20, 2014               [Page 3]

Internet-Draft               IANA framework                   March 2014

   development) does create enormous pressure to utilize Internet
   protocols, and hence the protocol registries and their associated
   policies should be developed in a transparent manner which is open to
   all interested parties.

   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 registries.  At the same time, it must be
   possible to evolve the systems and policies for managing registry
   contents as the Internet itself evolves.  This description of
   responsibilities, entities, and functions within the scope of IANA
   serves as an aid for a structured approach to the potential evolution
   of the Internet Registries model.

1.2.  The IANA function and Internet Registries

   The Internet Engineering Task Force (IETF) and its predecessors have
   traditionally separated the publication mechanism of its protocol
   specifications, published in immutable Request for Comments (RFCs),
   from the registries containing protocol parameters.  The latter is
   maintained by a set of functions traditionally known collectively as
   the Internet Assigned Numbers Authority (IANA).  Dating back to the
   somewhat before the earliest days of the Internet, the specification
   publication function and the registry maintenance functions were
   tightly coupled: Jon Postel of the Information Sciences Institute
   (ISI) of the University of Southern California (USC) was responsible
   for both the RFC publications and the IANA function.  However, this
   tight coupling was never a requirement.  Indeed, today the RFC Editor
   and IANA function are contracted to different entities.  (The RFC
   publication process and the IANA protocol parameter policy
   development process and oversight remain closely coupled.  For
   example, the Internet Architecture Board (IAB) has oversight
   responsibilities over the both RFC Series and IANA [RFC2850].)

   One way to approach Internet Registry Management is to examine the
   what, why, who and how.  Internet Registries are tables with
   assignments and allocations of values (the 'what'), established by
   explicit directions contained within RFC documents (the 'why').  The
   framework described in this document applies to individual
   registries.  These registries are colloquially grouped into 3
   classes: Names, Numbers, and IETF Protocol Parameters.  The framework
   applies, with some nuance, to all registries, regardless of their
   class.  Within the context of this document the term "Internet
   registries" is used for those the registries that are currently
   organized as Domain Names, Number Resources, and IETF Protocol
   Parameter registries.

IAB & Kolkman          Expires September 20, 2014               [Page 4]

Internet-Draft               IANA framework                   March 2014

   One of the nuances that come into play is that some protocol
   parameters within these classes are "general use", and registry
   values assigned upon request to specific parties in accordance with
   the registry policy.  Such assignments are generally unique in
   nature, i.e. only one party is associated with each general- purpose
   registry entry.  Coordination (or automation) is necessary to provide
   uniqueness of assignments in each registry, but it is particularly
   important in the general purpose registries given the large number of
   assignments involved.  Several of the general purpose registries
   (DNS, IPv4, IPv6, ASNs) have been delegated to parties which are
   believed to be reasonably representative of the communities dependent
   upon those registries (e.g. ccTLD, and Regional Internet Registries).

   In this framework we identify major four roles: The Policy, The
   Oversight, the Evaluation Coordination, and Maintenance/Publication
   Roles (the latter two are both both implementation aspects).  The
   entities that perform each of these roles can be interpreted as 'the
   who' while the ways in which they carry out their roles determine
   'the how'.

   Within the IETF, the term "IANA" is often used to describe functions
   belonging to the Evaluation Coordination and Maintenance/Publication
   roles (as described below).  In this document we use the term IANA or
   IANA function(s) independent of the entities that implement those
   functions (the 'who').  Currently, according to the Memorandum of
   Understanding[RFC2860], the maintenance, implementation and
   publication of most of the IETF protocol parameter registries are
   performed by the Internet Corporation for Assigned Names and Numbers

1.3.  Framework for Internet Registries

   This document provides a framework for describing the management of
   Internet Registries as they are currently implemented.  In Section 2
   it defines terminology describing the various roles and
   responsibilities associated with those roles.  In Section 3 we
   enumerate a few key principles for the implementation of the
   framework.  In Section 4 we discuss the existing context for these
   principles and other features of the framework.  Finally, in
   Section 5 we provide a number of examples on how the framework
   applies today.  The examples demonstrate how the framework is applied
   to the situation today and its utility going forward.

   This document may be read independent of [RFC6220] and [RFC7020].
   Those documents identify the specific requirements for the IETF
   Protocol Parameter registries and the Internet Numbers Registry
   System.  As such, they provide context and examples for some of the
   subject matter of this document.  Those requirements apply only to

IAB & Kolkman          Expires September 20, 2014               [Page 5]

Internet-Draft               IANA framework                   March 2014

   those subsets of the current collection of IANA function Internet

   The authors are aware that this framework uses fewer, slightly
   different, and more generic terms to describe the various roles than
   [RFC6220].  [RFC6220] is a document that specifically pertains to the
   IETF protocol parameter registries.

   For instance, [RFC6220] section 2.1 "Protocol Parameter Registry
   Operator Role" describes the full set of responsibilities for the
   operator(s) of the IETF Protocol Parameter registries.  These
   responsibilities map to the Implementor aspects in Section 2.2 and
   Section 2.3 below.  [RFC6220] also describes the role of the IETF
   Administrative Oversight Committee (IAOC) and IETF Trust.  These
   bodies have specific responsibilities in the wider IETF and are
   responsible for contracting and IPR respectively.  Within this
   framework they should be considered part of the 'oversight role'.

   The words must, should, shall, required, may and such should not be
   interpreted as normative language as defined in [RFC2119], 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 an
   arbitrary technical specification.

   Registry management involves 4 roles.  First, a policy development
   role that defines the purpose of the registry and the process and
   requirements for making additions or updates.  Second, roles that
   refer to the operational process for processing change requests to a
   registry and for publishing its contents, both implementation
   aspects.  Finally, an oversight role that refers to a high-level
   responsibility for ensuring that the other two roles are operating
   satisfactorily and 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 Role


   Registries may need to have additional values added, or an existing
   entry may need to be removed, clarified, or updated in some manner.
   The Policy Role creates the registry and defines the policies that
   describes who can make updates or additions, what sort of review (if
   any) is needed, the conditions under which update requests would

IAB & Kolkman          Expires September 20, 2014               [Page 6]

Internet-Draft               IANA framework                   March 2014

   normally be granted or when they might not, the security requirements
   of these interactions, etc.  The entity performing this role may
   delegate its policy responsibilities for part or all of the
   parameters within the registry.  Consequently, in this document the
   word "policy" is used to refer to a specific course or principle of
   action for administration of a technical resource maintained within
   specific registries.

   Key Responsibilities:

   The Policy Role refers to the creation of the 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.

2.2.  Evaluation Coordination Role

   The Evaluation Coordination Role and the Maintenance/Publication Role
   (below) comprise 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.  These roles implement
   processes that abide by the policies as defined by the Policy Role.

   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
   are submitted and 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 as performed by the
   entity in the Maintenance/Publication Role (Section 2.3).  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 Evaluation Coordination Role

IAB & Kolkman          Expires September 20, 2014               [Page 7]

Internet-Draft               IANA framework                   March 2014

   handles the request for allocation or maintenance of a record and
   may, under guidance of and in coordination with the entity fulfilling
   the Policy Role, delegate the actual evaluation to a third party.

2.3.  Maintenance/Publication Role

   Key Responsibility:

   The maintenance of the registries' content: allocating or assigning
   parameters after positive evaluation and based on established
   policies, keeping appropriate record of transactions, and making the
   registries widely and freely available to the extend possible, to
   encourage protocol usage in conformance with the specifications.

   Primary Output:

   Easy and convenient access to registry contents, with additions and
   updates appearing in a timely manner.


   Registry maintenance and publication are strictly mechanical
   functions.  In practice the entity that performs those functions will
   often perform some or all of the responsibilities of the Evaluation
   Coordination Role.  For instance, verification that an application/
   registration request is correct is an Evaluation Coordination
   responsibility that can reasonably be explicitly assigned to the
   entity performing the Maintenance/Publication Role by the entity that
   performs the Policy Development Role while evaluation of technical
   content is usually delegated to technical experts.

2.4.  The Oversight Role


   The oversight role refers to a high-level responsibility for ensuring
   that the other three roles are operating satisfactorily.  Oversight
   involves stepping in if significant changes are needed in the
   policies, evaluation coordination, maintenance, or publication of a

   Key Responsibility:

   Ensure that policies and the implementation of 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.

IAB & Kolkman          Expires September 20, 2014               [Page 8]

Internet-Draft               IANA framework                   March 2014

   The oversight role is normally isolated from policy development.
   That said, the entity performing the Oversight Role may serve to
   resolve appeals related to policies or ratify developed policies.

3.  Key principles of the IANA framework

   The following key principles underscore the successful functioning of
   the framework:

   Separation of Roles:  The Policy, Evaluation Coordination,
      Maintenance/Publication, and Oversight roles should be separate or
      separable.  A clear distinction between the roles enhances the
      transparency and makes it clearer who is accountable to whom.

   Delegation:  It should be possible to delegate any of the roles for
      registries or parts thereof.

   Accountability and transparency:  The entities fulfilling the roles
      are accountable to the materially concerned parties and the wider
      community.  The entities fulfilling the Oversight Role are
      directly accountable to the wider community, although not all of
      the entities fulfilling the other roles must be.  By implication,
      the entities fulfilling Oversight Role must maintain the highest
      possible standards of transparency and be open to input and

   Stable and Predictable:  Stable and predictable implementation of the
      Internet registries function is important for establishing global

4.  Discussion

4.1.  On Separation of the roles

   For many registries there is a de-facto separation of the Policy Role
   and the Evaluation Coordination Role that takes place at
   implementation.  While this has never been an explicit requirement,
   it seems that splitting those roles can expose instances where
   policies lack of clarity, which provides helpful feedback to allow
   those policies to be improved.  In addition, having the Policy,
   Oversight and the Evaluation Coordination Roles separated prevents
   the risks of the Evaluation Coordination Role from being burdened
   with (perceptions of) favoritism and unfairness.

IAB & Kolkman          Expires September 20, 2014               [Page 9]

Internet-Draft               IANA framework                   March 2014

4.2.  On Delegation

   Most, if not all, protocol parameter registries were created by the
   IETF or its predecessors.  Today, most IETF protocols paramaters
   registries are maintained by the IANA at ICANN.  However, nothing in
   this framework prohibits the delegation of the Oversight, Policy,
   Evaluation Coordination, or Maintenance/Publication role (or any
   combination of these) of specific protocol parameter registries to
   other organizations.  In some circumstances, that may be desirable
   and allow improved registry management for the good of the global
   Internet community.

   Delegation of an IANA registry may be desirable for several reasons,
   including support for more inclusive registry policy development,
   distributing registry operations globally, and accommodating public
   policy considerations in registry management.  While delegation of an
   IANA registry in these situations can improve the registry service
   received by the global Internet community, it is not guaranteed to do
   so and hence it is incumbent upon the IAB to have clear guidelines
   for successful IANA registry delegation.  Such guidelines are out of
   scope for this document.

   Examples for registries where the responsibility for developing
   policy has been delegated in whole or in part include the assignment
   of domain names and the assignment of Internet Protocol (IP) address
   blocks (both considered policy issues by [RFC2860]), and the
   autonomous system (AS) number registry [RFC7020].  [RFC2860]
   demonstrates that that delegation can be very specifically bounded:
   "Note that (a) assignments of domain names for technical uses (such
   as domain names for inverse DNS lookup), (b) assignments of
   specialised address blocks (such as multicast or anycast blocks), and
   (c) experimental assignments are not considered to be policy issues
   [...]".  These special-purpose names and addresses are assigned in
   the same manner as protocol parameters except that coordination is
   needed during policy setting and actual assignment of the values.
   The oversight bodies may facilitate the coordination.  Also see
   Policy Examples 2 and 3 in Section 5.1.

4.3.  Accountability

   Any entity performing one of the roles defined in this framework is
   to be held accountable for its responsibilities.  Accountability of
   each entity needs to be expressed in terms of 'who' and 'how'; to who
   is the entity accountable and by which mechanisms is the entity being
   held accountable.  In other words registry policy development and
   registry operations need to be "accountable" to the affected

IAB & Kolkman          Expires September 20, 2014              [Page 10]

Internet-Draft               IANA framework                   March 2014

   In practice accountability mechanisms may be defined by memoranda of
   understanding or through contractual service level agreements (SLA)
   between implementing entities and the oversight body while the
   oversight bodies are being held accountable through community review
   mechanisms, for instance through recall and appeal processes.

   For example: For protocol parameters the general oversight over the
   IANA function is performed by the IAB as a chartered responsibility
   from [RFC2850] (also see Section 5.4).  In addition the IAOC, a body
   responsible for IETF administrational and financial matters,
   [RFC4071] maintains an SLA with ICANN, thereby specifying the
   operational requirements with respect to the coordination of
   evaluation, and the maintenance and publication of the registries.
   Both the IAB and the IAOC are accountable to the larger Internet
   community and are being held accountable through the IETF Nomcom
   process [BCP10].

   Accountability mechanisms can vary depending upon the actual
   distribution of responsibilities (i.e.: how much is separated, how
   much is delegated).

4.4.  On the Ability to create Internet Registries

   As with the IETF and the corresponding IANA Protocol registries,
   other standards bodies (and other institutions) have long histories
   of defining and creating registries and the parameters, tables, and
   other values that make them up.  Those normal practices may obviously
   extend to registries and their contents for use on the Internet.
   This document does not prescribe how those registries are governed.

   The (wider) IETF has the authority to create new IETF Protocol
   Parameter registries as described in [RFC6220].  The IETF also has
   the authority to create registries that pertain to the Domain Name
   System, but only for specify technical use [RFC6761].  Finally the
   IETF has the (exclusive) authority to make technical assignment for
   Number Resources out of the currently reserved address space
   ([RFC2860] and [RFC4291]).

5.  Examples

5.1.  Policy Examples

   Not coincidentally, the following 3 examples map to how the IANA
   registration functions are currently organized: IETF Protocol
   Parameter Registries, Number Resources and Domain Names.

IAB & Kolkman          Expires September 20, 2014              [Page 11]

Internet-Draft               IANA framework                   March 2014

5.1.1.  IETF Protocol Parameter Registries

   The IETF, through the IESG (see [RFC6220] section 2.3), acts in this
   role when in the "IANA Considerations" sections of its RFCs it
   specifies the creation of a new registry, specifies initial entries,
   and specifies a policy for adding additional entries to the registry
   in the future.  [RFC5226] provides guidance and 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 uses these and, if needed, other
   templates to define the policy through which registries are

5.1.2.  Number Resources

   IP address allocation and the associated policy development is
   distributed too.  For instance, the IETF has defined an IPv6 address
   range called unicast addresses.  For a fraction of that address range
   ICANN has been delegated change control (see [RFC3513] section 4 for
   details and [GlobAddrPol] for examples).  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.

5.1.3.  Domain Names

   The Domain Name System (DNS) protocol allows for hierarchical
   maintenance of the domain name registries, and publication thereof.
   ICANN is currently responsible for change control at the root zone
   which includes setting and maintaining policies for that zone.
   Change control, policy control, and publication authority follows the
   DNS hierarchy; although ICANN is the authoritative entity in the
   policy role for the root zone, it is not authoritative for all
   domains below the root.  For example the IETF sets the policy for
   determining which names are allocated in the zone.  For
   country code top-level domains (ccTLD) the policies are set by the
   ccTLD registry in coordination with local community, local
   regulator(s), and/or other national bodies.  Even the policy for
   assignment of names within the root is subject to nuances.  For
   instance, ICANN has reserved two letter top-level domains for the use
   as country and territory code Top Level Domains (ccTLDs).  The
   assignment of two-letter codes themselves (that may consecutively be
   used as DNS top-level domains) is done by ISO TC46/WG2 and are
   maintained by the ISO 3166 maintenance agency [ISO.3166.2013].  The
   selection of the operator of a ccTLD is currently governed by
   [RFC1591], also see Section 5.4.4.

IAB & Kolkman          Expires September 20, 2014              [Page 12]

Internet-Draft               IANA framework                   March 2014

5.2.  Evaluation Coordination Role Examples

5.2.1.  IETF Protocol Parameters

   As mentioned above, [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 Role,
   sets the policy to use its (policy) process to determine consensus
   for a particular registry modification.

   The IANA functions operator (currently operated by ICANN) is the
   entity that, for the IETF, coordinates the evaluation of registration
   requests against policies as set by the IETF.

5.2.2.  Nubmer Resources

   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 IP-Resource Analysts (or similar) that assess
   allocation requests against the policies developed in the Region.

   RIR staff often support or even initiate the policy development

5.2.3.  Domain Names

   Generic TLD delegation policy is today developed bottom-up through
   ICANN policy processes.  As specified in ICANN's bylaws [ADDREF], the
   ICANN Board of Trustees (BoT) oversees those process to perform the
   Policy Role.  The Policy Evaluation Role is performed under the
   responsibility of the ICANN BoT; staff and various panels evaluate
   applications for new generic top-level domains against the policies
   developed via the ICANN Policy Development Processes.  In addition,
   ICANN staff often support these policy development processes.

5.3.  Maintenance and Publication of Registry Content

IAB & Kolkman          Expires September 20, 2014              [Page 13]

Internet-Draft               IANA framework                   March 2014

5.3.1.  IETF Protocol Parameters

   ICANN, as the current IANA functions operator, publishes the protocol
   parameters registries on the IANA website.  Recently the plain-text
   tables on that website 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.

5.3.2.  Alternative publication mechanisms

   [EDITORIAL NOTE: Add Reverse DNS and WHOIS content as examples of
   publication and maintenance]

5.4.  Oversight Examples

5.4.1.  IETF Protocol Parameters

   The Internet Architecture Board (IAB) is responsible for overseeing
   the process used to create Internet Standards and coordinates with
   the other entities that have the oversight role for Internet

5.4.2.  Nubmer Resources

   Collectively, the communities served by the Regional Internet
   Registries oversee the policy development for global Internet address
   allocation policies.

5.4.3.  Coordination - gTLDs vs special domain names

   Collectively, the stakeholders involved in the ICANN policy
   development processes serve to oversee the policy development for
   generic TLD allocation processes.

   Other examples of oversight around IETF protocols include the
   coordination between the IAB and the ITU-T when the ENUM protocol
   started to use E.164 identifiers (telephone numbers)[RFC3245].
   Another example is the facilitation of coordination between the IETF
   protocol development process and reservations of labels at the top-
   level of the domain name space with RFC6761 as a recent example.

5.4.4.  Coordination - ccTLD Administration

   Some readers might have noticed that in the Policy Example in
   Section 5.1.3 the policy by which ccTLD operators are selected refers
   to RFC1591.  RFC1591 was specified and published by the IANA, while
   Internet was still an ARPA project and before ICANN and the IETF

IAB & Kolkman          Expires September 20, 2014              [Page 14]

Internet-Draft               IANA framework                   March 2014

   existed.  The IAB at the time maintained loose oversight of IANA but
   had a different set of responsibilities.  Should an update of RFC1591
   or a declaration of the historic nature of that document be needed
   then such action would most likely involve stewardship and
   coordination by the IAB and ICANN.

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

7.  Contributors and Acknowledgemetns

   This text has been [is being] developed within the IAB IANA evolution
   program.  The ideas and many, if not most, text fragments, and
   corrections came from or were inspired on comments from: Bernard
   Aboba, Jaap Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet,
   Brian Carpenter, David Conrad, Steve Crocker, John Curran, Alissa
   Cooper, Leslie Daigle, Elise Gerich, Russ Housley, John Klensin,
   Bertrand de La Chapelle, Danny McPherson, George Michaelson, Thomas
   Narten, Andrei Robachevsky, and Greg Wood.  Further inspiration and
   input was drawn from various meetings with IETF and other Internet
   community (RIRs, ISOC, W3C, IETF & IAB) leadership.

   It should not be assumed that those acknowledged endorse the text.

8.  IANA Considderations

   This memo does not contain any specific instruction to any entity in
   the Implementer Role.

9.  Informative References

   [BCP10]    Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
              and Recall Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, June 2004.

              Dawkins, S., "Nominating Committee Process: Earlier
              Announcement of Open Positions and Solicitation of
              Volunteers", BCP 10, RFC 5633, August 2009.

IAB & Kolkman          Expires September 20, 2014              [Page 15]

Internet-Draft               IANA framework                   March 2014

              "Board's Review Procedures for Global Internet Number
              Resource Policies Forwarded for Ratification by the ASO
              Address Council in Accordance with the ASO MoU", July

              International Organization for Standardization, "Codes for
              the representation of names of countries and their
              subdivisions, 3rd edition", ISO Standard 3166, November

   [RFC1591]  Postel, J., "Domain Name System Structure and Delegation",
              RFC 1591, March 1994.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2850]  Internet Architecture Board and B. Carpenter, "Charter of
              the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
              May 2000.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860, June 2000.

   [RFC3245]  Klensin, J. and IAB, "The History and Context of Telephone
              Number Mapping (ENUM) Operational Decisions: Informational
              Documents Contributed to ITU-T Study Group 2 (SG2)", RFC
              3245, March 2002.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC4071]  Austein, R. and B. Wijnen, "Structure of the IETF
              Administrative Support Activity (IASA)", BCP 101, RFC
              4071, April 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

IAB & Kolkman          Expires September 20, 2014              [Page 16]

Internet-Draft               IANA framework                   March 2014

   [RFC6220]  McPherson, D., Kolkman, O., Klensin, J., Huston, G., and
              Internet Architecture Board, "Defining the Role and
              Function of IETF Protocol Parameter Registry Operators",
              RFC 6220, April 2011.

   [RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
              RFC 6761, February 2013.

   [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
              Internet Numbers Registry System", RFC 7020, August 2013.

IAB & Kolkman          Expires September 20, 2014              [Page 17]

Internet-Draft               IANA framework                   March 2014

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]

A.1.  Version Information

A.1.1.  draft-iab-iana-framework-01 -> draft-iab-iana-framework-02

      Reordered paragraphs in the Discussion to align them with the
      order in the Key Principles.  Also changed the order because
      Accountability mechanisms may depend on the kinds of separation
      and delegation applied.

      Renamed the section titles for the examples from numbers to more
      descriptive titles.

      Significant rewording to improve readability based on feedback by
      Alissa Cooper.

      Added the paragraph talking about general use in Section 1.2 based
      on feedback from John Curran.

A.1.2.  draft-iab-iana-framework-00 -> draft-iab-iana-framework-01

      Significantly reordered the document by pulling the examples out
      of the descriptions of the roles and moving those to section
      Section 5.

      Split the "Implementation Role" into two different roles
      explicitly: Evaluation and Maintenance.  Both those roles can be
      headed under Implementation aspects.

      Refined text about te "what, who and why" and gave an overview in
      section Section 1.2

      Reworded the text in Section 4.2 to highlight that only the name
      assignment is the policy aspect that has been delegated.
      Similarly, in section Section 5.1 I tried to illustrate that even
      within the domain name assignment in the root there are delegated
      policies by introducing the ISO3166 reference.

IAB & Kolkman          Expires September 20, 2014              [Page 18]

Internet-Draft               IANA framework                   March 2014

      Added Oversight Example 4 in Section 5.4 as an example of policy
      that exists for over a few decades and for which an update would
      need coordination

      Nits and minor edits.

A.1.3.  draft-kolkman-iana-framework-00 -> draft-iab-iana-framework-00

      Added section "On Accountability" and "On Delegation".

      Refined some of the phrasing based on a thorough review by David

      Added a reference to [RFC7020] in Section 1.3 and clarified the
      informative rather than normative nature of the examples.

      Added section Section 3 and changed the name of section Section 4.

      Nits and minor edits.

A.1.4.  draft-kolkman-iana-framework-00

   This draft is the result of a set of brainstorms in the IAB IANA
   program, it does not claim to reflect any consensus.

A.1.5.  TODO

   o  [RFC EDITOR: BCP10 reference [BCP10] needs to be formatted
      correctly.  The annotation hack used to list multiple RFCs that
      make up BCP10 does not seem to work.]

A.2.  Subversion information

   $Id: iana-framework.xml 32 2014-03-19 11:17:02Z olaf $

Authors' Addresses

   Internet Architecture Board


IAB & Kolkman          Expires September 20, 2014              [Page 19]

Internet-Draft               IANA framework                   March 2014

   Olaf Kolkman (editor)
   Stichting NLnet Labs
   Science Park 400
   Amsterdam  1098 XH
   The Netherlands


IAB & Kolkman          Expires September 20, 2014              [Page 20]