GenDispatch B. E. Carpenter Internet-Draft Univ. of Auckland Intended status: Informational 3 February 2026 Expires: 7 August 2026 Some Anachronisms in IETF Standards Process Documents draft-carpenter-gendispatch-anachronisms-00 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 BOF approvals. 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 7 August 2026. Carpenter Expires 7 August 2026 [Page 1] Internet-Draft Process Document Anachronisms February 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 . . . . . . . . . . . . . . . . . . . 4 4. Single-step Standards Process . . . . . . . . . . . . . . . . 4 5. How many BOFs? . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . 6 Appendix A. Change Log [RFC Editor: please remove] . . . . . . . 7 A.1. Draft-00 . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction This draft is posted only to open a discussion. If there is interest in the issues raised, they should probably be split into separate, more focussed, drafts. 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]. Carpenter Expires 7 August 2026 [Page 2] Internet-Draft Process Document Anachronisms February 2026 Another rule about I-Ds 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.) Experience has also 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 issue is the number of BOFs allowed. We are currently inconsistent with our own rules. The remainder of this document discusses these issues in more detail. 2. Making Internet-Drafts Inactive 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. Carpenter Expires 7 August 2026 [Page 3] Internet-Draft Process Document Anachronisms February 2026 3. Citing Internet-Drafts We have rules that attempt to restrict references to Internet-Drafts. [RFC2026] says: 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. 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. 4. Single-step Standards Process It has long been observed that "The Internet runs on Proposed Stanrards." 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. Carpenter Expires 7 August 2026 [Page 4] Internet-Draft Process Document Anachronisms February 2026 It would be good if all standards-track drafts _required_ an Implementation Status section [RFC7942]. 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? 5. How many BOFs? [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. Carpenter Expires 7 August 2026 [Page 5] Internet-Draft Process Document Anachronisms February 2026 6. IANA Considerations No IANA actions are needed. 7. Security Considerations This document does not directly affect the security of the Internet. 8. Acknowledgements Useful comments were received from Paul Hoffman, Michael Richardson, Rich Salz, Martin Thomson, and others. 9. 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-05, 2 February 2026, . [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-01, 15 October 2025, . [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, . [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, . [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . Carpenter Expires 7 August 2026 [Page 6] Internet-Draft Process Document Anachronisms February 2026 [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, . [RFC5434] Narten, T., "Considerations for Having a Successful Birds- of-a-Feather (BOF) Session", RFC 5434, DOI 10.17487/RFC5434, February 2009, . [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, . [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, . Appendix A. Change Log [RFC Editor: please remove] A.1. Draft-00 * Original version 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 7 August 2026 [Page 7]