]> ICANN

paul.hoffman@icann.org

This document describes the use of references in RFCs and IANA registries. It also discusses situations where RFCs are currently required as references in IANA registries. This document does not define any new policies, but instead describes the many practices that have been used, particularly the practices that are considered best current practices today. This document is informative, and thus does not require changes to, or prohibit exceptions from, the current practices.

Introduction The IETF has many diverse ways to make reference to components such as cryptographic algorithms, media types, and so on that are used in IETF protocols. These referencing practices have changed over time, based on the IETF community, the IETF leadership, and the types of components needed by protocols. Sometimes those components are already defined in RFCs, but there are many instances when they are described in Internet Drafts that are no longer being worked on, in specifications from other standards development organizations (SDOs), in government documents, in academic journals, and many other places. The purpose of this document is to increase consistency and transparency in how the IETF handles this diverse set of references for components. It provides input to IETF working groups that are defining new components or updating the way they specify components, particularly in the references section of RFCs and in IANA registries. Two of the most important features of a reference used in an RFC or IANA registries are the ability to find the referred-to information over a long period of time, and the stability of the information in the reference. For example, copies of very old RFCs and expired Internet Drafts have been available for at least a decade before this publication so that they can be used in newer protocol efforts. But there are many other types of references that become unavailable due to URLs becoming unusable, material in referred-to sources being updated without notice, and so on.

Types of References References and IANA assignments can come from many sources. The most common types are listed here, and described in more detail later in this document. This section also describes how the RFC Editor and IANA creates links to the references.

RFCs The clearest type of reference in an RFC or an IANA registry is an RFC. The RFC editor currently creates links to RFCs in references as "https://www.rfc-editor.org/info/rfc1234". IANA currently creates links to RFCs in registries as "https://www.iana.org/go/rfc1234". The RFC Editor or IANA might change the way they make these links in the future. RFCs that are also Internet Standards (sometimes listed as "STD") or Best Current Practices (sometimes listed as "BCP") are often instead listed by their STD or BCP numbers.

Internet Drafts There are two distinct ways to make references to Internet Drafts: A draft series is a reference to all drafts whose file name (without the trailing number) is the same. An example of a reference to a draft series would be "draft-smith-fancyprot-over-udp". A specific draft is a reference to a single version of a draft, that is, the file name with the trailing number. An example of a reference to a specific draft would be "draft-smith-fancyprot-over-udp-07". References to draft series and specific drafts are quite common in RFCs; about 30% of RFCs in the past five years have at least one reference to a draft series or specific draft. References to specific drafts are common in IANA registries, both for documents that are expected to later become RFCs and drafts that have been abandoned but nonetheless include reservations for identifiers. According to , references to draft series and specific drafts must appear only as informative references. The RFC editor currently creates links to a a specific draft as "https://datatracker.ietf.org/doc/html/draft-smith-fancyprot-over-udp-07". The RFC editor currently creates links to a a draft series as "https://datatracker.ietf.org/doc/html/draft-smith-fancyprot-over-udp". IANA currently creates links to a specific draft in registries as: "https://www.iana.org/go/draft-smith-fancyprot-over-udp-07". IANA currently strongly discourages using draft series in assignments. The RFC Editor or IANA might change the way they make these links in the future.

Specifications from Other SDOs Standards organizations outside the IETF publish specifications that are related to IETF work. There are two type of these references in RFCs: A specific document is a reference to a document that is produced by another SDO. For example, a reference to a W3C technical report (TR) would point to that document on the W3C web site. An organizational reference is a reference to part or all of an SDO. For example, a reference to the "Time-Sensitive Networking (TSN) Task Group" in IEEE 802.1 would point to that group's web page. currently divides SDOs as follows: International standards organizations (ISO, IEC, ITU, and so on) Regional standard organizations (CEN, ETSI, and so on) National standard organizations (ANSI, BSI, and so on) Standards developing organizations (SDOs) (CIE, IEEE, Audio Engineering Society, and so on)

Specifications from Governments Technical organizations in various national governments and groups of national governments often produce specifications and standards, and those are relevant to IETF work. For example, the U.S. National Institute of Standards and Technology (NIST) and the European Telecommunications Standards Institute (ETSI) publish many specifications that appear in RFCs and IANA registries. Referring to government standards is similar to referring to specifications from other SDOs, both for specific documents and for organizational references.

Academic Journals and Conference Papers Early RFCs had many references to academic journals and conference papers. Modern RFCs and IANA registries have many fewer than the early days of the IETF, but they are still sometimes used, particularly when discussing the origins of ideas that are embodied in new protocol work. In recent years, for example, RFCs and IANA registries have referred to IEEE conference papers, ACM journal articles, and Cryptology ePrint Archive, and recent RFCs regularly refer to IEEE and ACM conference papers and journal articles.

Other Types of References The previous sections listed the references that are by far the most common, but they are not the only ones. For example, an RFC might have to have references to IANA registry groups, not just for the IANA Considerations section. Another example is that RFCs will sometimes refer to presentations at IETF meetings. One type of reference often seen in IANA registries and never in RFCs is references to individual people, with the reference linking to their email address. These references are often for registries that allow allocations just by individual request, without a specification required.

