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

[todd glassey]

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


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

Chore...  (sorry what  meant to say is that its not the WG's chore to...)

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