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

[todd glassey]

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <harald at alvestrand.no>
To: "James Seng" <jseng at pobox.org.sg>; <problem-statement at alvestrand.no>
Sent: Wednesday, July 16, 2003 3:29 AM
Subject: Re: [Fwd: Re: rough consensus (was Re: "trouble maker")]


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

So OK then Harald - who decides what constitutes a concensus then? The WG
Chair? and then what is the minimum number of members that need to vote, or
how is a quorum created? becuase without some form of voting, I see that
there is no real way to measure anything... let alone a concensus.

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

OK So all the parties on whoever's payroll all vote the same.

>    Consensus
>    can be determined by a show of hands, humming, or any other means on
>    which the WG agrees (by rough consensus, of course).

So then the WG, can select its own type of concensus, making NONE of the
efforts of achieving concensus comparable to each other. This is a glaring
flaw in the process since it essentially says that each WG can do whatever
then hell it wants with no regard for consistancy.


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

So here again - we have some basic number stating that more than 52% is
considered a concensus. But that above 52%, and its the WG Chair's
responsibility to declare the concensus reached. So let me paint a picture
hypothetically...

So I come up with a new backbone protocol so revolutionary that it threatens
to rock the world, and I expose it to the IETF under terms not totally
inline with the full releases in RFC2026's SS10. Cisco or other large IETF
participant notices that I have something that potentiallty could kick their
ass in the marketspace, and so they flood the WG that I got the IETF to
allow me to start on this with bodies. These bodies do two things, they
create chaos in the process and effectively STOP me from advancing the
protocol...

The question is how the IETF's processes can prevent the scenario that I
just painted, and my apologies to Big John and the Tasman Avenue crowd, no
offense was intended here, but the fact is that any large player in the IETF
has a clear, everpresent, and very unfair advantage here, and the IETF's
processes are setup to allow this to happen and that's the issue.

>
> <solutionism>
> how could this definition be modified to be more useful?

    1)    Define the formal vetting process and the steps involved - this
will take a revision to RFC2026 and the standards process.

    2)    Define the minimum number of participants needed to constitute a
vetting process, and  allow for any number of standards initiatives in the
same WG. It is not the WG's choir to pick the dominent player in the
marketplace. Its their responsibilty to "create interoperable standards" not
lock others out of the marketplace.

    3)    Put in place a real oversight process instead of the loosely
defined methods now woven through RFC2026 and the other Operating Documents
herein. This includes Management Oversignt as well and having some formal
mechanism for the members of a WG to oust the WG Chair and how many members
it takes to do that.



> </solutionism>