RFC 2434

Guidelines for Writing an IANA Considerations Section in RFCs

📅 published October 1998, from ietf

Guidelines for Writing an IANA Considerations Section in RFCs 🎀

💖 Part 1 of 3 💖

okay bestie, let's get into it ✨ this one is RFC 2434, and it's a Best Current Practice (that's BCP 26) 💅 It came out in October 1998 from the Network Working Group. The authors are T. Narten from IBM and H. Alvestrand from Maxware 🫶 The title block doesn't list anything it obsoletes or updates, so it's a standalone vibe 🌸

Status of this Memo 📜

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract 🦋

okay so tbh a lot of protocols run on identifiers that are just constants and well-known values 🧚 and even after a protocol is defined and already out in the wild, new values might still need to be assigned. like a new option type in DHCP, or a new encryption or authentication algorithm for IPSec 🔥 to keep everything consistent across different implementations, somebody central has to be in charge of handing those out. for IETF protocols, that's the Internet Assigned Numbers Authority (IANA) 👑

so for the IANA to manage a name space properly, it needs rules about when new values can be assigned 💅 if the IANA is going to have a role in managing a name space, it has to get clear and concise instructions about that role, no cap. this document talks through what to think about when making an assignment policy for a name space, and it gives document authors guidance on the exact text that has to go into documents that put demands on the IANA 🎀

Table of Contents

   Status of this Memo..........................................    1
   1.  Introduction.............................................    2
   2.  Issues To Consider.......................................    3
   3.  Registration maintenance.................................    6
   4.  What To Put In Documents.................................    7
   5.  Applicability to Past and Future RFCs....................    8
   6.  Security Considerations..................................    8
   7.  Acknowledgments..........................................    9
   8.  References...............................................    9
   9.  Authors' Addresses.......................................   10
   10. Full Copyright Statement.................................   11

1. Introduction 🌈

okay so this is the part where everything starts to make sense 🧚 a lot of protocols depend on fields that hold constants and other well-known values. think of the Protocol field in the IP header [IP], or the MIME types in mail messages [MIME-REG] ✨ and just like the Abstract said, new values can show up long after a protocol has been defined and deployed. the examples are a new option type in DHCP [DHCP] or a new encryption or authentication algorithm for IPSec [IPSEC] 💖 so again, those assignments have to be run by one central authority, and for IETF protocols that's the Internet Assigned Numbers Authority (IANA) 👑

quick vocab moment 🦋 in this document, the set of possible values for one of these fields is called a "name space". the content in it can be a name, a number, or some other kind of value 💅 when a specific value gets assigned to a name space, that's called an assigned number (or assigned value), and every single assignment of a number in a name space is called a registration 🫶

so the IANA needs guidelines about the conditions under which new values should be assigned to manage a name space prudently 🔥 this document gives authors guidance on what kind of text to add to their documents, and it goes over the issues to think about when working out a sensible policy for assigning numbers to name spaces 🌸

not every name space needs central administration, though 🙈 sometimes a name space can be delegated, so further assignments can happen independently with no more (central) coordination needed. in the Domain Name System, for example, the IANA only deals with assignments at the higher levels, while subdomains are run by the organization the space was delegated to 💜 Object Identifiers (OIDs) as defined by the ITU are also delegated [ASSIGNED] ✨ so when a name space can be delegated, the IANA only deals with assignments at the top level, periodt 💅

last bit, and it's important 💀 this document uses the terms 'MUST', 'SHOULD' and 'MAY', plus their negatives, the way RFC 2119 [KEYWORDS] describes them 🎀 in this case, "the specification" as used by RFC 2119 means the processing of protocols that are being submitted to the IETF standards process 🧚

2. Issues To Consider 💅✨

Okay so the big question when you're managing a name space is: how big is it? 🧐 If the space is small and limited, assignments have to be made carefully so it doesn't run out 😭. If it's essentially unlimited, it can be perfectly fine to hand new values to anyone who wants one 🎀. Even then, it's usually a good idea to do a minimal review so nobody hoards the space or wastes it. Like, if the space is text strings, you probably don't want an organization grabbing a huge pile of the "best" names (think existing company names) 💀.

The second thing to think about is whether it makes sense to delegate the name space in some way. If it does, go for it when it's appropriate, because it lightens the load on the IANA when it comes to handling assignments 🫶.

Sometimes the name space is essentially unlimited and assigned numbers can safely go to anyone. When no subjective review is needed, the IANA can make assignments directly, as long as it's given specific instructions on what types of requests to grant and what information must be provided before a request is considered 📋. Note: the IANA will not define an assignment policy itself! It should be handed guidelines that let it make allocation decisions with very little subjectivity 🙅‍♀️.

In most cases, though, some review is appropriate, and the real question becomes who does the review and how rigorous it needs to be 🤔. People often think an IETF Working Group (WG) familiar with the name space should be consulted. The tea, though: WGs eventually disband, so they can't be a permanent evaluator 😤. It's also possible for name spaces to be created through individual submission documents, where no WG is ever formed 🦋.

One way to make sure the community reviews prospective assignments is to have the requester submit a document for publication as an RFC. That makes sure the IESG and relevant WGs review the assignment 👑. This is the preferred way to get review, and it's especially important if any potential interoperability issues can come up 🚨. Lots of assignments aren't just assignments, they also involve some protocol specification. For example, a new option might define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols they're built on 💀.

Sometimes, though, publishing an RFC just to get an assignment is excessive. It's still generally useful (and sometimes necessary) to discuss proposed additions on a mailing list dedicated to the purpose, such as ietf-types@iana.org for media types, or on a more general mailing list, like that of a current or former IETF WG 📬. That kind of list lets new registrations be publicly reviewed before they're assigned, or gives advice to people who want help understanding what a proper registration should contain ✨.

Mailing list discussion can provide valuable technical expertise, but opinions vary and discussions can drag on for ages without resolution 😩. On top of that, the IANA can't participate in all of these mailing lists and can't determine if or when those discussions reach consensus. So the IANA cannot let general mailing lists fill the role of giving definitive recommendations on a registration question 🚫. Instead, the IANA uses a designated subject matter expert. The IANA relies on a "designated expert" to advise it on assignment matters. In other words, the IANA forwards the requests it gets to one specific point-of-contact (one or a small number of individuals) and acts on the returned recommendation from that designated expert 💖. The designated expert can start and coordinate as wide a review of an assignment request as necessary to evaluate it properly 🔍.

Designated experts are appointed by the relevant Area Director of the IESG. They're typically named when the document that creates a new numbering space is published as an RFC. But since experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary 🌸.

Any decision made by the designated expert can be appealed using the normal IETF appeals process, as outlined in Section 6.5 of [IETF-PROCESS]. And since the designated experts are appointed by the IESG, the IESG may remove them too 🙃.

The following are example policies, some of which are in use today ✨:

  • Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There's no need for IANA to review these assignments, and they aren't generally useful for interoperability 🏠.
    • Examples: Site-specific options in DHCP [DHCP] have significance only within a single site. X-foo: header lines in email messages.
  • Hierarchical allocation - Delegated managers can assign values, provided they've been given control over that part of the name space. IANA controls the higher levels of the name space according to one of the other policies 🌳.
    • Examples: DNS names, Object Identifiers
  • First Come First Served - Anyone can obtain an assigned number, as long as they provide a point of contact and a brief description of what the value would be used for. For numbers, the exact value is generally assigned by the IANA; with names, specific names are usually requested 🏃‍♀️.
    • Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP and UDP port numbers.
  • Expert Review - approval by a Designated Expert is required 🧑‍🏫.
  • Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in enough detail that interoperability between independent implementations is possible 📖.
    • Examples: SCSP [SCSP]
  • IESG Approval - New assignments must be approved by the IESG, but there's no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis) 🤷‍♀️.
  • IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists) 🤝.
    • Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address Family Identifiers [BGP4-EXT].
  • Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG 🏅.
    • Examples: MIME top level types [MIME-REG]

