RFC 3929

RFC 3929: Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF 🎀

Part 1 of 3 💖

Okay bestie, let's start with the basics. This is RFC 3929 from the Network Working Group, written by T. Hardie at Qualcomm, Inc. 💅 It's marked as Category: Experimental and dated October 2004. The title block doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC 🦋. Its whole job is about what the IETF should do when a working group agrees a decision has to be made but can't agree on what that decision should be 🧚

Status of this Memo ✨

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind 🌸 It's giving "please poke at this and tell us what you think" energy, because discussion and suggestions for improvement are literally requested. Distribution of this memo is unlimited 🫶

Copyright Notice 💜

Copyright (C) The Internet Society (2004).

Abstract 🔥

Okay so this document proposes an experimental set of alternative decision-making processes for use in IETF working groups 👑 Sometimes a working group reaches consensus that a particular decision must be made, but they still can't agree on the decision itself. This doc describes alternative mechanisms for those moments. It's not meant to be an exhaustive list. It's more like a known set of tools you can grab when you need them 🧰✨

1. Introduction 💖

Dave Clark's super-quoted credo for the IETF describes "rough consensus and running code" as the key criteria for decision making in the IETF 🎀 Besides being a cute bit of alliteration, these two touchstones sum up the ideals that guide how the IETF makes decisions. The first implies an open process where any technical opinion gets heard and any participant's concerns get addressed. The second implies that any decision has to be grounded in solid engineering and in the known characteristics of the network and how it's used 🌈 The IETF's aim is to make the best possible engineering choices and protocol standards for the Internet as a whole, and these two principles are what guide it there 💅

Now, in a small number of cases, working groups can't reach consensus on a technical decision that has to be made so that an interoperable mechanism or set of standards is available in some sphere 😭 Most of the time, there are two or more competing proposals at about the same level of technical maturity, deployment, and specification. Sometimes a working group can reach consensus to advance multiple proposals, either to revisit the question with experience or to build the mechanisms needed to handle multiple options for the life of the protocol 🦋 Other times, though, the working group decides it must advance a single proposal 🍓

Choosing between proposals can be really hard, especially when each one is optimized for slightly different use cases. That means the working group's best choice depends on how participants think the thing will be used in the future 🔮 It gets messier when different proposals put implementation, deployment, or usage costs on different groups, because it's a totally normal human reaction to try to keep your own ox from getting gored 🐂🙈

So this document proposes a set of experimental mechanisms for those cases ✨ To gauge how these mechanisms work out, the Last Call issued to the IETF community should note that such a mechanism is being used and which proposal from the set was chosen 📣 If and when the community feels one or more of these methods is useful, it should be documented in a BCP 🌸

In no way should this experiment or any future BCP for this small number of cases take precedence over the IETF's normal mode of operation. Normal operation stays the main character 👑

2. Rough Consensus as a baseline approach 🌈

The Conflict Research Consortium at the University of Colorado lays out the pros and cons of consensus like this:

The advantage of consensus processes is that the resulting decision is one that meets the interests of all the parties and that everyone can support. The disadvantage is that developing such a decision can be a very slow process, involving many people over a long period of time. There is also a relatively high probability of failure. If a quick decision is needed, the consensus approach may not work. Consensus rule processes also tend to favor those that oppose change and want to preserve the status quo. All these people have to do is refuse to support any consensus compromises and they will win (at least as long as they can delay change) [CONFLICT].

Using "rough consensus" as a guideline cuts down on some of those downsides, since it makes sure individuals or small factions can't easily block a decision that already has general support 🫶 The "running code" touchstone helps too, because it requires that statements opposing particular proposals be technically grounded 💅

These limits don't change the core mechanics of consensus-building, though. The IETF process still needs individual participants to use their best engineering judgment to pick among proposals, and to balance their own interests with the Internet as a whole 🧚 Active participation and a willingness to compromise, possibly on key points, are needed. Historically this has worked, because a large majority of participants have recognized that the Internet's growth and enhancement matter more overall than any specific short-term advantage 💖

In other words, "rough consensus" is usually enough in the IETF to make sure individuals or small groups are heard when they raise technical objections, and also that they can't block progress once general agreement has been reached 🎀 This document doesn't suggest changing the usual ways of making progress. It proposes mechanisms for when a working group has consensus that it must make a decision but can't make that decision by the usual rules 🦋

