Some Anachronisms in IETF Standards Process Documents
draft-carpenter-gendispatch-anachronisms-06

GenDispatch                                              B. E. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                              24 June 2026
Expires: 26 December 2026

         Some Anachronisms in IETF Standards Process Documents
              draft-carpenter-gendispatch-anachronisms-06

Abstract

   This document discusses some aspects of documents describing the IETF
   standards process that have been overtaken by events.  It covers the
   six-month expiry of Internet-Drafts, the citation of Internet-Drafts,
   the reality of the two-stage standards process, and other issues.
   This draft is posted only to open a discussion.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-carpenter-gendispatch-
   anachronisms/.

   Discussion of this document takes place on the GenDispatch Working
   Group mailing list (mailto:GenDispatch@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/gendispatch/.  Subscribe
   at https://www.ietf.org/mailman/listinfo/GenDispatch/.

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 26 December 2026.

Carpenter               Expires 26 December 2026                [Page 1]
Internet-Draft        Process Document Anachronisms            June 2026

Copyright Notice

   Copyright (c) 2026 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
   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.  Making Internet-Drafts Inactive . . . . . . . . . . . . . . .   3
   3.  Citing Internet-Drafts  . . . . . . . . . . . . . . . . . . .   3
   4.  Single-step Standards Process and STD numbers . . . . . . . .   4
   5.  How many BOFs?  . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Area Director for Individual Submissions  . . . . . . . . . .   6
   7.  Defining the IETF . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Force Majeure . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  IESG Statements . . . . . . . . . . . . . . . . . . . . . . .   7
   10. Who determines (rough) consensus? . . . . . . . . . . . . . .   8
   11. Other issues  . . . . . . . . . . . . . . . . . . . . . . . .   8
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   13. Security Considerations . . . . . . . . . . . . . . . . . . .   8
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   15. Informative References  . . . . . . . . . . . . . . . . . . .   8
   Appendix A.  Change Log [RFC Editor: please remove] . . . . . . .  10
     A.1.  Draft-00  . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.2.  Draft-01  . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.3.  Draft-02  . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.4.  Draft-03  . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.5.  Draft-04  . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.6.  Draft-05  . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.7.  Draft-06  . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This draft is posted only to open a discussion and to record known
   issues.  If there is interest in the issues raised, they should
   probably be split out into separate, more focussed, drafts.  Each of
   the following sections considers a specific issue.

Carpenter               Expires 26 December 2026                [Page 2]
Internet-Draft        Process Document Anachronisms            June 2026

   Note that [I-D.ietf-procon-2026bis] and [I-D.ietf-procon-2418bis] may
   clarify some of these issues.  An open question is whether the PROCON
   WG should be rechartered to consider formal rule changes for such
   issues.

2.  Making Internet-Drafts Inactive

   Experience has shown that the expiry after six months of Internet-
   Drafts, as described in [RFC2026], is meaningless and often leads to
   wasted effort.  It is meaningless because drafts, once posted on
   line, never disappear; indeed the IETF maintains a public archive of
   them.  It leads to wasted effort since authors often feel obliged to
   refresh a draft every six months with no significant change.  This
   wastes effort and resources for the authors themselves, the IETF's
   own computing resources, and potentially the resources and time of
   innumerable others.  Additional arguments can be found in
   [I-D.thomson-gendispatch-no-expiry].

   The following sentence in Section 2.2 of [RFC2026] (or its equivalent
   in [I-D.ietf-procon-2026bis]):

     An Internet-Draft that is published as an RFC, or that has remained
     unchanged in the Internet-Drafts directory for more than six months
     without being recommended by the IESG for publication as an RFC, is
     simply removed from the Internet-Drafts directory.

   describes what used to happen in the twentieth century.  What really
   happens today is closer to the following:

   An Internet-Draft that is published as an RFC, or that has remained
   unchanged for more than six months without being approved for
   publication as an RFC and is not under active discussion in a working
   group, is marked as "inactive" in tooling maintained by the IETF
   (such as the Datatracker).

   In other words, nothing really "expires" after six months; either the
   draft is actively developed, or it simply remains in the archive.
   Mentions of the expiry of Internet-Drafts in [RFC2418] (or
   [I-D.ietf-procon-2418bis]) are anachronisms, as are references to
   expiry or the period of six months in the header or boilerplate of
   Internet-Drafts.

3.  Citing Internet-Drafts

   Another rule about Internet-Drafts is broken as a matter of course -
   that they can only be referenced "without referencing an Internet-
   Draft".  Yes, that's what our rules say today; [RFC2026] says:

Carpenter               Expires 26 December 2026                [Page 3]
Internet-Draft        Process Document Anachronisms            June 2026

   Note: It is acceptable to reference a standards-track specification
   that may reasonably be expected to be published as an RFC using the
   phrase "Work in Progress" without referencing an Internet-Draft.
   This may also be done in a standards track document itself  as long
   as the specification in which the reference is made would stand as a
   complete and understandable document with or without the reference to
   the "Work in Progress".

   This isn't what we do, for sound practical reasons - we refer to I-Ds
   frequently in other I-Ds, and those references are often normative
   when two documents are being developed simultaneously.  (Which leads
   naturally to an interlock between the two documents if they come to
   be approved as RFCs.)  Also, we refer informatively to I-Ds in
   published RFCs.  Also, in some circumstances we refer to them as
   _stable_ references in IANA registries.

   In the real world these references explicitly _do_ cite an I-D with
   its DataTracker URL, directly in contradiction to the first sentence
   quoted above.  This makes sense, since otherwise the reader couldn't
   easily find the cited document.

   Note that at the time of writing, this issue is fixed in
   [I-D.ietf-procon-2026bis] by removing the phrase "without referencing
   an Internet-Draft" cited above, but that seems to be an actual rule
   change, not a clarification.

4.  Single-step Standards Process and STD numbers

   Experience has shown that the process for elevating a Proposed
   Standard (or a residual Draft Standard) to Internet Standard is so
   similar to the process for approving a Proposed Standard that there
   is now no practical difference between the two.  In reality, the
   Proposed Standard process is more stringent in practice than the
   description in [RFC2026], with in-depth reviews during the IETF Last
   Call and IESG discussion stages.  This is underlined by the
   Implementation Status Section recommended by [RFC7942], and echoes
   the arguments used in [RFC6410] to reduce the standards process to
   two stages.  Additional arguments can be found in
   [I-D.loughney-newtrk-one-size-fits-all].

   Another perspective -- the confusion caused by STD numbers -- is
   covered by [I-D.klensin-std-numbers], and those arguments are not
   repeated here, except to note that when a Proposed Standard updates
   or obsoletes an Internet Standard, the STD number loses it
   legitimacy.  Also the issue was already hinted at in [RFC1311], which
   has never been updated.

Carpenter               Expires 26 December 2026                [Page 4]
Internet-Draft        Process Document Anachronisms            June 2026

   (This problem does not arise for BCP numbers, which already follow a
   single-step process.  But for both STD and BCP numbers, it is
   undocumented who is responsible for choosing the numbers and deciding
   which documents are grouped together under a single number.)

   It has long been observed that "The Internet runs on Proposed
   Standards."  What harm to the Internet would result if we replaced
   the two-tier maturity ladder defined in [RFC6410] with a single lavel
   of maturity, namely "Internet Standard"?  This maturity level would
   be a merger of Proposed Standard, Draft Standard, and Standard as
   they are described in [RFC2026].  The characterization of an Internet
   Standard could remain as stated in RFC 2026:

     An Internet Standard is characterized by a high degree of
     technical maturity and by a generally held belief that the
     specified protocol or service provides significant benefit to the
     Internet community.

   In effect those criteria have long been applied by the IESG for the
   Proposed Standard maturity level, including when a Proposed Standard
   is updated without promotion to Internet Standard.  Merging the two
   levels would not change much at all, except for making things
   simpler.  Clarification of the scope of STD numbers is also needed.

   It would be good if all standards-track drafts _required_ an
   Implementation Status section [RFC7942] (noting that this section
   will not be included in the published RFC).  Then the IESG could
   consider the following issues if they are applicable, especially when
   the new document replaces or updates a previous one:

   1.  Are there at least two independent interoperating implementations
       with widespread deployment and successful operational experience?

   2.  Are there changes, including corrected errata, in the
       specification that would cause a new implementation to fail to
       interoperate with older ones?

   3.  Are there non-essential features in the specification that might
       increase implementation complexity?

   4.  If the technology required to implement the specification
       requires patented or otherwise controlled technology, do existing
       implementations demonstrate at least two independent, separate
       and successful uses of the licensing process?

Carpenter               Expires 26 December 2026                [Page 5]
Internet-Draft        Process Document Anachronisms            June 2026

5.  How many BOFs?

   Another issue is the number of BOFs allowed.  We are currently
   inconsistent with our own rules.  [RFC2418] seems to limit the number
   of Birds of a Feather (BOF) sessions to one per new working group:

    Note that an Area
    Director MAY require holding an exploratory Birds of a Feather (BOF)
    meeting, as described below, to gage the level of support for a
    working group before submitting the charter to the IESG and IAB for
    approval.

   Or it doesn't:

   To facilitate exploration of the issues the IETF
   offers the possibility of a Birds of a Feather (BOF) session, as well
   as the early formation of an email list for preliminary discussion.

   In reality the IESG has interpreted this to allow "non-WG-forming"
   BOFs, possibly followed by a "WG-forming BOF", and occasionally a
   second one.  Also there is a practice of creating non-WG mailing
   lists which may or may not be associated with a BOF.

   The current documentation does not really decribe the current
   practice.  [RFC5434] is realistic but only Informational.

6.  Area Director for Individual Submissions

   Section 6.1.1 of [RFC2026] mentions individual submissions quite
   briefly:

   A standards action is initiated by a recommendation by the IETF
   Working group responsible for a specification to its Area Director,
   copied to the IETF Secretariat or, in the case of a specification not
   associated with a Working Group, a recommendation by an individual to
   the IESG.

   This leaves it open which IESG member shepherds such a document.

   Section 4.2 on non-standards track documents also leaves this open,
   as does Section 5 on BCPs.

   It seems necessary to state that a specific AD needs to sponsor and
   shepherd such a submission, which is today's current practice.

   [I-D.ietf-procon-2026bis] partially clarifies this by citing an IESG
   Statement (https://datatracker.ietf.org/doc/statement-iesg-guidance-
   on-area-director-sponsoring-of-documents-20070320/).

Carpenter               Expires 26 December 2026                [Page 6]
Internet-Draft        Process Document Anachronisms            June 2026

7.  Defining the IETF

   [RFC3233] (BCP 58) offers a slightly out-of-date definition of the
   IETF.  Should this be resolved by

   1.  updating BCP 58,

   2.  adding a sentence or two to the definition of the IETF in
       Section 3.1 of [RFC9281] (BCP 11), or

   3.  leaving this matter for the IETF web site?

   Suggested text is along the lines of:

    The IETF is an unincorporated, freestanding organization composed
    of volunteers who are independent, bound only by policy, not by any
    membership agreement.

8.  Force Majeure

   "Force Majeure" is the phrase used in many contexts to indicate that
   normal rules may be broken when an event entirely outside the control
   of those involved occurs and makes those rules unworkable.  A recent
   example in the IETF's history is the COVID-19 pandemic.  Another
   example could be an urgent need to temporarily replace a person much
   more quickly than the NomCom can act.

   At the moment, the IETF's process documents do not tackle this issue,
   yet the pandemic obliged both the IESG and IETF LLC to take urgent
   decisions regardless of process rules and normal practice.

9.  IESG Statements

   Sometimes it occurs that a procedural issue of some kind is not
   covered, or is ambiguously covered, by any formal document (typically
   a BCP).  In this case the established practice is that the IESG
   publishes a statement to settle the procedural issue, possibly in
   conjunction with or embedded in an appeal response.  Such statements
   become part of the IETF process unless negated or replaced by a new
   formal document.

   At the moment the IETF's process documents do not describe this
   mechanism.

Carpenter               Expires 26 December 2026                [Page 7]
Internet-Draft        Process Document Anachronisms            June 2026

10.  Who determines (rough) consensus?

   It seems that no current document states clearly that the IESG
   determines IETF consensus (although it's strongly implied).  Also the
   fact that the IETF process does not require _unanimous_ consensus is
   not formally stated, despite general agreement on the rough consensus
   model.

11.  Other issues

   Open issues identified during the consolidation of RFC 2026 and RFC
   2418 can be found at https://github.com/ietf-wg-procon/2026bis/
   issues/24 and https://github.com/ietf-wg-procon/2418bis/issues.
   There is some overlap with this document.

12.  IANA Considerations

   No IANA actions are needed.

13.  Security Considerations

   This document does not directly affect the security of the Internet.

14.  Acknowledgements

   Useful comments were received from Toerless Eckert, Paul Hoffman,
   John Klensin, Michael Richardson, Rich Salz, Martin Thomson, and
   others.

15.  Informative References

   [I-D.ietf-procon-2026bis]
              Salz, R. and S. O. Bradner, "The Internet Standards
              Process", Work in Progress, Internet-Draft, draft-ietf-
              procon-2026bis-10, 23 June 2026,
              <https://datatracker.ietf.org/doc/html/draft-ietf-procon-
              2026bis-10>.

   [I-D.ietf-procon-2418bis]
              Salz, R., Schinazi, D., and S. O. Bradner, "IETF Working
              Group Guidelines and Procedures", Work in Progress,
              Internet-Draft, draft-ietf-procon-2418bis-02, 2 March
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              procon-2418bis-02>.

   [I-D.klensin-std-numbers]
              Klensin, J. C., "STD Numbers and the IETF Standards
              Track", Work in Progress, Internet-Draft, draft-klensin-

Carpenter               Expires 26 December 2026                [Page 8]
Internet-Draft        Process Document Anachronisms            June 2026

              std-numbers-03, 18 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-klensin-std-
              numbers-03>.

   [I-D.loughney-newtrk-one-size-fits-all]
              Dawkins, S. and J. A. Loughney, "A Single-Stage Standards
              Process", Work in Progress, Internet-Draft, draft-
              loughney-newtrk-one-size-fits-all-01, 6 March 2006,
              <https://datatracker.ietf.org/doc/html/draft-loughney-
              newtrk-one-size-fits-all-01>.

   [I-D.thomson-gendispatch-no-expiry]
              Thomson, M. and P. E. Hoffman, "Removing Expiration
              Notices from Internet-Drafts", Work in Progress, Internet-
              Draft, draft-thomson-gendispatch-no-expiry-03, 16 January
              2024, <https://datatracker.ietf.org/doc/html/draft-
              thomson-gendispatch-no-expiry-03>.

   [RFC1311]  Postel, J., "Introduction to the STD Notes", RFC 1311,
              DOI 10.17487/RFC1311, March 1992,
              <https://www.rfc-editor.org/rfc/rfc1311>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/rfc/rfc2026>.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
              September 1998, <https://www.rfc-editor.org/rfc/rfc2418>.

   [RFC3233]  Hoffman, P. and S. Bradner, "Defining the IETF", BCP 58,
              RFC 3233, DOI 10.17487/RFC3233, February 2002,
              <https://www.rfc-editor.org/rfc/rfc3233>.

   [RFC5434]  Narten, T., "Considerations for Having a Successful Birds-
              of-a-Feather (BOF) Session", RFC 5434,
              DOI 10.17487/RFC5434, February 2009,
              <https://www.rfc-editor.org/rfc/rfc5434>.

   [RFC6410]  Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
              DOI 10.17487/RFC6410, October 2011,
              <https://www.rfc-editor.org/rfc/rfc6410>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/rfc/rfc7942>.

Carpenter               Expires 26 December 2026                [Page 9]
Internet-Draft        Process Document Anachronisms            June 2026

   [RFC9281]  Salz, R., "Entities Involved in the IETF Standards
              Process", BCP 11, RFC 9281, DOI 10.17487/RFC9281, June
              2022, <https://www.rfc-editor.org/rfc/rfc9281>.

Appendix A.  Change Log [RFC Editor: please remove]

A.1.  Draft-00

   *  Original version

A.2.  Draft-01

   *  Added individual submission issue

   *  Simplified Introduction

A.3.  Draft-02

   *  Clarified that Implementation Status sections are removed before
      RFC publication

A.4.  Draft-03

   *  Added "Defining the IETF"

A.5.  Draft-04

   *  Mentioned STD number issue

   *  Added "Force majeure"

   *  Note on IANA citing I-Ds

A.6.  Draft-05

   *  Added IESG Statements issue

A.7.  Draft-06

   *  Noted that assignment of STD and BCP numbers is undocumented

   *  RFC1311 lives!

   *  Who determines consensus?

   *  Added pointers to PROCON open issues

Carpenter               Expires 26 December 2026               [Page 10]
Internet-Draft        Process Document Anachronisms            June 2026

Author's Address

   Brian E. Carpenter
   The University of Auckland
   School of Computer Science
   The University of Auckland
   PB 92019
   Auckland 1142
   New Zealand
   Email: brian.e.carpenter@gmail.com

Carpenter               Expires 26 December 2026               [Page 11]