Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF
RFC 3929
Document | Type |
RFC - Experimental
(October 2004; Errata)
Updated by RFC 8717
Was draft-hardie-alt-consensus (individual in gen area)
|
|
---|---|---|---|
Author | Ted Hardie | ||
Last updated | 2015-10-14 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3929 (Experimental) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Harald Alvestrand | ||
Send notices to | (None) |
Network Working Group T. Hardie Request for Comments: 3929 Qualcomm, Inc. Category: Experimental October 2004 Alternative Decision Making Processes for Consensus-Blocked Decisions in the IETF Status of this Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document proposes an experimental set of alternative decision- making processes for use in IETF working groups. There are a small number of cases in IETF working groups in which the group has come to consensus that a particular decision must be made but cannot agree on the decision itself. This document describes alternative mechanisms for reaching a decision in those cases. This is not meant to provide an exhaustive list, but to provide a known set of tools that can be used when needed. 1. Introduction Dave Clark's much-quoted credo for the IETF describes "rough consensus and running code" as the key criteria for decision making in the IETF. Aside from a pleasing alliteration, these two touchstones provide a concise summary of the ideals that guide the IETF's decision making. The first implies an open process in which any technical opinion will be heard and any participant's concerns addressed; the second implies a recognition that any decision must be grounded in solid engineering and the known characteristics of the network and its uses. The aim of the IETF is to make the best possible engineering choices and protocol standards for the Internet as a whole, and these two principles guide it in making its choices and standards. In a small number of cases, working groups within the IETF cannot reach consensus on a technical decision that must be made in order to ensure that an interoperable mechanism or set of standards is Hardie Experimental [Page 1] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004 available in some sphere. In most of these cases, there are two or more competing proposals at approximately the same level of technical maturity, deployment, and specification. In some cases, working groups can achieve consensus to advance multiple proposals and either to revisit the question with experience or to build the required mechanisms to handle multiple options for the life of the protocol. In other cases, however, a working group decides that it must advance a single proposal. Choosing among proposals can be difficult especially when each is optimized for slightly different use cases, as this implies that the working group's best choice depends on the participants' views of likely future use. Further problems arise when different proposals assign costs in implementation, deployment, or use to different groups, as it is a normal human reaction to seek to prevent one's own ox from being gored. This document proposes a set of experimental mechanisms for use in such cases. To gauge the results of the use of these mechanisms, the Last Call issued to the IETF community should note such a mechanism is being used and which proposal among the set was chosen. If and when the community becomes satisfied that 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. 2. Rough Consensus as a baseline approach The Conflict Research Consortium at the University of Colorado outlines the pros and cons of consensus as follows: 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]. Hardie Experimental [Page 2] RFC 3929 Consensus-Blocked Decisions in the IETF October 2004 Using "rough consensus" as a guideline limits some of the disadvantages of consensus processes by ensuring that individuals orShow full document text