Skip to main content

A Framework for the Evolution of the Internet Assigned Numbers Authority(IANA)

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Olaf Kolkman
Last updated 2014-01-03
RFC stream Internet Architecture Board (IAB)
Stream IAB state (None)
Consensus boilerplate Unknown
IAB shepherd (None)
Internet Architecture Board(IAB)                                     IAB
Internet-Draft                                           O. Kolkman, Ed.
Intended status: Informational                                NLnet Labs
Expires: July 05, 2014                                  January 03, 2014

     A Framework for the Evolution of the Internet Assigned Numbers


   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

   [ is the list which the IAB will be
   monitoring for the discussion of this draft.  See
   mailman/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 July 05, 2014.

Copyright Notice

   Copyright (c) 2014 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 (
   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.

IAB & Kolkman            Expires July 05, 2014                  [Page 1]
Internet-Draft               IANA framework                 January 2014

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 done 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, the Internet
   Assigned Numbers Authority (IANA) maintains over one thousand
   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
   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.

   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.

1.2.  The IANA function and Internet Registries

IAB & Kolkman            Expires July 05, 2014                  [Page 2]
Internet-Draft               IANA framework                 January 2014

   The Internet Engineering Task Force (IETF) and its predecessors have
   traditionally separated the publication mechanism of its protocol
   specifications, published in immutable 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 and 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 instance,one of the
   responsibilities of the IAB is oversight over the RFC Series and IANA
   [RFC2850] )

   To properly understand Internet registry management it is important
   to distinguish between the who, the what, and the how.  The Internet
   or IANA Registries are tables with assignments and allocations of
   values (the What). These Internet registries are colloquially
   subdivided into 3 classes: Names, Numbers, and IETF Protocol
   Parameters.  Normally we use the term IANA for the set of functions
   with specific responsibilities within the context of Internet
   Registries.  In this document we use the term IANA or IANA
   function(s) independent of the entities that implement those
   functions (the Who). Currently the maintenance, implementation and
   publication of most of the IETF protocol Registries is performed by
   the Internet Corporation for Assigned Names and Numbers (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 those roles.

   Although this document can be read independent of [RFC6220] and
   [RFC7020] -- which document the requirements specific to a subset of
   all current IANA function Internet registries, namely the IETF
   protocol parameter registries and the Internet Numbers Registry
   System respectively --, those RFCs provide context and example of the
   subject matter of this document.  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 examples herein are intended to
   illustrate the applicability of the framework and are of informative

IAB & Kolkman            Expires July 05, 2014                  [Page 3]
Internet-Draft               IANA framework                 January 2014

   rather than of normative nature.

   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 a
   arbitrary technical specification.  Registry management involves 3
   roles.  First, a policy development role that defines the purpose of
   the registry and the process and requirements for making additions or
   updates.  Second, an implementation role that refers to the
   operational process for processing change requests to a registry and
   for publishing its contents.  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 Development 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 development 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 normally be granted or when they might not, the
   security requirements of these interactions, etc.  The entity
   performing this role may delegate 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 the creation of the governing
   policies that define how and when a registry can be updated or

   Primary Output:

   A set of policies by which registries can be populated.

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

   Example 1:

IAB & Kolkman            Expires July 05, 2014                  [Page 4]
Internet-Draft               IANA framework                 January 2014

   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

   Example 2:

   The Domain Name System (DNS) protocol allows for hierarchical
   maintenance of the 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 authoritative 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.

   Example 3:

   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.

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 implements processes that abide by 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 these
   aspects separately.

IAB & Kolkman            Expires July 05, 2014                  [Page 5]
Internet-Draft               IANA framework                 January 2014

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
   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 (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, under guidance of or in coordination with the
   policy role, delegate the actual evaluation to a third party.

   Example 1:

   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
   Development role, set the policy and then, in its Policy Evaluation
   role implements it by determining consensus for a particular registry

   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.

   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 IP-Resource Analysts (or similar) that assess

IAB & Kolkman            Expires July 05, 2014                  [Page 6]
Internet-Draft               IANA framework                 January 2014

   allocation requests against the policies developed in the Region.

   RIR staff often support or even initiate the policy development

   Example 3:

   Generic TLD delegation policy is 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.

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 transactions, and making the
   registries publicly available.

   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 Policy
   Evaluation Coordination.  For instance, verification that an
   application/registration request is correct is a Policy Evaluation
   responsibility that can reasonably be explicitly assigned to the
   entity performing the IANA function by the entity that performs the
   Policy Development Role.

   Example 1:

   ICANN, as the 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

IAB & Kolkman            Expires July 05, 2014                  [Page 7]
Internet-Draft               IANA framework                 January 2014

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

   The oversight role is normally isolated with respect to the actual
   policy development.  That said, it may serve to resolve appeals or
   ratify developed policies.

   Example 1:

   The Internet Architecture Board (IAB) is responsible for overseeing
   the policy development in the context of the IETF's standards process
   and coordinates with the other entities that have the oversight role
   for Internet Registries.

   Example 2:

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

   Example 3:

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

   Other examples of coordination around IETF protocols are coordination
   with the ITU-T when the ENUM protocol started to use E.164
   identifiers (telephone numbers)[RFC3245].  Another example is the
   coordination between the IETF protocol development process and

IAB & Kolkman            Expires July 05, 2014                  [Page 8]
Internet-Draft               IANA framework                 January 2014

   reservations of labels at the top-level of the domain name space with
   RFC6761 as a recent example.

3.  Key principles of the IANA framework

   Any IANA framework should be implementable with the following key
   principles in mind.

   Stable and Predictable: Stable and Predictable implementation of the
      Internet Registries Function is important for establishing global

   Accountability and transparency: Oversight, implementation, and
      policy development roles are accountable to the materially
      concerned parties and the wider community.  Not all roles may be
      directly accountable to the wider community, in practice the
      oversight role has responsibility for such stewardship.

   Separation of Roles: The oversight, policy development, and
      implementation roles should be separate or separable.  A clear
      distinction between the roles enhances the transparency and makes
      it clearer who is accountable to who.

   Delegation: It should be possible to delegate any of the roles
      (policy, implementation, or oversight) for registries or parts

4.  Discussion

4.1.  On 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 can surface a lack of clarity in
   the policies.  In addition, having the policy setting, oversight and
   evaluation roles separated prevents the evaluation role from being
   burdened with perceptions of favoritism and unfairness.

4.2.  On 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 practice accountability mechanisms will 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

IAB & Kolkman            Expires July 05, 2014                  [Page 9]
Internet-Draft               IANA framework                 January 2014

   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].  In addition the IAOC [RFC4071] maintains an SLA with
   ICANN.  Both the IAB and the IAOC are accountable to the larger
   Internet community and are being held accountable through the IETF
   Nomcom process [BCP10].

4.3.  On Delegation

   Most, if not all, protocol parameter registries were created by the
   IETF or its predecessors.  Today, most IETF protocols registries are
   maintained by the IANA at ICANN. However, nothing in this framework
   prohibits the delegation of the oversight, policy, or maintenance
   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.

   Examples of IANA registries already delegated delegated in whole or
   in part include the Domain Name System (DNS) registry [RFC2860] the
   Internet Protocol (IP) address space registry and the autonomous
   system (AS) number registry [RFC7020].

   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.

4.4.  On the Authority 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."

   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 July 05, 2014                 [Page 10]
Internet-Draft               IANA framework                 January 2014

   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 pace

4.5.  On the relation to RFC6220

   The authors are aware that this framework uses less, 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 Role in Section 2.2 above.
   [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'.

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

6.  Contributors and Acknowledgemetns

   This text has been [is being] developed within the IAB IANA strategy
   program.  The ideas and many, if not most, text fragments, and
   corrections came from or were inspired on comments from: Jari Arkko,
   Marcelo Bagnulo, Mark Blanchet, David Conrad, John Curran, Leslie
   Daigle, Russ Housley, John Klensin, Danny McPherson, Thomas Narten,
   Andrei Robachevsky, Greg Wood, and various meetings with IETF and
   other Internet community (RIRs, ISOC, W3C, IETF & IAB) leadership.

7.  IANA Considderations

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

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

IAB & Kolkman            Expires July 05, 2014                 [Page 11]
Internet-Draft               IANA framework                 January 2014

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

              "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

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

   [RFC6220]  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.

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

Appendix A.  Document Editing Details

IAB & Kolkman            Expires July 05, 2014                 [Page 12]
Internet-Draft               IANA framework                 January 2014

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

Appendix A.1.1.  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.

Appendix A.1.2.  draft-kolkman-iana-framework-00 -> draft-iab-iana-

      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.

Appendix A.1.3.  TODO

   o  Possibly add a terminology section with terms like maintenance,
      coordination, etc further explained.

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

   o  Review and potentially add clarifying text on the use of 'Internet
      Registries' (IP and AS numbers, Domain Names, and IETF Protocol

Appendix A.2.  Subversion information

   $Id: draft-iab-iana-framework-00.txt 26 2014-01-03 16:56:37Z olaf $

Authors' Addresses

   Internet Architecture Board

IAB & Kolkman            Expires July 05, 2014                 [Page 13]
Internet-Draft               IANA framework                 January 2014

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

IAB & Kolkman            Expires July 05, 2014                 [Page 14]