]> The University of Auckland

School of Computer Science The University of Auckland PB 92019 Auckland 1142 New Zealand brian.e.carpenter@gmail.com

General GenDispatch Internet-Draft 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. About This Document Status information for this document may be found at . Discussion of this document takes place on the GenDispatch Working Group mailing list (), which is archived at . Subscribe at .

Introduction This draft is posted only to open a discussion. 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. Note that and 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.

Making Internet-Drafts Inactive Experience has shown that the expiry after six months of Internet-Drafts, as described in , 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 . The following sentence in Section 2.2 of (or its equivalent in ): describes what used to happen in the twentieth century. What really happens today is closer to the following: 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 (or ) are anachronisms, as are references to expiry or the period of six months in the header or boilerplate of Internet-Drafts.

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; says: 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 by removing the phrase "without referencing an Internet-Draft" cited above, but that seems to be an actual rule change, not a clarification.

Single-step Standards Process 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 , with in-depth reviews during the IETF Last Call and IESG discussion stages. This is underlined by the Implementation Status Section recommended by , and echoes the arguments used in to reduce the standards process to two stages. Additional arguments can be found in . 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 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 . The characterization of an Internet Standard could remain as stated in RFC 2026: 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. It would be good if all standards-track drafts required an Implementation Status section . 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?

How many BOFs? Another issue is the number of BOFs allowed. We are currently inconsistent with our own rules. seems to limit the number of Birds of a Feather (BOF) sessions to one per new working group: Or it doesn't: 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. is realistic but only Informational.

Area Director for Individual Submissions Section 6.1.1 of mentions individual submissions quite briefly: 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. partially clarifies this by citing an IESG Statement.

IANA Considerations No IANA actions are needed.

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

Acknowledgements Useful comments were received from Paul Hoffman, Michael Richardson, Rich Salz, Martin Thomson, and others.

Informative References This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document discusses tactics and strategy for hosting a successful IETF Birds-of-a-Feather (BOF) session, especially one oriented at the formation of an IETF Working Group. It is based on the experiences of having participated in numerous BOFs, both successful and unsuccessful. [STANDARDS-TRACK] This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Akamai Technologies SOBCO This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages, and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process. This document obsoletes RFC 2026, RFC 5657, RFC 6410, RFC 7100, RFC 7127, RFC 8789, and RFC 9282. It also includes the changes from RFC 7475. If this document and [_2418bis] are published as RFCs, then taken together the two of them make RFC 7475 obsolete. Akamai Technologies Google LLC SOBCO The Internet Engineering Task Force (IETF) has responsibility for developing and reviewing specifications intended as Internet Standards. IETF activities are organized into working groups (WGs). This document describes the guidelines and procedures for formation and operation of IETF working groups. It also describes the formal relationship between IETF participants WG and the Internet Engineering Steering Group (IESG) and the basic duties of IETF participants, including WG Chairs, WG participants, and IETF Area Directors. This document obsoletes RFC2418, and RFC3934. It also includes the changes from RFC7475, and with [_2026bis], obsoletes it. It also includes a summary of the changes implied in RFC7776 and incorporates the changes from RFC8717 and RFC9141. Futurewei Nokia This document proposes several changes of principle to the Internet standards process, specifically a reduction from three stages to a single stage in the standards track. This does not effect the Informational, Experimental or BCP designations. Mozilla ICANN The long-standing policy of requiring that Internet-Drafts bear an expiration date is no longer necessary. This document removes requirements for expiration for Internet-Drafts from RFC 2026/BCP 9 and RFC 2418/BCP 25. In place of expiration, this document introduces Internet-Drafts being labeled "active" and "inactive" in the IETF tooling.

Change Log [RFC Editor: please remove]

Draft-00

• Original version

Draft-01

• Added individual submission issue
• Simplified Introduction