RFC 6220

Defining the Role and Function of IETF Protocol Parameter Registry Operators

📅 published April 2011, from ietf

📜 RFC 6220: Defining the Role and Function of IETF Protocol Parameter Registry Operators 🎀

okay bestie, this one's from the Internet Architecture Board (IAB) and it's all about who's in charge of the lists of magic numbers that protocols rely on 💅✨

Authors: D. McPherson, O. Kolkman, J. Klensin, and G. Huston, all listed as editors (Ed.)
Category: Informational 🦋 (not a Standards Track spec, so it's a "for the record" doc, not a rulebook)
Date: April 2011 🌸
ISSN: 2070-1721
Obsoletes/Updates: the title block has no Obsoletes or Updates entries, so this doc doesn't replace or change any other RFC 🫶

Abstract

okay so a bunch of IETF protocols pass around shared values inside their messages and packets 📦 for two separate implementations to understand each other, those values and what they mean have to be uniquely defined 🔒 the IETF handles this with registries that record every assigned value and its meaning. 📚 for each protocol parameter, the IETF's usual move is to hand the job of running that registry to a nominated entity (the Protocol Parameter Registry Operator) 👑 this document describes that job and sets out what's required of it ✨

1. Overview ✨

okay so here's the core problem 🧠 lots of IETF protocols use common values that get passed around inside messages or packets. 💌 if different implementations are gonna read those values the same way, the values and their intended meaning need to be pinned down exactly. 📌 the IETF does this with registries that log every possible value of a protocol parameter and what it's supposed to mean 📖 the rules for these registries, how registration works, and how the content is laid out all live in the "IANA Considerations" sections of IETF documents 🎀

here's the tea ☕ the IETF keeps its registry operator separate from itself. 🧩 this split is pretty common among standards development organizations (SDOs), though it's less common among technology consortia and similar bodies 🌈 there are a few reasons they split things up: handling admin stuff, keeping basic policy at a healthy distance from specific allocations 📏 and dodging any conflicts of interest that could come from commercial or organizational relationships 💼 for example, most ISO and ISO/IEC JTC1 standards that need registrations name a Registration Authority (RA) or Maintenance Agency (MA) to make the actual registration calls 🗂️ the database of what's registered for each standard then gets run by a secretariat or database function tied to that RA or MA, or (less often) by the secretariat of the body that made the standard in the first place 🏛️

this kind of role split shows up in other places in the IETF too, like the RFC Editor function 📝 the Internet Architecture Board (IAB) is responsible, on behalf of the IETF, for defining and managing the relationship with the Protocol Registry Operator role 👀 that includes picking and managing the Protocol Parameter Registry Operator, plus managing the registration process for parameters and the guidelines for allocating them 🔥

⚠️ even though the IETF can hand off some specific decisions, it still claims authority and responsibility over all of its protocol parameters and their registries 🫡 it mostly stays out of picking the actual values once a registration is approved, but the ownership never goes anywhere 💜

this document explains how these registries work for individual protocol parameters defined through the IETF Internet Standards Process [RFC2026] 🧁 the goal is an orderly rollout by the Internet Administrative Oversight Committee (IAOC) and others as needed, all under guidance from the IAB 🌸 and yep, we also spell out the requirements for those delegated functions, which the IETF traditionally calls the Internet Assigned Numbers Authority (IANA) function 🎀

2. Roles and Responsibilities Concerning IETF Protocol Parameter Registries 👑

okay so the IETF has a longstanding habit of outsourcing the management and running of some important functions (see [RFC5620]) 💼 the protocol parameter registry is one of those outsourced jobs, and this section is where the roles and responsibilities for registering IETF protocol parameters get laid out 🧾

specifically, this doc describes a delegated IETF Protocol Parameter Registry Operator, who gets selected and overseen by the IETF Administrative Support Activity (IASA) [RFC4071] 🫶 usually there's just one Operator, but extra Operators can be picked to run specific registries, and that has happened now and then 🌈 having a single Operator makes it easier to keep things coordinated across registries, even ones that don't seem related at all 🔗 it also helps keep formats and registry structure consistent, which makes life easier for registry users and helps with quality control ✅

here's why all this matters 🧠 lots of protocols use identifiers made of constants and other well-known values. 🔢 even after a protocol is defined and out in the wild, new values sometimes need to be assigned (like a new option type in DHCP, or a new encryption or authentication algorithm for IPsec) 🚀 so that those values mean the same thing across different implementations, a central authority has to administer the assignments 🗝️ for IETF protocols, that central authority is the delegated Protocol Parameter Registry Operator 💖 and for any given protocol parameter, there is exactly one delegated Registry Operator 💯

(to be continued in Part 2 🎀💖)

2.1. Protocol Parameter Registry Operator Role ✨

okay bestie, the IETF Protocol Parameter Registry function is run under the auspices of the Internet Architecture Board 🌸

The Protocol Parameter Registry Operator has these roles:

Review and Advise 🔍
- A Registry Operator may be asked to review Internet-Drafts that the Internet Engineering Steering Group (IESG) is considering. The goal is to give the IESG advice on the contents of the "IANA Considerations" section, whether that section is clear about what it asks of the Registry Operator (when one is needed), and whether it matches the current published Registry Operator guidelines.
Registry 📚
- To operate a registry of protocol parameter assignments.
- The delegated Registry Operator registers values for Internet protocol parameters only as the criteria and procedures in RFCs direct. That includes Proposed, Draft, and full Internet Standards, Best Current Practice documents, and other RFCs that require protocol parameter assignment.

If values for Internet protocol parameters weren't specified, or something is ambiguous, the Registry Operator keeps assigning and registering only the parameters already delegated to it. It follows past and current practice for those assignments, unless the IESG directs otherwise in terms of operating practice. If there's an ambiguity, the Registry Operator is expected to flag it to the IAB or IESG, as appropriate, and either suggest better text or ask the right people for clarification 🙏

For each protocol parameter, the associated registry includes:
- a reference to the RFC document that describes the parameter and the associated "IANA Considerations" for it, and
- for each registration of a protocol parameter value, the source of the registration and the date of the registration (if that date is known), and
- any other information the RFC document describing the parameter says should be included in the registration data.
- If in doubt, or in case of a technical dispute, the Registry Operator will seek and follow technical guidance exclusively from the IESG. Where appropriate, the IESG will appoint an expert to advise the Registry Operator 💅
The Registry Operator will work with the IETF to develop any missing criteria and procedures over time, and will adopt them when the IESG instructs it to.
Unless special circumstances apply to subsets of the data and specific rules are set by IETF consensus, each protocol parameter registry operates as a public registry. Its contents are openly available to the public, online, and free of charge 🌈
The Registry Operator assigns protocol parameter values according to the policy attached to that parameter, such as "First Come First Served" or "Expert Review" [RFC5226].

Mailing Lists 💌
- The Registry Operator maintains public mailing lists as specified in IANA Considerations [RFC5226]. These lists are for reviewing assignment proposals alongside a designated expert review function. On top of that, each Protocol Parameter Registry Operator should maintain a mailing list so the registry staff can be reached by email.
Liaison Activity 🤝
- The Registry Operator will nominate a liaison point of contact. Through this liaison, the Registry Operator may be asked to advise the IESG on IETF protocol parameters, and on the "IANA Considerations" section of each Internet-Draft being reviewed for publication as an RFC. Where appropriate, the IESG will appoint an expert to advise the Registry Operator.
Reporting 📊
- The Registry Operator will submit periodic reports to the IAB on how the registry function is performing operationally. For an example of what those reports should cover, check out the supplement [IAOC_SUPP] to the "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" [RFC2860]. It sets out the service level agreement (SLA) guidelines that ICANN, the current protocol parameter registry, has to operate under.
- At the request of the chair of the IETF, IAB, or IAOC, the Registry Operator will give periodic reports at IETF Plenary meetings on the status of the registry function.
- The Registry Operator will publish an annual report describing the status of the function and a summary of performance indicators.
Intellectual Property Rights and the Registry Operator ⚖️
- All assigned values are to be published and made available free of any charges.
- The assignment values may be redistributed without modification.
- Any intellectual property rights in the IETF protocol parameter assignment information, including the IETF protocol parameter registry and its contents, are to be held by the IETF Trust [RFC4748].

2.2. IAB Role 🏛️

An Operator of an IETF protocol parameter registry takes on its role as a delegated function under the authority of the IAB.

The IAB is responsible for reviewing the current description of the registry function from time to time, and for directing the Registry Operator to adopt amendments to its role and mode of operation, according to the best interests of the IETF and the Internet community in general.

The IAB is responsible for appointing an organization to carry out the delegated functions of the Protocol Parameter Registry Operator for each IETF protocol parameter. Specifically, the IAB defines the role and requirements for those functions. The IAOC is responsible for identifying a potential vendor and, once under agreement, managing the various aspects of the relationship with that vendor. To be clear, the IAB is in the deciding role (for example, for appointment and termination), but it must work in close consultation with the IAOC.

The IAB is responsible for determining the terms and conditions of this delegated role. Those terms and conditions should ensure that the registry operates in a way that fully conforms to the functions described in this document. They also must not restrict the rights and interests of the IETF with respect to the registry contents and maintenance 🔐

2.3. IESG Role 🧠

The IESG is responsible for the technical direction of entries into IETF protocol parameter registries, and for maintaining the policies by which that technical direction is given. Technical direction itself comes through directives adopted in the "IANA Considerations" section of IETF Stream RFCs, or through stand-alone "IANA Considerations" RFCs.

The IESG shall verify that Internet-Drafts offered for publication as IETF Stream RFCs [RFC4844] include "IANA Considerations" sections when needed, and that those sections conform to the current published guidelines.

Technical assessment isn't generally the Registry Operator's job, so as part of giving technical direction, the IESG is responsible for identifying the technical experts needed to review registration requests where appropriate, or to resolve open technical questions about registering parameters 🧐

At its discretion, the IESG will organize the liaison activities with the Registry Operator's liaison point of contact, so that communication stays clear and the registry function runs effectively 💖

2.4. Role of the IETF Trust 🦋

The IETF Trust [RFC4748] was formed to act as the administrative custodian of all copyrights and other intellectual property rights relating to the IETF Standards Process. That job was previously done by the Internet Society (ISOC) and the Corporation for National Research Initiatives (CNRI).

Any intellectual property rights in IETF protocol parameter assignment information, including the registry and its contents, and all registry publications, are to be held by the IETF Trust on behalf of the IETF.

The IETF Trust may make whatever regulations are appropriate for redistributing assignment values and registry publications.

2.5. Role of the IAOC 📋

The IAOC is responsible for identifying a potential vendor, in a manner of its choosing and based on IAB consultation, and for managing the various aspects of the relationship with that vendor.

On top of that, the IAOC has the responsibility to ensure long-term access, stability, and uniqueness across all such registries. This responsibility is especially important if a relationship with a Protocol Parameter Registry Operator is ever terminated 🚨

3. Miscellaneous Considerations 🎀

While this document focuses on protocols created by the IETF, the requirements in it apply generically to the wider IETF community too (for example, the Internet Research Task Force (IRTF)).

The IESG is responsible for the technical direction of the IETF Protocol Parameter registries, and for maintaining the policies by which that technical direction is given. As part of the document approval process for IETF Stream RFCs [RFC4844], the IESG is responsible for "IANA Considerations" verification. For the other RFC streams, the approval bodies are responsible for verifying that documents include "IANA Considerations" sections when needed, and that those sections conform to the current published guidelines. If IANA considerations in non-IETF document streams lead to a dispute, the IAB makes the final decision.

This document talks about "Registry Operator" (singular). There are stability and economy-of-scale advantages to having one single Operator, but this document doesn't rule out different Operators for different protocol registries when the circumstances justify it 🧩

4. Security Considerations 🛡️

This document does not propose any new protocols and does not introduce any new security considerations.

5. IANA Considerations 🌟

This document requires no direct IANA actions in terms of creating or operating a protocol parameter registry. However, it does define the roles and responsibilities of the various bodies responsible for, and associated with, the operation of protocol parameter registration functions for the IETF 👑

6. Informative References ✨

okay so this is the reading list bestie, the stuff the doc points to but doesn't need you to read to get the main point 📚🫶 these are all the refs it cites, and I'm keeping every detail, titles and dates and all, because you can't cite something wrong and be iconic about it 💅

[RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
            3", BCP 9, RFC 2026, October 1996.

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

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

[RFC4748]   Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF
            Trust", RFC 4748, October 2006.

[RFC4844]   Daigle, L., Ed., and Internet Architecture Board, "The
            RFC Series and RFC Editor", RFC 4844, July 2007.

[RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

[RFC5620]   Kolkman, O., Ed., and IAB, "RFC Editor Model (Version
            1)", RFC 5620, August 2009.

[IAOC_SUPP] ICANN/IANA-IETF MoU Supplemental Agreement,
            <http://iaoc.ietf.org/documents/
            IETF-ICANN_Supplemental_Agreement.pdf>.

7. Acknowledgements 🎀

this bit gives credit where it's due, and honestly the origin story is so good 🌸 the doc is built on top of "Guidelines for Writing an IANA Considerations Section in RFCs" [RFC5226], but it got some glow-ups: explicit talk about Intellectual Property Rights, plus the IAB and IESG roles around the IETF Protocol Parameter Registry function 🔥

the Internet Architecture Board also gave a huge shout-out to the reviewers who read the drafts and helped make it better 🫶 the named crew is Scott Bradner, Brian Carpenter, Leslie Daigle, Adrian Farrel, Alfred Hoenes, Paul Hoffman, Alexey Melnikov, Thomas Narten, and Ray Pelletier 💜 the real MVPs ✨

8. IAB Members 👑

these are the Internet Architecture Board members at the time this doc was approved for publication 🌈 squad goals, fr fr:

   Marcelo Bagnulo
   Ross Callon
   Spencer Dawkins
   Russ Housley
   John Klensin
   Olaf Kolkman
   Danny McPherson
   Jon Peterson
   Andrei Robachevsky
   Dave Thaler
   Hannes Tschofenig

Authors' Addresses 💌

and finally, who to email if you have questions (be nice about it, they're literally the editors 🥹):

Danny McPherson, Editor
Verisign, Inc.
EMail: dmcpherson@verisign.com

Olaf M. Kolkman, Editor
NLnet Labs
EMail: olaf@NLnetLabs.nl

John C Klensin, Editor
EMail: john+ietf@jck.com

Geoff Huston, Editor
APNIC
EMail: gih@apnic.net

Internet Architecture Board
EMail: iab@iab.org

that's the whole doc, bestie, you survived the RFC 6220 arc 🌈💖🦋

📦 where this page comes from

ietf: rfc6220 2011-04
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms