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 (C) The Internet Society (2004).
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.
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
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
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]