3. Conditions for use 👑

In general, working groups should consider using alternate decision-making processes when it's clear both that a choice must be made and that the choice can't be made with continued discussion, refinement of specifications, and implementation experience 💅 A guideline for checking whether those conditions are met is included below 🔍

3.1. There is a clear decision to be reached 🍓

There must be a clear statement of the decision to be reached 📝 That might live in the working group's charter, in requirements documents, or in other documents the working group has developed. Before any alternate decision-making process gets invoked, the Chair(s) should confirm with the working group that there's general agreement on the decision to be reached. This should include a specific consensus call on whether the working group can advance multiple proposals or must select a single proposal for the work item 🌸

3.2. Proposals are available in Draft form 💜

Proposed solutions must be available as Internet-Drafts, and they must be specified well enough that the Chair(s) believe they could be published as an IETF specification, possibly after further refinement 📄 If the Chair indicates that a proposed solution is insufficiently specified, concrete problems must be identified, and a reasonable amount of time must be provided to resolve those problems 🕰️ Also, if one of the proposed solutions is "do nothing", an explicit Draft to that effect must be available. It may, however, be produced when the group invokes an alternate decision-making process 🦋

3.3. The working group has discussed the issue without reaching resolution 🌈

Consensus-building takes a ton of discussion, and there's no general rule for how much discussion a technical issue needs before a group should reach consensus 💬 If there's any question about whether the discussion has been sufficient, the working group chair(s) should always err on the side of letting discussion continue 🫶 Before using an alternate decision making process, the working group chair(s) should also make an explicit call for consensus, summarizing the technical issues and the choice to be made. If new technical points come up during that call for consensus, discussion should continue. If no new points are raised but the group still can't come to consensus, the working group may consider using an alternate decision making process 🎀 Under no circumstances is the working group required to use an alternate decision-making process. No pressure, bestie 🙅‍♀️💖

3.4. There is an explicit working group last call to use an alternate method 📣

As noted in item 3.3 above, the Chair(s) should make an explicit call for consensus on the technical issues, and should only proceed once that call has produced no forward progress 🔁 A different Last Call is then required on whether to use an alternate decision-making method, with a stated period for comments from working group members. This signals that the decision to use an alternate method should be taken at least as seriously as the decision to advance a document on the standards track 🔥 It also sends a clear signal that this is the last moment for participants to reconsider their positions 😳 The decision to use an alternate decision making process requires the rough consensus of the working group, as determined by the Chair(s). The choice of which process to use may be made in the Last Call, or it may be the subject of separate discussions within the working group 🧚 If the group comes to consensus that an alternative method is required but doesn't come to consensus on which method to use, an external review team (c.f. section 4.1, below) will be formed 👑

In discussions about this document, several points have been raised about whether any mechanism requiring consensus to use an alternative to consensus-based decision making is even viable 🤔 Some individuals have pointed out that groups having trouble achieving consensus on a technical matter may have similar problems achieving consensus on a procedural matter ✨ Others are worried this will be used as an attempt to end-run around rough consensus 😬 These are valid concerns. They point both to the need to keep rough consensus as the baseline mechanism and to the need to exercise caution when using these alternate methods 🫶 More importantly though, they highlight the nature of these alternatives. They're primarily mechanisms that let people recognize the need for compromise in a new way, by backing away from entrenched technical positions and putting the technical choice in the hands of the broader community 🌸 They also highlight that the choice for each participant is now between achieving a result and failure 💀

There's a fundamental tension between the IETF community's desire to get the best decision for a particular technical problem and its desire to get a decision that has community buy-in in the form of rough consensus 🥹 These mechanisms can't resolve that fundamental tension. They may, however, provide a way forward in some situations that might otherwise end in deadlock or stagnation 🌈✨

4. Alternate Methods ✨

okay so bestie, this section is basically the "what if we can't agree and consensus is stuck" backup plan 🫶 the writer gives us a straw proposal for four mechanisms, and they're deliberately heavyweight. that's on purpose, so nobody invokes them lightly and the whole IETF community stays in the loop 👀 the way that it's set up, the process has to stay open and focused on the best technical choice for the Internet as a whole 💅 and yeah, alternate procedures have happened before! see [RFC3127] for the AAA protocol showdown 🎀 this doc isn't trying to box in working groups, it just gives them well-defined processes so they don't have to reinvent the wheel every time 🌸

