Principles for Operation of Internet Assigned Numbers Authority (IANA) RegistriesVigil Security, LLC918 Spring Knoll DriveHerndonVA20170United States of Americahousley@vigilsec.comInternet SocietyScience Park 400Amsterdam1098 XHNLkolkman@isoc.orgIASA
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
.
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
() 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
. Introduction
. Principles for the Operation of IANA Registries
. Discussion
. Ensuring Uniqueness, Stability, and Predictability
. Public
. Open and Transparent
. Accountable
. Security Considerations
. Changes since RFC 7500
. Informative References
IAB Members at the Time of Approval
Acknowledgements
Authors' Addresses
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.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.
Discussion
The principles discussed in provide trust and confidence in
the IANA registries. This section expands on these principles.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 , 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.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.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 , the recommendations by
designated experts must be visible to the public to the maximum
extent possible and subject to challenge or appeal.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 , the general oversight of the IANA
function is performed by the IAB as a chartered responsibility from
. 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 . 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 .
For the Internet Number Registries , oversight is performed
by the Regional Internet Registries (RIRs) as described RFC 7020
. 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 .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.Changes since RFC 7500 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).Informative ReferencesAddress Supporting Organization (ASO) MoUICANNCharter of the Internet Architecture Board (IAB)Internet Architecture BoardThis memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Defining the Role and Function of IETF Protocol Parameter Registry OperatorsInternet Architecture BoardMany Internet Engineering Task Force (IETF) protocols make use of commonly defined values that are passed in messages or packets. To ensure consistent interpretation of these values between independent implementations, there is a need to ensure that the values and associated semantic intent are uniquely defined. The IETF uses registry functions to record assigned protocol parameter values and their associated semantic intentions. For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions. This document is not an Internet Standards Track specification; it is published for informational purposes.The Internet Numbers Registry SystemThis document provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers.This document also provides information about the processes for further evolution of the Internet Numbers Registry System.This document replaces RFC 2050.This document does not propose any changes to the current Internet Numbers Registry System. Rather, it documents the Internet Numbers Registry System as it works today.Internet Numbers RegistriesRFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.This companion document identifies the IANA registries that are part of the Internet Numbers Registry System at this time.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Structure of the IETF Administrative Support Activity, Version 2.0IAB, IESG, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall CommitteesIAB Members at the Time of Approval
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:
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
and .
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' AddressesVigil Security, LLC918 Spring Knoll DriveHerndonVA20170United States of Americahousley@vigilsec.comInternet SocietyScience Park 400Amsterdam1098 XHNLkolkman@isoc.org