References in RFCs and IANA Registries
draft-hoffman-non-rfc-refs-00

Network Working Group                                         P. Hoffman
Internet-Draft                                                     ICANN
Intended status: Informational                              28 June 2025
Expires: 30 December 2025

                 References in RFCs and IANA Registries
                     draft-hoffman-non-rfc-refs-00

Abstract

   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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 30 December 2025.

Copyright Notice

   Copyright (c) 2025 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 (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components

Hoffman                 Expires 30 December 2025                [Page 1]
Internet-Draft                 References                      June 2025

   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Types of References . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  RFCs  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Internet Drafts . . . . . . . . . . . . . . . . . . . . .   3
     2.3.  Specifications from Other SDOs  . . . . . . . . . . . . .   4
     2.4.  Specifications from Governments . . . . . . . . . . . . .   5
     2.5.  Academic Journals and Conference Papers . . . . . . . . .   5
     2.6.  Other Types of References . . . . . . . . . . . . . . . .   5
   3.  Selecting References for RFCs . . . . . . . . . . . . . . . .   5
   4.  Selecting References for IANA Assignments . . . . . . . . . .   6
     4.1.  When Publication in an RFC is Needed for IANA
           Assignments . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

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

Hoffman                 Expires 30 December 2025                [Page 2]
Internet-Draft                 References                      June 2025

   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.

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

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

2.2.  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".

Hoffman                 Expires 30 December 2025                [Page 3]
Internet-Draft                 References                      June 2025

   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 [RFC7322], 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.

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

   [WikipediaSDO] 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)

Hoffman                 Expires 30 December 2025                [Page 4]
Internet-Draft                 References                      June 2025

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

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

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

3.  Selecting References for RFCs

   References in RFCs are split into two types: normative and
   informative.  The distinction is defined in [RFC7322] and, for IETF
   stream RFCs, [IESGonRefs].  Although [IESGonRefs] 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

Hoffman                 Expires 30 December 2025                [Page 5]
Internet-Draft                 References                      June 2025

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

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

   [RFC8126], which is currently being updated by
   [I-D.iana-ianabis-rfc8126bis], 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.

4.1.  When Publication in an RFC is Needed for IANA Assignments

   Section 4 of [RFC8126]/[I-D.iana-ianabis-rfc8126bis] 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.

Hoffman                 Expires 30 December 2025                [Page 6]
Internet-Draft                 References                      June 2025

   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 [RFC8789]

   *  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

Hoffman                 Expires 30 December 2025                [Page 7]
Internet-Draft                 References                      June 2025

      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.

5.  IANA Considerations

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

Hoffman                 Expires 30 December 2025                [Page 8]
Internet-Draft                 References                      June 2025

6.  Security Considerations

   This document does not discuss security.

7.  References

7.1.  Normative References

   [RFC7322]  Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
              DOI 10.17487/RFC7322, September 2014,
              <https://www.rfc-editor.org/info/rfc7322>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [I-D.iana-ianabis-rfc8126bis]
              Baber, A. and S. Tanamal, "Guidelines for Writing an IANA
              Considerations Section in RFCs", Work in Progress,
              Internet-Draft, draft-iana-ianabis-rfc8126bis-00, 27
              February 2025, <https://datatracker.ietf.org/doc/html/
              draft-iana-ianabis-rfc8126bis-00>.

   [IESGonRefs]
              "IESG Statement: Normative and Informative References",
              2006, <https://datatracker.ietf.org/doc/statement-iesg-
              iesg-statement-normative-and-informative-references-
              20060419/>.

7.2.  Informative References

   [RFC8789]  Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream
              Documents Require IETF Rough Consensus", BCP 9, RFC 8789,
              DOI 10.17487/RFC8789, June 2020,
              <https://www.rfc-editor.org/info/rfc8789>.

   [Wayback]  "Internet Archive Wayback Machine",
              <https://web.archive.org/>.

   [WikipediaSDO]
              "Standards organization", <https://en.wikipedia.org/wiki/
              Standards_organization#Overview>.

Hoffman                 Expires 30 December 2025                [Page 9]
Internet-Draft                 References                      June 2025

Appendix A.  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.

Author's Address

   Paul Hoffman
   ICANN
   Email: paul.hoffman@icann.org

Hoffman                 Expires 30 December 2025               [Page 10]