Selecting References for RFCs References in RFCs are split into two types: normative and informative. The distinction is defined in and, for IETF stream RFCs, . Although has not been updated, some of the rules about referencing Internet Drafts are not always followed exactly as specified. The RFC series is one of the best-known set of standards in the technical world, and great emphasis is put on making the references as useful as possible. When references are Internet Drafts or other RFCs, this is not a problem. However, some other types of references have caused problems over the years. URLs used by other organizations and governments tend to change without redirection, leading to "link rot". Another problem is "reference rot", where the material at the given URL is now useless due to changes by the URL's owner. Readers of an RFC can sometimes remedy these types of rot by searching for saved copies of the URL, such as using . In these cases, the reader of an RFC might file an erratum report listing the new URL for the reference. In general, using RFCs as references in later RFCs is a best practice. However, that's not always possible because there isn't an RFC for every topic that needs a reference. For those cases, references of other types are appropriate, and almost always better than describing a topic but omitting any kind of reference. Although using references to draft series or specific drafts was considered controversial in the past, doing so now is considered normal in the RFC series.

Selecting References for IANA Assignments Although a proliferation of experimental extensions to protocols can be a barrier to interoperability, the IETF often encourages such experimentation and operational testing. Nearly all IANA registries have clearly-defined extension mechanisms, and most of these allow allocation of identifiers (sometimes called "code points") before the extension has been standardized in the IETF. , which is currently being updated by , specifies the many decisions that go into writing an "IANA Considerations" section for an RFC. Essentially all IANA registries start as an RFC being published; the RFC specifies initial values for the identifiers for the registry and the rules for adding new identifiers. The IETF has discovered that different types of requirements for extensions to IANA registries can have a huge effect on how much or little extension a protocol can receive. In short, some types of IANA considerations cause easy experimentation and extension, while other types make such experimentation and extension to be difficult for protocol developers.

When Publication in an RFC is Needed for IANA Assignments Section 4 of / describes many policies that might be used for making assignments in IANA registries. Three of them ("RFC Required", "IETF Review", and "Standards Action") require RFCs in order to make an assignment. In order to be published as an RFC, an Internet Draft must be sponsored by one of the following: An IETF working group (and then the working group's Area Director) A research group in the Internet Research Task Force (IRTF) An Area Director who is individually sponsoring the draft The Independent Submissions Editor (ISE) The Internet Architecture Board (IAB) RFCs describing protocols and protocol extensions have been published by the first four of those. IETF working groups and IRTF research groups get to choose the Internet Drafts they want to work on, and which of the drafts adopted are meant to become RFCs after later work and approvals. Similarly, the ISE chooses which Internet Drafts are appropriate for the Independent stream of RFCs. Area Directors may not be willing to individually sponsor Internet Drafts to become RFCs for various reasons: Other venues for RFC publication can garner better reviews RFCs are often not required for specifying protocols and protocol extensions in RFCs or IANA registries Individually-sponsored documents must get IETF consensus, as determined by the IESG, before publication as RFCs; see It might be difficult to get IETF consensus if there are already working groups dealing with similar topics Each of the methods for getting an RFC for protocols or extensions has possible failure cases.

IETF working groups:

Each working group gets to choose which drafts to adopt, based on the working group's charter. A working group might not adopt a particular draft if the working group is already too busy with other work, or if it finds the new topic not different enough from topics that have already been specified, or if it wants the industry to focus on the protocols or extensions that have already been specified.

Research groups in the IRTF:

The IRTF decides what research topics can be handled in research groups. In general, research groups are not supposed to specify protocols or extensions: that's the work of the IETF. The few research groups that do sometimes work on protocols or protocol extensions may decide not to publish RFCs for particular protocols or extensions if those are not that different from others that the research group have already published, or if the group decides that the new work might have some undesirable properties, or just because it is so busy with other more interesting research.

Area Director who individually sponsor drafts:

Area Directors are usually quite busy running their areas and reviewing every draft that comes before the Internet Engineering Steering Group (IESG). They sometimes make special cases for sponsoring drafts, but the amount of work to do so can often be a burden, so they tend not to do so.

The ISE:

The ISE gets to choose which drafts they spend time on getting published as RFCs. Each draft that the ISE publishes goes through a lengthy review process before publication, so the ISE tends to be conservative in what they accept to publish. The ISE publishes on a wide variety of topics, but is often choosy about which drafts within a particular topic (such as cryptography) they publish.

The IAB:

The IAB publishes drafts that originate with the IAB, and thus rarely publishes drafts about protocols or extensions just because they were proposed to them.

From the above, it is clear that it is risky to assume that any particular protocol or extension that was not already adopted by a working group or research group will be published as an RFC. As an aside, some vendors and organizations that specify protocol compliance or interoperability demand that the protocols used in their requirements be in RFCs. Such demands are fine for protocols and extensions that are already widely agreed upon in IETF working groups, but those demands may not be met due to the difficulty of getting published RFCs for topics of narrow interest. That is, one cannot assume that a protocol or extension can automatically be embodied in an RFC.

IANA Considerations This document contains no actions for IANA. However, it discusses the use of IANA registries in many places.

Security Considerations This document does not discuss security.

&RFC7322; &RFC8126; &I-D.iana-ianabis-rfc8126bis; &RFC8789;

Acknowledgements Some of the material here was originally written by Paul Wouters for a different document. Many of the ideas here came from the discussion of that document in the Security Area during 2024 and 2025. Ted Harrison provided suggested additions on an early version of this draft.