    Internet Architecture Board (IAB)                        R. Housley, Ed.
    Request for Comments: 7500                                Vigil Security
    Category: Informational                                  O. Kolkman, Ed.
    ISSN: 2070-1721                                         Internet Society
                                                                  April 2015

                          Principles for Operation of
             Internet Assigned Numbers Authority (IANA) Registries

    Abstract

       This document provides principles for the operation of Internet
       Assigned Numbers Authority (IANA) registries.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This document is a product of the Internet Architecture Board (IAB)
       and represents information that the IAB has deemed valuable to
       provide for permanent record.  It represents the consensus of the
       Internet Architecture Board (IAB).  Documents approved for
       publication by the IAB are not a candidate for any level of Internet
       Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc7500.

    Copyright Notice

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

    Housley & Kolkman             Informational                     [Page 1]

    RFC 7500                         TITLE*                       April 2015

    Table of Contents

       1. Introduction ....................................................2
       2. Principles for the Operation of IANA Registries .................3
       3. Discussion ......................................................4
          3.1. Ensuring Uniqueness, Stability, and Predictability .........4
          3.2. Public .....................................................4
          3.3. Open and Transparent .......................................4
          3.4. Accountable ................................................5
       4. Security Considerations .........................................5
       5. Informative References ..........................................6
       IAB Members at the Time of Approval ................................7
       Contributors and Acknowledgements ..................................7
       Authors' Addresses .................................................7

    1.  Introduction

       The Internet Engineering Task Force (IETF) and its predecessors have
       traditionally separated the publication of protocol specifications in
       immutable Request for Comments (RFCs) and the registries containing
       protocol parameters.  Traditionally, the registries are maintained by
       a set of functions known collectively as the Internet Assigned
       Numbers Authority (IANA).  Dating back to the earliest days of the
       Internet, specification publication and the registry operations were
       tightly coupled: Jon Postel of the Information Sciences Institute
       (ISI) of the University of Southern California (USC) was responsible
       for both RFC publication and IANA registry operation.  This tight
       coupling had advantages, but it was never a requirement.  Indeed,
       today the RFC Editor and IANA registry operation are provided by
       different entities.

       Internet registries are critical to the operation of the Internet,
       because 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 IANA maintains more than two thousand
       protocol parameter registries.

       Internet registries hold protocol identifiers consisting of constants
       and other well-known values used by Internet protocols.  These values
       can be numbers, strings, addresses, and so on.  They are uniquely
       assigned for one particular purpose or use.  Identifiers can be
       maintained in a central list (such as a list of cryptographic
       algorithms) or they can be hierarchically allocated and assigned by
       separate entities at different points in the hierarchy (such as IP
       addresses and domain names).  To maximize trust and usefulness of the
       IANA registries, the principles in this document should be taken into
       consideration for centralized registries as well as hierarchically

    Housley & Kolkman             Informational                     [Page 2]

    RFC 7500                         TITLE*                       April 2015

       delegated registries.  In hierarchically delegated registries,
       entries nearest to top level have broad scope, but lower-level
       entries have narrow scope.   The Internet Architecture Board (IAB)
       will encourage support for these principles in all delegations of
       Internet identifiers.

       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 creates enormous pressure
       to use Internet protocols and the identifier registries associated
       with them.

       This document provides principles for the operation of IANA
       registries, ensuring that protocol identifiers have consistent
       meanings and interpretations across all implementations and
       deployments, and thus providing the necessary trust in the IANA
       registries.

    2.  Principles for the Operation of IANA Registries

       The following key principles underscore the successful functioning of
       the IANA registries, and they provide a foundation for trust in those
       registries:

       Ensure Uniqueness:  The same protocol identifier must not be used for
          more than one purpose.

       Stable:  Protocol identifier assignment must be lasting.

       Predictable:  The process for making assignments must not include
          unexpected steps.

       Public:  The protocol identifiers must be made available in well-
          known locations in a manner that makes them freely available to
          everyone.

       Open:  The process that sets the policy for protocol identifier
          assignment and registration must be open to all interested
          parties.

       Transparent:  The protocol registries and their associated policies
          should be developed in a transparent manner.

       Accountable:  Registry policy development and registry operations
          need to be accountable to the affected community.

    Housley & Kolkman             Informational                     [Page 3]

    RFC 7500                         TITLE*                       April 2015

    3.  Discussion

       The principles discussed in Section 2 provide trust and confidence in
       the IANA registries.  This section expands on these principles.

    3.1.  Ensuring Uniqueness, Stability, and Predictability

       Protocol identifier assignment and registration must be unique,
       stable, and predictable.  Developers, vendors, customers, and users
       depend on the registries for unique protocol identifiers that are
       assigned in a stable and predictable manner.

       A protocol identifier may only be reassigned for a different purpose
       after due consideration of the impact of such a reassignment, and if
       possible, with the consent of the original assignee.

       Recognizing that some assignments involve judgment, such as those
       involving a designated expert [RFC5226], a predictable process does
       not require completion in a predetermined number of days.  Rather, it
       means that no unexpected steps are introduced in the process of
       making an assignment.

    3.2.  Public

       Once assigned, the protocol identifiers must be made available in a
       manner that makes them freely available to everyone without
       restrictions.  The use of a consistent publication location builds
       confidence in the registry.  This does not mean that the publication
       location can never change, but it does mean that it must change
       infrequently and only after adequate prior notice.

    3.3.  Open and Transparent

       The process that sets the policy for protocol identifier assignment
       and registration must be open to all interested parties and operate
       in a transparent manner.

       When a registry is established, a policy is set for the addition of
       new entries and the updating of existing entries.  While making
       additions and modifications, the registry operator may expose
       instances where policies lack clarity.  When this occurs, the
       registry operator should provide helpful feedback to allow those
       policies to be improved.  In addition, the registry operator not
       being involved in establishing registry policy avoids the risks
       associated with (perceptions of) favoritism and unfairness.

    Housley & Kolkman             Informational                     [Page 4]

    RFC 7500                         TITLE*                       April 2015

       Recognizing that some assignments involve judgment, such as those
       involving a designated expert [RFC5226], the recommendations by
       designated experts must be visible to the public to the maximum
       extent possible and subject to challenge or appeal.

    3.4.  Accountable

       The process that sets the policy for IANA registries and the
       operation of the registries must be accountable to the parties that
       rely on the protocol identifiers.  Oversight is needed to ensure
       these are properly serving the affected community.

       In practice, accountability mechanisms for the registry operator may
       be defined by contract, memoranda of understanding, or service level
       agreements (SLAs).  An oversight body uses these mechanisms to ensure
       that the registry operator is meeting the needs of the affected
       community.  The oversight body is held accountable to the affected
       community by vastly different mechanisms, for instance recall and
       appeal processes.

       For protocol parameters [RFC6220], the general oversight of the IANA
       function is performed by the IAB as a chartered responsibility from
       [RFC2850].  In addition, the IETF Administrative Oversight Committee
       (IAOC), a body responsible for IETF administrative and financial
       matters [BCP101], maintains an SLA with the current registry
       operator, the Internet Corporation for Assigned names and Numbers
       (ICANN), thereby specifying the operational requirements with respect
       to the coordination, maintenance, and publication of the protocol
       parameter 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].

       For the Internet Number Registries [RFC7249], oversight is performed
       by the Regional Internet Registries (RIRs) as described RFC 7020
       [RFC7020].  The RIRs are member-based organizations, and they are
       accountable to the affected community by elected governance boards.
       Furthermore, per agreement between the RIRs and ICANN, the policy
       development for the global IANA number registries is coordinated by a
       community-elected number council and subject to process review before
       ratification by the ICANN Board of Trustees [ASOMOU].

    4.  Security Considerations

       Internet Registries are critical to elements of Internet security.
       The principles described in this document are necessary for the
       Internet community to place trust in the IANA registries.

    Housley & Kolkman             Informational                     [Page 5]

    RFC 7500                         TITLE*                       April 2015

    5.  Informative References

       [ASOMOU]   ICANN, "ICANN Address Supporting Organization (ASO) MoU",
                  October 2004,
                  <http://archive.icann.org/en/aso/aso-mou-29oct04.htm>.

       [BCP10]    Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection,
                  Confirmation, and Recall Process: Operation of the
                  Nominating and Recall Committees", BCP 10, RFC 7437,
                  January 2015, <http://www.rfc-editor.org/info/bcp10>.

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

                  Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for
                  IPR Trust", BCP 101, RFC 4371, January 2006.

                  <http://www.rfc-editor.org/info/bcp101>

       [RFC2850]  Internet Architecture Board and B. Carpenter, Ed.,
                  "Charter of the Internet Architecture Board (IAB)", BCP
                  39, RFC 2850, May 2000,
                  <http://www.rfc-editor.org/info/rfc2850>.

       [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,
                  <http://www.rfc-editor.org/info/rfc2860>.

       [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
                  IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                  May 2008, <http://www.rfc-editor.org/info/rfc5226>.

       [RFC6220]  McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,
                  Huston, G., Ed., and Internet Architecture Board,
                  "Defining the Role and Function of IETF Protocol Parameter
                  Registry Operators", RFC 6220, April 2011,
                  <http://www.rfc-editor.org/info/rfc6220>.

       [RFC7020]  Housley, R., Curran, J., Huston, G., and D. Conrad, "The
                  Internet Numbers Registry System", RFC 7020, August 2013,
                  <http://www.rfc-editor.org/info/rfc7020>.

       [RFC7249]  Housley, R., "Internet Numbers Registries", RFC 7249, May
                  2014, <http://www.rfc-editor.org/info/rfc7249>.

    Housley & Kolkman             Informational                     [Page 6]

    RFC 7500                         TITLE*                       April 2015

    IAB Members at the Time of Approval

       Jari Arkko (IETF Chair)
       Mary Barnes
       Marc Blanchet
       Joel Halpern
       Ted Hardie
       Joe Hildebrand
       Russ Housley
       Eliot Lear
       Xing Li
       Erik Nordmark
       Andrew Sullivan
       Dave Thaler
       Brian Trammell

    Contributors and Acknowledgements

       This text has been developed within the IAB IANA Evolution Program.
       The ideas and many 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,
       John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson,
       George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew
       Sullivan, Dave Thaler, Brian Trammell, and Greg Wood.  Further
       inspiration and input was drawn from various meetings with IETF and
       other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership.

       Please do not assume those acknowledged endorse the resulting text.

    Authors' Addresses

       Russ Housley
       918 Spring Knoll Drive
       Herndon, VA 20170
       USA
       EMail: housley@vigilsec.com

       Olaf Kolkman
       Science Park 400
       Amsterdam  1098 XH
       The Netherlands
       EMail: kolkman@isoc.org

    Housley & Kolkman             Informational                     [Page 7]