It's worth noting that it often makes sense to split a name space into several categories, with assignments out of each category handled differently. For example, the DHCP option space [DHCP] is split into two parts. Option numbers in the range 1-127 are globally unique and assigned according to the Specification Required policy described above, while options numbered 128-254 are "site specific", i.e., Local Use 🧩. Dividing the name space up makes it possible to allow some assignments with minimal review, while also reserving some part of the space for future use 🌈.

3. Registration maintenance 🎀

Registrations are requests for an assigned number, including the related information needed to evaluate and document the request. Even after a number is assigned, some types of registrations contain extra information that may need updating over time. For example, MIME types, character sets, language tags, etc. typically include more information than just the registered value itself 📝. Example information can include point of contact information, security issues, pointers to updates, literature references, etc. In cases like these, the document must clearly state who is responsible for maintaining and updating a registration. It is appropriate to:

  • Let the author update the registration, subject to the same constraints and review as with new registrations ✍️.
  • Allow some mechanism to attach comments to the registration, for cases where others have significant objections to claims in a registration, but the author does not agree to change it 💬.
  • Designate the IESG or another authority as having the right to reassign ownership of a registration. This is mainly to get around the problem when some registration owner cannot be reached in order to make necessary updates 🔁.

4. What To Put In Documents ✨

