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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 or