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

Internet Architecture Board (IAB)                        R. Housley, Ed.
Request for Comments: 8720                               O. Kolkman, Ed.
Obsoletes: 7500                                            February 2020
Category: Informational
ISSN: 2070-1721


 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 candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

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

Copyright Notice

   Copyright (c) 2020 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
   (https://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.

Table of Contents

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

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

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 [RFC8126], 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 must
   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.

   Recognizing that some assignments involve judgment, such as those
   involving a designated expert [RFC8126], 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 a 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 Administration Limited Liability
   Company (IETF LLC), as part of the IETF Administrative Support
   Activity (IASA), is responsible for IETF administrative and financial
   matters [RFC8711].  In that role, the IETF LLC 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 Board of the IETF LLC are accountable to the larger Internet
   community and are being held accountable through the IETF NomCom
   process [RFC8713].

   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.

5.  Changes since RFC 7500

   Section 3.4 has been updated to align with the restructuring of the
   IETF Administrative Support Activity (IASA).  Under the new
   structure, the IETF LLC maintains an SLA with the protocol parameter
   registry operator.  Under the old structure, the SLA was maintained
   by the IETF Administrative Oversight Committee (IAOC).

6.  Informative References

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

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

   [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, DOI 10.17487/RFC6220, April
              2011, <https://www.rfc-editor.org/info/rfc6220>.

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

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8711]  Haberman, B., Hall, J., and J. Livingood, "Structure of
              the IETF Administrative Support Activity, Version 2.0",
              BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
              <https://www.rfc-editor.org/info/rfc8711>.

   [RFC8713]  Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood,
              Ed., "IAB, IESG, and IETF LLC Selection, Confirmation, and
              Recall Process: Operation of the IETF Nominating and
              Recall Committees", BCP 10, RFC 8713,
              DOI 10.17487/RFC8713, February 2020,
              <https://www.rfc-editor.org/info/rfc8713>.

IAB Members at the Time of Approval

      Jari Arkko
      Alissa Cooper
      Stephen Farrell
      Wes Hardaker
      Ted Hardie
      Christian Huitema
      Zhenbin Li
      Erik Nordmark
      Mark Nottingham
      Melinda Shore
      Jeff Tantsura
      Martin Thomson
      Brian Trammell

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 by comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko,
   Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Alissa
   Cooper, Steve Crocker, John Curran, 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 the leadership of the Internet
   community, i.e., from the RIRs, ISOC, W3C, IETF, and IAB.

   Please do not assume those acknowledged endorse the resulting text.

Authors' Addresses

   Russ Housley (editor)
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   United States of America

   Email: housley@vigilsec.com


   Olaf Kolkman (editor)
   Internet Society
   Science Park 400
   1098 XH Amsterdam
   Netherlands

   Email: kolkman@isoc.org