RFC 3933

A Model for IETF Process Experiments 🦋

Okay bestie, this is RFC 3933, and it's giving "how the IETF can try new process stuff without going full bureaucracy" 💅

Here's the title block tea ☕. It's RFC 3933, titled A Model for IETF Process Experiments, from the Network Working Group. The authors are J. Klensin and S. Dawkins. It's a Best Current Practice (that's BCP 93) and the date is November 2004. The header doesn't list anything it obsoletes or updates.

---

Status of this Memo ✨

This document is an Internet Best Current Practice for the Internet Community, and it's asking people to chime in with discussion and suggestions for improvements 🫶 Anyone can share this memo, since distribution is unlimited.

Copyright Notice 📜

Copyright (C) The Internet Society (2004).

Abstract 🌸

So the IETF has been changing its process for about ten years, and it's done that in two main ways. One is when the IESG just announces a change, sometimes based on informal agreements that the wider community barely knew about. The other is using the same heavy machinery it uses for protocol specifications. The first one often felt too lightweight, and the second one felt too heavyweight 😭

This document lays out a middle-ground approach for making changes to IETF process. It leans hard on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model, which is different from the ways that were tried before 🔥

Table of Contents 🧚

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Background and Specification . . . . . . . . . . . . . . . . . 2
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 5
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
       5.1.  Normative Reference. . . . . . . . . . . . . . . . . . . 5
       5.2.  Informative References . . . . . . . . . . . . . . . . . 5
   6.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7

1. Introduction 💖

This document is basically the middle-ground approach we just talked about, for changing IETF process. It relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model, rather than the ones that were tried before ✨

2. Background and Specification 🎀

Okay so since the 1992 changes documented in [RFC1396], the IETF has used two mechanisms for process changes 💅

1. The IESG has made a bunch of procedural changes on its own initiative and written them down informally, using the wide discretion that [RFC2026] implicitly gives it 🦋 This was a lightweight mechanism for change, but the lightness came with a cost: sometimes there was too little alignment with the larger IETF community 😬
2. The IETF has also used the [RFC2026] protocol standards development process to identify a community of interest, hold one or more BoFs, charter a working group, discuss proposed changes within the community, develop IETF-wide consensus on the changes, and publish (usually) Best Current Practice specifications. This gave full community involvement, but it also cost flexibility 🌈 The IETF doesn't change its formal processes often. The IPR clarifications in [RFC3667, RFC3668] are the first documented changes to [RFC2026] since 1996, and honestly the community is understandably reluctant to permanently alter or extend formally adopted processes with untried new procedures 🙈

There's a middle ground between BCP process updates and informal agreements, and this document is about regularizing and formalizing the informal IESG mechanisms listed in 1 above. The goal is moving forward with procedural changes that might prove valuable ⭐

The mechanisms here add to the IESG's range of tools for dealing with process issues on an ongoing basis. They supplement the existing tools rather than trying to replace them with a single "magic bullet" 🧚 Whether the IESG uses this procedure or some other mechanism, available now or later, is still up to the IESG and the community. If the IESG doesn't use that discretion wisely, this document provides no additional remedies 💀

Some people have read the current procedures as giving the IESG all of the capabilities outlined here. If that's true, this document only encourages the IESG to use this type of mechanism more often instead of less streamlined ones, and to document its actions and decisions more explicitly 🍓

This specification permits and encourages the IESG to adopt and institute "process experiments" using the following procedure 🫶

1. An I-D is written describing the proposed new or altered procedure. A statement of the problem expected to be resolved is desirable but not required, because the intent is to keep the firm requirements for such an experiment as lightweight as possible. Similarly, specific experimental or evaluative criteria are highly desirable but not required. For some of the process changes they anticipate, having the IESG reach a conclusion at the end of the sunset period that the community generally believes things to be better (or worse) will be both adequate and sufficient. The I-D must state an explicit "sunset" timeout, typically not to exceed one year after adoption ⏳
2. If the IESG believes the proposal is plausible and plausibly useful, a four-week IETF Last Call is initiated. The IESG can institute whatever procedures it wishes to make this determination, and to avoid denial of service attacks from large numbers of spurious or unimportant proposals. In particular, it might institute a procedure requiring a number of endorsements, or endorsements of a particular type, before the IESG considers the proposal. The IESG is, however, expected to understand that procedures or review processes that act as a mechanism for significant delays do not fall within the intent of this specification 🐢
3. At the conclusion of the Last Call, the IESG reevaluates the plausibility and appropriateness of the proposal. If they conclude that the proposed experiment is appropriate, a second I-D is generated, either by the IESG or by the original authors with IESG advice. That second I-D cleans up any definitional issues exposed in the Last Call and explicitly identifies and responds to issues raised during it 🔍
4. The document and experiment are then announced, the experiment is begun, and the document is forwarded for publication as an Experimental RFC 🚀

The IESG is explicitly authorized to use this mechanism, which is based on Experimental RFCs, to gain experience with proposed changes to BCP specifications. There's no requirement to approve a BCP specification for the experiment until the experiment is found to have value 👑

The IESG could, of course, reach a "bad idea" conclusion at any stage in this process and abandon the experiment. It might recommend publication of the experimental document, with a discussion of why it was a bad idea, but it isn't required to do so 🙃

The list above is deliberately vague about where the I-Ds come from. A WG, design team, individual contribution, editing group, or other mechanism could be used in the first and/or third steps, but no specific mechanisms are required, and the IESG is explicitly permitted to generate such proposals internally 🌸

Full Copyright Statement 💅

okay so the Internet Society owns the copyright on this one, it's (C) The Internet Society (2004) 🎀. This document is subject to the rights, licenses and restrictions in BCP 78 and at www.rfc-editor.org, and except as set forth there, the authors keep all their rights 🦋.

This document and the info in it are provided "AS IS", and the contributor, the organization they represent or are sponsored by (if any), the Internet Society and the Internet Engineering Task Force all disclaim ALL WARRANTIES, express or implied 🙈. That includes, but isn't limited to, any warranty that using the info here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. ngl this is a lot of legal stuff, but it's giving "use at your own risk" energy ✨.

Intellectual Property

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Info on the ISOC's procedures for rights in ISOC Documents can be found in BCP 78 and BCP 79 📜.

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The same goes for the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights for this specification 🔥.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society 🫶🌈.