[Fwd: Re: rough consensus (was Re: "trouble maker")]

[hardie at qualcomm.com]

When I was writing a recent draft on alternative consensus mechanisms, I felt
like the IETF process needed a little more context than 2418.  The text is
below, and improvements on it would be welcome 
(from draft-hardie-alt-consensus-00.txt)

. Introduction.

     Dave Clark's much-quoted credo for the IETF cites "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 which 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 statements guide it in making
     its choices and standards.

<snip>

2.  Rough Consensus as a baseline approach.

     The Conflict Research Consortium at the University of Colorado
     outlines the pros and cons of consensus as:

	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 limits some of
     disadvantages of consensus processes by ensuring that individuals
     or small factions cannot easily block a decision which has
     otherwise general support.  The second touchstone of "running
     code" can also limit the disadvantages of consensus processes by
     requiring that statements opposing particular proposals be
     technically grounded.

     These limitations do not change the core mechanisms of
     consensus-building, however, and the IETF process continues to
     require individual participants both to use their best engineering
     judgment to select among proposals and to balance their own
     interests with those of 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 are more important overall than any
     specific short-term advantage.

     In other words, the use of "rough consensus" is sufficient in most
     cases in the IETF to ensure that individuals or small groups are
     heard when they raise technical objections, but that they cannot
     block progress when a general agreement has been reached.  This
     document does not suggest changing the usual mechanisms for
     achieving forward progress; it proposes mechanisms for use when a
     working group has consensus that it must make a decision, but it
     cannot make that decision by the usual rules.
    


At 7:19 PM +0800 7/16/03, James Seng wrote:
>There are two parts here : Rough consensus process and rough consensus itself.
>
>RFC 2418 defines the process but leave the 
>definition of rough consensus vague, leaving it 
>to the chair.
>
>I am not saying the process have problem. I am 
>saying we need to clarify the latter so everyone 
>at least have some baseline understanding of 
>what "rough consensus" is.
>
>-James Seng
>
>Brian E Carpenter wrote:
>
>>Harald Tveit Alvestrand wrote:
>>
>>>the RFC 2418 definition is as follows (section 3.3):
>>>
>>>   Working groups make decisions through a "rough consensus" process.
>>>   IETF consensus does not require that all participants agree although
>>>   this is, of course, preferred.  In general, the dominant view of the
>>>   working group shall prevail.  (However, it must be noted that
>>>   "dominance" is not to be determined on the basis of volume or
>>>   persistence, but rather a more general sense of agreement.) Consensus
>>>   can be determined by a show of hands, humming, or any other means on
>>>   which the WG agrees (by rough consensus, of course).  Note that 51%
>>>   of the working group does not qualify as "rough consensus" and 99% is
>>>   better than rough.  It is up to the Chair to determine if rough
>>>   consensus has been reached.
>>>
>>><solutionism>
>>>how could this definition be modified to be more useful?
>>
>>
>>I doubt if it can, unless we radically change our open door
>>policy.     Brian
>>
>>></solutionism>