Re: [wg-review] The Number 1 Problem

[Greg Burton <sidna@feedwriter.com>]

At 10:58 PM 1/7/01, Kent Crispin wrote:
>On Sun, Jan 07, 2001 at 05:13:11PM -0700, Greg Burton wrote:
> > this is not aimed at  you or any other specific person.
>
>I don't mind.  I hope you will take the following in the same spirit:

Of course :)

>Nothing you say below is new -- really, nothing.

I didn't think it was. Most of the description of the broken code process 
(aka so-called consensus) comes from comments real people have made about 
the real process here. Consider it a summary.

>Your hymn to "real consensus" was very passionate, but unfortunately, it
>gave no evidence understanding of the IETF process, and that is really
>too bad.

The IETF process may be wonderful - we're talking about the ICANN/DNSO 
broken code process, which, whatever it was based on, is not wonderful.

>... the IETF consensus process handles a problem that your "real 
>consensus" does not, and can not, deal
>with: "real consensus", as you describe it, can be forever blocked by 
>someone who really wishes to obstruct it.  "Real consensus", that is, 
>doesn't handle the problem of bad actors, and it can't, by definition.
>
>And it is a simple fact that there are bad actors in the ICANN orbit.
>There are people who really do want ICANN to fail, period.  That's why
>"rough consensus".

Equally solvable by using the RRO modifications Karl keeps pointing us to, 
or other methods. The current methods might work better if people didn't 
think they were buying into a consensus process. Perception counts.

Has it ever occurred to you that fewer people might want ICANN to fail if 
they believed it was actually operating with the ideals it claims?

>"Real consensus" is not achievable

Ah wonderful! I believe this is EXACTLY what Milton has said. Nice to find 
an agreement here. Under the current system, and at this time I agree, too. 
So does Karl. So does Roeland. So does Joop. So let's end the denial and 
stop calling it that.

>It's an engineering solution, not a religious one.

Code that crashes the system every time it's invoked is not running code.

>I'm sorry that Joe Sims didn't make it more explicit in the bylaws that he 
>wasn't using
>"consensus" in your sense of "real consensus", but the simple fact is
>that he was not.

My sense of "consensus" is the manner it is COMMONLY understood in - at 
least outside the IETF. Since you say the intention was not to use it as is 
commonly understood, it is misleading. QED. Since ICANN's legal counsel is 
highly paid and has a reputation for being really good at what they do, 
isn't it understandable that some people might feel that such lack of 
explicitness reflects a deliberate intention, rather than gross negligence?

>Concrete experience has demonstrated that your notion
>of "real consensus" is not adequate to the problem domain.

Problem domain =Nice pun. However, concrete experience has demonstrated 
that the current broken code is not adequate. I am unaware of ANY attempt 
to apply formal consensus procedures within ICANN. Could you point me to 
the documentation of where it was tried?

>The IETF "rough consensus" process is notable for its success in an 
>environment with
>many of the same characteristics as ours.

Wow - the IETF environment includes a requirement for determining social 
policy issues, complex matters of determining "rights" in multiple 
jurisdictions based on differing legal codes,  and a 
governmentally-required mandate to operate inclusively? I didn't know that. 
Must be why it's part of this SO. Oh, it isn't.......

The DNSO's broken code process is notable for it's outstanding and 
persistent failure in our specific environment. The IETF process worked 
really well in '95, didn't it? Does that have anything to do with why we're 
discussing this inside something called ICANN?

>In the following *you* have created an incoherent strawman you call 
>"so-called consensus", and then made the
>case that it is incoherent.  Yes, of course your strawman is incoherent, 
>since you constructed it that way.  But your strawman doesn't relate at 
>all well to reality...

No? Funny then that so much discussion and outrage has occurred over these 
points. The straw man is alive and well, and seems to be humming "if I only 
had a brain".

>I have interposed a few comments:
>
> > -----------------------------
> > Real consensus cannot be imposed - it must be accepted by all the people
> > involved.  So-called "consensus" doesn't care whether or not the people
> > involved understand the process.
> >
> > Real consensus is not concerned with capture, because real consensus can't
> > be captured, only achieved. So-called "consensus" is concerned with 
> capture
> > because it is afraid of power shifts.
>
>It is all very well to be concerned about everybody involved understanding 
>the
>process, but ICANN has a steady flux of newcomers that must be brought
>up to speed.