4.1. Alternate Method One: External Review Team Formation 🦋

the working group announces on the IETF-announce mailing list that it's forming an external review team 📣 the announcement should include a summary of the issue to be decided and a list of the Internet-Drafts with the alternate proposals. it should also name an archived mailing list for the review team's deliberations, plus where to find it 🗂️

4.1.1. External Review Team Membership 👑

okay this part is giving eligibility vibes 💅 the review team has five members, and they MUST meet the same eligibility requirements as a voting member of the NomCom [RFC3777]. people who've posted to the relevant working group mailing list in the last twelve months are excluded, and so are the IESG, the IAB, and anyone on an active NomCom 🙈

if you want to be on the team, send your name to the IETF executive director. if more than five people volunteer, five get picked using the process in [RFC3797] 🎲 the same affiliation rules as the NomCom apply here too, so no one org can pack the team and nobody can say it's been packed 🫶

working group participants can totally hype up other people to volunteer 📢 but they can't serve themselves if they've commented on the list in the past twelve months. no sneaking in 🙅‍♀️

4.1.2. External Review Team Deliberation ⏳

the review team gets one month for deliberations 🗓️ any member can stretch that by two weeks, but they have to let the relevant working group Chair(s) know the extension will be needed ✨

the team commits to reading the summary from the IETF announcement and all of the relevant Internet-Drafts 📚 members can also read the working group's archived mailing list and ask the document authors, the working group chairs, or any other technical experts for clarifications 🧠 all of those asks, plus all the group deliberations about the proposals, MUST happen on the archived mailing list from the announcement. one-on-one chats by phone, email, or in person are fine, but the group stuff stays on the list 💜

4.1.3. Decision Statements 📝

each team member writes a short decision statement, max one page 📄 it MUST contain a list of the proposals in preference order. it MAY also include a summary of their analysis of the problem and the proposed solutions, but that part isn't required 🌈 the statements go to the archived mailing list, the relevant working group chair(s), and the IESG 💌

4.1.4. Decision Statement Processing 🧮

the decision statements get tallied with "instant-runoff voting" rules, also called "preference voting" rules [VOTE] 🔥

4.2. Alternate Method Two: Mixed Review Team 🌀

this one lets the working group pick a review team that mixes outsiders with people who were already part of the working group process 🤝 it might seem like having one rep per proposal wouldn't change the outcome, but it usually does, except when there's a binary choice, because of the decision-statement rules (c.f. 4.1.4.) 🤯 just like 4.1, the working group announces on the IETF-announce mailing list that it's forming a mixed review team 📣 that announcement should have the issue summary, the list of alternate Internet-Drafts, and the name and location of an archived mailing list for the review team's deliberations 🗂️

4.2.1. Mixed Review Team Membership 🎀

a mixed review team has one designated representative for each proposal, usually the Internet-Draft's principal author, plus six external members 💖 five of those external members are picked per 4.1.1. above. the sixth is designated by the IESG as chair of the group. the chair's main job is making sure the process gets followed, but she or he MAY vote and join the deliberations 🫶

4.2.2. Mixed Review Team Deliberation ⏰

the review team gets one month for deliberations, and any member can extend that by two weeks by letting the review team Chair know the extension will be required 🌸

the review team commits to reading the summary from the IETF announcement and all of the relevant Internet-Drafts 📚 members can also read the working group's archived mailing list, and check in with any other technical experts they like 🧠 all of those solicitations and all the review team's deliberations about the proposals MUST take place on the archived mailing list from the IETF announcement 💜

4.2.3. Decision Statements 📝

same as 4.1.3, above ✨

4.2.4. Decision Statement Processing 🧮

same as 4.1.4, above 🔥

4.3. Alternate Method Three: Qualified Short-Straw Selection 🍓

same energy as 4.1 and 4.2: the working group announces on the IETF-announce mailing list that it plans to use an alternate decision mechanism 📣 the announcement should have the issue summary and the list of alternate Internet-Drafts 🗂️

