RFC 8720

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

📅 published February 2020, from ietf

RFC 8720: Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries 🎀

Okay bestie, let's talk about RFC 8720! 💖 It's an Informational doc from the Internet Architecture Board (IAB), so it's not a Standards Track spec 🙈. R. Housley, Ed. and O. Kolkman, Ed. wrote it, it's Request for Comments: 8720, it came out in February 2020, and its ISSN is 2070-1721 ✨. It obsoletes RFC 7500 💅, so this is the new and improved version.

Abstract ✨

This doc gives us the principles for how the Internet Assigned Numbers Authority (IANA) registries should be run 🧚

Status of This Memo 📜

This doc is not an Internet Standards Track specification 🙈. It's published just for informational purposes.

It's a product of the Internet Architecture Board (IAB), and it holds info the IAB decided was valuable enough to keep on record forever 💜. It represents the consensus of the IAB. Docs the IAB approves for publication are not candidates for any level of Internet Standard, so check out Section 2 of RFC 7841 if you want the deets 🫶.

For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8720 🔥.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they explain your rights and restrictions for this doc 📖.

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 🌸

Okay so the IETF and its predecessors have always kept two things separate: the protocol specs, which get published as immutable Request for Comments (RFCs), and the registries that hold the protocol parameters 📚. The registries are traditionally run by a group of functions called the Internet Assigned Numbers Authority (IANA).

Back in the earliest days of the Internet, publishing specs and running the registries were super tightly coupled. Jon Postel of the Information Sciences Institute (ISI) at the University of Southern California (USC) handled both the RFC publication and the IANA registry operation 🤯. That tight coupling had its perks, but it was never a requirement. Today the RFC Editor and IANA registry operation are run by different entities, and that's totally fine ✨.

Registries are critical to how the Internet works, because they give a definitive record of the value and meaning of the identifiers protocols use to talk to each other 💅. Almost every Internet protocol uses registries in some form. At the time of writing, IANA maintains more than two thousand protocol parameter registries 😭.

These registries hold protocol identifiers, which are constants and other well-known values that Internet protocols use. They can be numbers, strings, addresses, and so on 🎀. Each one is uniquely assigned for one particular purpose or use. Identifiers can live in a central list (like a list of cryptographic algorithms), or they can be allocated hierarchically, with separate entities assigning them at different points in the hierarchy (like IP addresses and domain names) 🦋. To maximize trust and usefulness of the IANA registries, the principles in this doc should be taken into consideration for centralized registries as well as hierarchically delegated ones 🫶. In hierarchically delegated registries, the entries nearest the top have broad scope, while the 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 runs on trust and mutual cooperation 🤝. Using the registries is voluntary, and it's not enforced by mandates or certification policies. Even so, the success of the Internet creates enormous pressure to use Internet protocols and the identifier registries that go with them 👀.

So this doc gives us principles for operating IANA registries, so protocol identifiers have consistent meanings and interpretations across all implementations and deployments. That consistency is what gives us the necessary trust in the IANA registries 💜.

2. Principles for the Operation of IANA Registries 👑

These key principles are what keep the IANA registries running well, and they're the 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 from Section 2 are what give us trust and confidence in the IANA registries, and this section breaks each one down 🔍.

3.1. Ensuring Uniqueness, Stability, and Predictability 🧩

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

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

Some assignments involve judgment, like those handled by a designated expert [RFC8126], so a predictable process doesn't have to finish in a set number of days ⏳. What it does mean is that no unexpected steps get added to 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 🎉. Using a consistent publication location builds confidence in the registry. The publication location doesn't have to stay put forever, but 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 it must operate in a transparent manner 💅.

When a registry gets set up, a policy is put in place for adding new entries and updating existing ones. While making additions and changes, the registry operator may notice places where policies are unclear. When that happens, the registry operator should give helpful feedback so those policies can be improved 🛠️. Also, the registry operator not being involved in setting registry policy helps avoid the risks tied to (perceptions of) favoritism and unfairness ⚖️.

Some assignments involve judgment, like those handled by a designated expert [RFC8126]. For those, the recommendations made by designated experts must be visible to the public to the maximum extent possible, and they must be 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 make sure the registries 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 make sure the registry operator is meeting the needs of the affected community. The oversight body is itself held accountable to the affected community through very different mechanisms, such as 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] 🎀. 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). That SLA spells out the operational requirements for coordinating, maintaining, and publishing the protocol parameter registries 🧚. Both the IAB and the Board of the IETF LLC are accountable to the larger Internet community, and they're 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 in RFC 7020 [RFC7020] 🌍. The RIRs are member-based organizations, and they're accountable to the affected community through elected governance boards 🗳️. Also, per an agreement between the RIRs and ICANN, policy development for the global IANA number registries is coordinated by a community-elected number council. That policy is then 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, so this part is seriously important! The principles described in this doc are necessary for the Internet community to be able to place trust in the IANA registries 💀.

5. Changes since RFC 7500 🔄

Section 3.4 has been updated to line up 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, that SLA was maintained by the IETF Administrative Oversight Committee (IAOC) 💅.

6. Informative References ✨

okay bestie, these are the "for your info" references 📚 so they're background reads, not the rules themselves. Here's the whole list, untouched:

IAB Members at the Time of Approval 💜

These are the IAB members who were around when this got approved 🎀

  • 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 was developed within the IAB IANA Evolution Program 🌈 The ideas, a bunch of the 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. Extra inspiration and input came 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
📦 where this page comes from