]> 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. This draft is posted only to open a discussion. 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 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. 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. 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 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 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 , 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 . Another perspective -- the confusion caused by STD numbers -- is covered by , 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 , which has never been updated. (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 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. Clarification of the scope of STD numbers is also needed. It would be good if all standards-track drafts required an Implementation Status section (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?

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.

Defining the IETF (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 (BCP 11), or
3. leaving this matter for the IETF web site?

Suggested text is along the lines of:

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.

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.

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.

Other issues Open issues identified during the consolidation of RFC 2026 and RFC 2418 can be found at and . There is some overlap with this document.

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 Toerless Eckert, Paul Hoffman, John Klensin, Michael Richardson, Rich Salz, Martin Thomson, and others.

Informative References The STDs are a subseries of notes within the RFC series that are the Internet standards. The intent is to identify clearly for the Internet community those RFCs which document Internet standards. [STANDARDS-TRACK] 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 gives a more concrete definition of "the IETF" as it understood today. Many RFCs refer to "the IETF". Many important IETF documents speak of the IETF as if it were an already-defined entity. However, no IETF document correctly defines what the IETF is. 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. This document describes the individuals and organizations involved in the IETF standards process, as described in BCP 9. It includes brief descriptions of the entities involved and the role they play in the standards process. The IETF and its structure have undergone many changes since RFC 2028 was published in 1996. This document reflects the changed organizational structure of the IETF and obsoletes RFC 2028. Akamai Technologies Harvard University (retired) 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. STD numbers are assigned to IETF Standards Track specifications in order to provide a stable reference even when RFCs are revised and the underlying documents change. However, the numbers are only assigned when the specifications reach Internet Standard maturity level, significantly reducing their utility in the contemporary world in which few specifications advance beyond the first standardization maturity level. For that reason, one proposal, more than a decade ago, suggested eliminating the numbers entirely. Others, including more recent ones, have suggested eliminating maturity levels entirely, in part as a way to solve the numbering problem. This document argues that stable references for Standards Track specifications are actually useful and that the solution is not to abolish the numbers or maturity levels but to change the point at which they are assigned.

Change Log [RFC Editor: please remove]

Draft-00

• Original version

Draft-01

• Added individual submission issue
• Simplified Introduction

Draft-02

• Clarified that Implementation Status sections are removed before RFC publication

Draft-03

• Added "Defining the IETF"

Draft-04

• Mentioned STD number issue
• Added "Force majeure"
• Note on IANA citing I-Ds

Draft-05

• Added IESG Statements issue

Draft-06

• Noted that assignment of STD and BCP numbers is undocumented
• RFC1311 lives!
• Who determines consensus?
• Added pointers to PROCON open issues