RFC 7500

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

📅 published April 2015, from ietf

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

Okay bestie, so this is RFC 7500 💜, and it's Informational, which means it's a permanent record and not an Internet Standard ✨. The Internet Architecture Board (IAB) published it in April 2015 🌸. The editors are R. Housley (Vigil Security) and O. Kolkman (Internet Society), and the ISSN is 2070-1721. The title block doesn't list any RFCs that it obsoletes or updates, so it doesn't mess with anything else 🫶.

Abstract

This doc gives you the principles for how IANA registries should be run 📖💅.

Status of This Memo

This document is not an Internet Standards Track specification. It's published just for info 🦋.

This document is a product of the Internet Architecture Board (IAB). It's basically the IAB saying "this is valuable, keep it forever," and it represents the consensus of the IAB 👑. Anything the IAB approves for publication is not a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for the details 🙈.

Want the current status, errata, or a way to give feedback? Check http://www.rfc-editor.org/info/rfc7500 💖.

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) as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🧚.

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 ✨

Okay so the IETF and its predecessors have always kept protocol specs in RFCs, which are immutable 📜, and kept the registries of protocol parameters separate. The registries are usually run by a group of functions called the Internet Assigned Numbers Authority (IANA) 💅. Way back at the start of the Internet, publishing specs and running registries were super tightly linked. Jon Postel of the Information Sciences Institute (ISI) at the University of Southern California (USC) did both RFC publication and IANA registry operation 🙈. That tight coupling had perks, but it was never a requirement. Today, the RFC Editor and IANA registry operation are run by different entities 🫶.

Registries are critical to the Internet, no cap 🔥. They give a definitive record of the value and meaning of the identifiers that protocols use to talk to each other. Almost every Internet protocol uses registries in some form 💜. When this was written, the IANA maintained more than two thousand protocol parameter registries 🤯.

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 one central list (like a list of cryptographic algorithms), or they can be allocated hierarchically, with different entities assigning at different levels of the hierarchy (like IP addresses and domain names) ✨. To keep the IANA registries trustworthy and useful, the principles in this document should be considered for both centralized registries and hierarchically delegated ones. In hierarchically delegated registries, entries near the top have broad scope, and 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 isn't enforced by mandates or certification policies. Even so, the success of the Internet puts enormous pressure on people to use Internet protocols and the identifier registries that go with them 😭.

So this document lays out principles for running IANA registries. The goal is that protocol identifiers mean the same thing and get interpreted consistently across all implementations and deployments, which builds the trust that IANA registries need 💖.

2. Principles for the Operation of IANA Registries 👑

These key principles hold up the successful functioning of the IANA registries, 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 💅

Section 2's principles are what give people trust and confidence in the IANA registries. This section goes deeper on each of them 🧚.

3.1. Ensuring Uniqueness, Stability, and Predictability ✨

Protocol identifier assignment and registration must be unique, stable, and predictable. Developers, vendors, customers, and users all rely 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 careful thought about what that reassignment would do, and, if possible, with the consent of the original assignee 🙈.

Some assignments involve judgment, like the ones handled by a designated expert [RFC5226]. Because of that, a predictable process doesn't have to finish in a set number of days. What it does mean is that no unexpected steps sneak into the process of making an assignment 💜.

3.2. Public 🌸

Once assigned, protocol identifiers must be made available in a way that makes them freely available to everyone, without restrictions 🌈. Using a consistent publication location builds confidence in the registry. That doesn't mean the publication location can never change, but it does mean 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 set up, a policy is set for adding new entries and updating existing ones. While making additions and changes, the registry operator may spot places where policies lack clarity. 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 avoids the risks that come with (perceptions of) favoritism and unfairness 😤.

Some assignments involve judgment, like the ones handled by a designated expert [RFC5226]. 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 themselves, must be accountable to the parties that rely on the protocol identifiers. Oversight is needed to make sure they're actually 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 check that 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 done by the IAB, as a chartered responsibility from [RFC2850] 👑. On top of that, the IETF Administrative Oversight Committee (IAOC), which handles IETF administrative and financial matters [BCP101], keeps 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 IAOC are accountable to the larger Internet community, and that accountability is enforced 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're accountable to the affected community through elected governance boards 🌈. Also, under an agreement between the RIRs and ICANN, policy development for the global IANA number registries is coordinated by a community-elected number council, and it's subject to process review before the ICANN Board of Trustees ratifies it [ASOMOU] 💖.

4. Security Considerations 🔥😭

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

Part 1 ends here, more coming next bestie 🧚💜

5. Informative References 📚✨

okay bestie, these are the extra reads that back up everything we just talked about. think of them as the receipts 💅

IAB Members at the Time of Approval 🌸

the IAB squad when this got approved, iconic lineup 👑

  • 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 🫶

okay the thank-you list is so long and I love it 🥹 this text came out of the IAB IANA Evolution Program, and the ideas, a bunch of 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, 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. extra inspiration also came 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. they're the ones who helped, not the ones who signed off on every word 💀

Authors' Addresses 💖

the people who actually wrote it, and how to reach them 💌

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
📦 where this page comes from