Subject: RE: rough consensus (was Re: "trouble maker")

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Jun 2003 11:31:20 -0700

I think it also depends on what the stake the parties have.

If we have 20 people vote on an issue (lets call things by their names eh?
it is still a vote even if the supreme court decides not to count it).

Say people object because they want the spec to require implementations to
use some proprietary IP they own. Pretty easy call, could be 5 objectors or
15 there is something going on here that is an IETF-wide issue.

Say on the other hand you have an issue that is hard to implement. In that
case 5 objections from non-developers might carry much less weight than 5
from developers.

Or say again that you have a case where cost is involved. Objections from
five people who are unaffected by the cost issue might carry much less
weight than five objections from people directly affected.

But of course, nobody represents anything, nobody can speak from authority
except those the establishment choose to recognize. So we are back to raw
numbers.

Going back to my case study (yes facts are sometimes unplesant things) the
objections to the spec did not come from people with a stake in the outcome
- except for those who had stated their objections were explicitly political
and wanted to use DNSSEC to force some sort of change in the ICANN
contracts.

So what does the consensus process do except create inbuilt vetos in favor
of the status quo?

The fact that a spec has been undeployable for ten years is in my view and
that of most software vendors a comment on its quality.

As I said to Keith in private email, what you are doing here is projecting
on a massive scale. You are affraid that the big corporations will dominate
the process so you have rigged the rules so that they have zero influence -
even though you depend on their market influence to propagate standards. Now
you are surprised that we are abandoning the IETF in droves?

Compare the decline in IETF attendance with the rise in OASIS participation.
If the reason was the post dotcom boom recession then OASIS should have been
affected at least as baddly as IETF.

Contrary to the paranoid assumptions that many in this group appear to act
on corporations do not in general want to exclude the academic and
individual contributors from the standards process. But the way the IETF
rules are being applied are leaving little choice in the matter.

		Phill

> -----Original Message-----
> From: James Seng [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2003 2:11 PM
> To: Hallam-Baker, Phillip
> Cc: 'Thomas Narten'; [email-masked]
> Subject: rough consensus (was Re: "trouble maker")
> 
> 
> Maybe lets put this particular case aside and look at the 
> more general 
> problem:
> 
> "What is rough consensus?" How rough is "rough"?
> 
> Unfortunately, this was not particular well-defined even tho 
> it is one 
> of our core principle. Could we tag this as a problem in the 
> problem-statement?
> 
> I remember I asked this questions before when I am a newbie 
> in IETF. The 
> general answer of "rough consensus" are super-super majority.
> 
> The general figure is >75%-80% but bear in mind that we dont "vote", 
> absolute figures isnt the way to go. We also need to take 
> those who are 
> "neutral" into considering as "neutral but wont object" and 
> "no but wont 
> object strongly" are important swing factor.
> 
> If we can get a rough consensus on what is "rough consensus", then 
> perhaps we could avoid a lot of misunderstanding.
> 
> -James Seng
> 
> Hallam-Baker, Phillip wrote:
> > Count the votes as 12:2 or 12:9 there was a clear majority 
> for OPT in and
> > the 7 who said no but were willing to stand asside for the 
> sake of forward
> > progress.
> > 
> > However you count them a clear majority of the group 
> believes that the
> > DNSSEC specs as currently defined are broken and are in 
> need of fixing. Why
> > then are ANY drafts being forwarded to the IESG?
>

---

From: James Seng <[email-masked]>
Date: Thu, 26 Jun 2003 03:35:04 +0800

While we dont have the concept of "stakeholder", we have a concept of 
"running code". This is another swing factor in the consideration of 
"rough consensus".

Someone also reminded me that sometimes you need as high as 95% for 
rough consensus and sometimes as low as 65%, varies according to the 
topic and the situation.

So really, there is no any fixed methodology in determine rough 
consensus and the current process leave it to the wg chairs to determine 
"rough consensus". To balance this power, the appeal process was there 
to catch the exception case.

Since everyone has their own interpretion of what is "rough consensus", 
I can understand the resentment for those who lost out. And the wg 
chairs is in this unfortunate position of been the center of this 
resentment.

But please spare a thought for the wg chairs too. They are in this "damn 
if you do, damn if you dont" position...

-James Seng

---

From: Melinda Shore <[email-masked]>
Date: Wed, 25 Jun 2003 16:21:49 -0400

> rough consensus and sometimes as low as 65%, varies according to the 

When you frame the question of "rough consensus" in terms of
percentages you're actually framing it in terms of voting,
which we don't do for a number of reasons.  "Consensus" is
really about the process of arriving at decisions rather
than the decisions themselves - making sure that all voices
are heard and respected, and that what you're doing is
synthesizing information rather than selecting from
available options.  By choosing "rough consensus" we're
providing ourselves some protection, in theory, against
holdouts. 

We do consensus *incredibly* badly.  One of the primary
reasons is that it requires commitment to the process
itself - to negotiation, compromise, and a willingness to
accept and move forward with the outcome of the process.
All too often we lack that commitment and it's causing some
big process problems, including the "obstructive individual"
problem that you've raised.

Melinda

---

From: [email-masked]
Date: Wed, 25 Jun 2003 14:12:12 -0700

>providing ourselves some protection, in theory, against

I tried to cover some of the same points in draft-hardie-alt-consensus-00.txt,
which uses steals this text to describe some of the problems using
consensus in our context:
>
>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)

I then tried to capture some of the differences between rough consensus
and consensus

>
>     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.

Discussion of the draft, and the mechanisms it proposes for use in
these cases does not belong here ([email-masked] would be
one place to discuss it), but the recognition of the shape of the problem
is important to scoping how individuals or small groups can affect
the normal process.

			regards,
				Ted Hardie