1. Ongoing Education
2. A written introduction to the process
3. Written rules and procedures
4. Explicit definitions

Has anyone seen any of those? No? If none of this is new, where in the 
world are these really simple means of ameliorating that situation?

> > Real consensus cannot be declared - it can only be recognized by the 
> people
> > who have participated in the process. So-called "consensus" allows people
> > outside the process to decide what "consensus" is.
>
>An absolute requirement ICANN faces is that it must document its
>decisions.  Hence, labels are required.  It would be nicer not to have
>to label -- I agree -- but those pesky lawyers need to see things in
>writing.

Which does not address why the label needs to be "consensus", does it?

> > Real consensus focuses on where the people involved can agree and builds
> > from there. So-called "consensus" counts votes or calculates power blocks
> > before attempting anything.
>
>You say the same thing twice, once in glowing terms, and once in
>perjorative terms.  In both cases you are checking where people agree
>before proceeding.

Nope. If we start with an explicit statement and discuss it in order to 
understand the various positions involved, we haven't checked anything 
before proceeding.

> > Real consensus is inclusive and civil. So-called "consensus" uses 
> ridicule,
> > personal attacks, red herrings, and a "rough" process to eliminate or
> > discredit those who disagree with those holding the majority of power, and
> > to harass those perceived as holding power.
>
>Don't know what you mean here -- seems like you just threw the kitchen
>sink at your strawman "consensus".

See "History of the Working Groups, Part 1" - directed by Mel Brooks and 
playing on a monitor near you.

> > Real consensus abjures the "power of the chair" in favor of the
> > powerlessness of the clerk. So-called "consensus" elevates the power of 
> the
> > chair.
> >
> > Real consensus works toward articulating explicit statements - be they
> > policy statements or action directives - on which the group can agree.
> > So-called "consensus" operates on hidden agendas and ambiguous or vague
> > language that cloaks the intent and mystifies any potential opposition.

No attempt at arguing against these. Ignoring them doesn't make them go 
away. Dang, that humming is getting loud.

> > Real consensus has real rules of process which are agreed to by everyone
> > participating, and doesn't proceed until everyone understands the rules.
>
>Once again, this assumes a static population.

No, actually it doesn't. It assumes that you establish general and explicit 
rules and procedures ahead of time and publish them. You create an 
"education about our process" list. When you create a WG participants 
explicity agree to the rules when they sign up, and you direct them to the 
process list and the published rules so that they CAN understand them if 
they don't already.

For crying out loud - this is NOT rocket science.

> > So-called "consensus" allows a governing body to create rules and
> > procedures "as they see fit".
> >
> > Real consensus works for full understanding by all participants. So-called
> > "consensus" redefines words to disguise the process of mystification.
>
>You know, in all honesty, I don't know what you mean in the above
>sentence  ;-)

See the bylaws :)

> > Real consensus requires explicit agreement or disagreement. So-called
> > "consensus" allows subjective interpretation of the "mood of the group" by
> > some power figure.

You didn't address this, and since one of the goals of this whole process 
is to decrease subjective measures and increase objective ones, I would 
have thought it was key.

> > The white paper mandates consensus. Instead of actually trying to 
> determine
> > how to achieve real consensus, putting any resources into it, or educating
> > people about consensus, the mandate was papered over by using the word
> > without definition.
>
>Had they been explicit, they would not have used your notion of "real
>consensus", that is for sure.

Once again, we agree on something :)

> > The real root of the problem is that what is being passed off as
> > "consensus" within ICANN is a travesty and a lie. Once you understand
> > that,  to refer to it as consensus or accept the use of consensus to
> > describe the process, you participate in and validate the lie.
>
>Sorry you feel that way.  I agree that the notion of consensus used in
>the ICANN context is not as pure, in some sense, as your "real
>consensus".  I do not agree with you that the notion of consensus used
>in ICANN is therefore evil.

The "notion" may even be good - the implementation and effect is pernicious.

>The above writing strikes me as a pretty egregious strawman argument,
>to tell you the truth.

Sorry, Kent - I can't hear you over his humming. Wonder why he thinks music 
from "the wizard of oz" is relevant.

Regards,
Greg
sidna@feedwriter.com

--
This message was passed to you via the wg-review@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe wg-review" in the body of the message).
Archives at http://www.dnso.org/archives.html