here, ONE working group participant gets picked to make the call 👑 anyone who contributed to the working group in the twelve months before the working group Last Call on the technical question (c.f. 3.3, above) can volunteer. people count as participants if they made a public statement on the working group mailing list, authored an Internet-Draft under consideration by the working group, or made a minuted comment at a public working group meeting 🎤 the Chair(s) MUST NOT volunteer. each qualified volunteer sends their name to the working group chair and the IETF Executive Director within three weeks of the IETF-announce message 📬 the IETF Executive Director then uses the selection procedures in [RFC3797] to pick a single volunteer from the list 🎲 that volunteer decides the issue by naming the Internet-Draft with the selected proposal in an email to the relevant working group chair, the working mailing list, and the IESG 💅

4.4. Alternate Method Four: Random Assignment 🎰

okay so this is the most niche one 🙈 consensus isn't the right tool for a small number of cases, and an even smaller number of those have zero technical points and just need a random pick. the IDN working group is the example here: it needed to designate a specific DNS prefix, and because the decision was about early access to a scarce resource, a random selection was required 🧚 in those cases, a working group MAY ask IANA to make a random assignment from a set of clearly delineated values. IANA will be guided by [RFC3797] in its selection procedures 🫶 and in extraordinary circumstances, the working group MAY, with the approval of the IESG, ask IANA to pick among a pool of Internet-Drafts this way 🌈

5. Appeals ⚖️

technical decisions from these processes can be appealed under the same rules as any other working group decision 💜 the one catch: the working group's consensus to use an alternate method stands in for its consensus on the technical issue 🫶

6. Security Considerations 🚨

💀 okay this is the serious bit, bestie. moving to a system like this shifts the basis of decision making within the IETF 😭 the hope is that decisions that would be stuck under consensus rules can actually get reached under these rules. the risk? forcing the evaluation to happen under these rules might let people game the system 🙀

7. IANA Considerations 🧚

section 4.3 may require IANA to make random selections among a known set of alternates 🎲

8. References 📚

8.1. Normative References 💖

[RFC3797] Eastlake, D., "Publicly Verifiable Nomination Committee (NomCom) Random Selection", RFC 3797, June 2004.

[RFC3777] Galvin, J., Ed. "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.

8.2. Informative References 🌸

[RFC3127] Mitton, D., StJohns, M., Barkley, S., Nelson, D., Patil, B., Stevens, M., and B. Wolff, "Authentication, Authorization, and Accounting: Protocol Evaluation", RFC 3127, June 2001.

[VOTE] Center for Democracy and Voting. "Frequently Asked Questions about IRV", http://www.fairvote.org/irv/faq.htm.

[CONFLICT] International Online Training Program on Intractable Conflict,"Consensus Rule Processes", Conflict Research Consortium, University of Colorado, USA. http://www.colorado.edu/conflict/peace/treatment/consenpr.htm

10. Acknowledgements 🫶

the author wants to give a huge shoutout to everyone who reviewed this document and gave challenging exchanges, including John Klensin, Dave Crocker, Pete Resnick, Spencer Dawkins, Scott Bradner, Joel Halpern, Avri Dora, Melinda Shore, Harald Alvestrand, Alex Simonelis, Keith Moore, Brian Carpenter, and Alex Rousskov 💅✨

11. Author's Address 🦋

Ted Hardie Qualcomm, Inc. 675 Campbell Technology Parkway Suite 200 Campbell, CA U.S.A.

EMail: hardie@qualcomm.com

Full Copyright Statement 🌈

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

Intellectual Property ✨

Okay bestie, so the IETF is basically saying it has NOT picked a side on whether any IP rights (like patents or other proprietary stuff) apply to the tech in this doc, or whether you can actually get a license for them. It also didn't go hunting for those rights itself 💅. If you want the full tea on how the IETF handles rights in its docs, check out BCP 78 and BCP 79 🎀.

Now, if you want copies of IPR disclosures that were sent to the IETF Secretariat, or assurances that licenses will be available, or the results of anyone trying to get a general license or permission to use those proprietary rights as an implementer or user of this spec... it's all in the IETF's online IPR repository at http://www.ietf.org/ipr 🦋.

Last bit, and it's important: the IETF invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard to tell them. Send it to ietf-ipr@ietf.org 🫶 no cap, speak up if you know something!

Acknowledgement 💖

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