okay so this is where the working group and/or document author gets to do the real planning 💅 The earlier sections were all the stuff to think about, and now it's YOUR job to write a policy for handing out well-known numbers and other protocol constants and put it in the right document 🎀 In some cases an "IANA Considerations" section is totally the move 🦋 Specifically, if your doc creates a name space (or changes an existing one) AND expects the IANA to help maintain it (like being the repository for registered values), you MUST document the process for future assignments 😭 That section MUST state clearly:

  • whether or not an application for an assigned number needs to be reviewed. If review is necessary, the review mechanism MUST be specified. When a Designated Expert is used, documents MUST NOT name the Designated Expert in the document itself. Instead, the name should be relayed to the appropriate IESG Area Director at the time the document is sent to the IESG for approval. 🙈
  • If the request should also be reviewed on a specific public mailing list (such as ietf-types@iana.org for media types), that mailing address should be specified. Note, however, that use of a Designated Expert MUST also be specified. 📬
  • if the IANA is expected to make assignments without requiring an outside review, sufficient guidance MUST be provided so that the requests can be evaluated with minimal subjectivity. 🧠

Authors SHOULD attempt to provide guidelines that let the IANA assign new values directly, without needing a Designated Expert to review them. This is actually pretty easy in a lot of cases 🌸 You just designate a range of values for direct IANA assignment, and then keep a big enough chunk of the name space for the future, with assignments from that chunk only happening after a stricter review. Smart, right? 👑

And it's totally acceptable to pick one of the example policies cited above and just refer to it by name. For example, a document could say something like:

     Following the policies outlined in [IANA-CONSIDERATIONS],
     numbers in the range 0-63 are allocated as First Come First
     Served, numbers between 64-240 are allocated through an IETF
     Consensus action and values in the range 241-255 are reserved
     for Private Use.

If you want examples of documents that give the IANA really good, detailed guidance on assigning numbers, go check out [MIME-REG, MIME-LANG] 🔥

5. Applicability to Past and Future RFCs 🕰️

For all existing RFCs that either explicitly or implicitly rely on the IANA to evaluate assignments without specifying a precise evaluation policy, the IANA will keep deciding what policy is appropriate. The default policy has been first come, first served. Changes to existing policies can always be started through the normal IETF consensus process 🫶

All future RFCs that either explicitly or implicitly rely on the IANA to register or otherwise manage assignments MUST provide guidelines for managing the name space. No vibes-based name spaces allowed, bestie 💅

6. Security Considerations 🔐

Information that creates or updates a registration needs to be authenticated. Obviously. 🙈

Information about possible security vulnerabilities of a protocol can change over time. The same goes for security vulnerabilities related to how an assigned number gets used (for example, if it identifies a protocol). As new vulnerabilities turn up, information about them may need to be attached to existing registrations, so that users are not mislead as to the true security issues surrounding the use of a registered number 😭 This part is SERIOUS, no cap.

An analysis of security issues is required for all parameters (data types, operation codes, keywords, etc.) used in IETF protocols or registered by the IANA. All descriptions of security issues must be as accurate as possible, regardless of the level of registration. In particular, a statement that there are "no security issues associated with this type" must not given when it would be more accurate to state that "the security issues associated with this type have not been assessed". Don't lie to people about security, periodt 💀

7. Acknowledgments 🌈

Jon Postel and Joyce K. Reynolds gave a detailed explanation of what the IANA needs in order to manage assignments efficiently, and they patiently commented on multiple versions of this document 🫶 Brian Carpenter gave helpful comments on earlier versions too. One paragraph in the Security Considerations section was borrowed from [MIME-REG]. Thank you, legends ✨

8. References 📚

  • [ASSIGNED] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
  • [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.
  • [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
  • [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
  • [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
  • [IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
  • [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
  • [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
  • [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.

9. Authors' Addresses 🦋

Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195 - BRQA/502
Research Triangle Park, NC 27709-2195

Phone: 919-254-7798
EMail: narten@raleigh.ibm.com


Harald Tveit Alvestrand
Maxware
Pirsenteret
N-7005 Trondheim
Norway

Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards, in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💖

📦 where this page comes from