ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] RE: Consensus on consensus?


David Johnson, I might add, does understand what "consensus" means:
"It's not about empowering a new regulatory structure. It's about talking
(hopefully, mostly, online) until we can figure out what most of those
involved DO agree upon. It's about... consensus."

Bill Lovell

"Johnson, David" wrote:

Any restructing plan must deal with the problem of the tyranny of the
majority (or even supermajority).
In a governmental structure, this might be handled by creating certain
"rights" -- e.g., against "takings" or inequitable treatment.
It's precisely the absence of such protections in the context of a private
ICANN that gives rise to the need to construct a documented consensus,
rather than just counting votes. (Even the votes of every individual
participant, as Danny suggests, because even that doesn't confer legitimacy
when the individual participants are self-selected and don't necessarily
bear the burdens of the rules they collectively make.)

I'm sorry to sound like a broken record on this, but ICANN's powers must be
based on the "consent of the governed" -- and that requires that those
required to follow the rules (and impacted by the rules) must agree to abide
by them. For future rules, this inevitably means a "bargain" in which those
signing up to follow ICANN's regime agree not to be irrational holdouts --
but it simply cannot realistically lead to a regime in which those who might
be bound by the rules agree to the outcome of a board resolution, or an at
large vote, no matter what it might be, no matter how inequitably the
burdens are distributed, etc.

I acknowledge that very few in the ICANN process have seemed to "get" the
idea of consensus (and that the idea has been much abused by false claims
regarding its existence). And I agree with those who have suggested the
value of some more formal (and open) processes to generate a record that an
IRP could uphold. But all of the plans that have suggested re-jiggering
board seats to create an authority that simply legislate rules ... miss the
point ... and make the same mistake that the ICANN Board made in Singapore.

For those who argue that consensus has failed because it's too hard to get a
consensus on many issues, I must respond that: "you don't get it!" The point
is NOT to make rules where there is substantial, principled disagreement
from those with a stake. The point is to NOT make rules where there is such
disagreement. (And to allow, in effect, local option.)

Democracy is not the answer here. Because there is no way to define a
satisfactory "demos" -- an engaged citizenry consisting of most of those
affected by the rule making institutions.

I personally think there is a way to shrink ICANN's mission back to the
(still formidable) task of attempting to catalyze agreement on global issues
that require coordination. The route mapped by too many of the "reform"
proposals leads to creation of a global regulator that might be more
"effective" but that would lack any claim to legitimacy based on "consent of
the governed" -- in the sense that the welfare and goals of those affected
by the rules would govern what rules are made. A much more promising route,
in my view, is to introduce real competition at the registry level so that
the competition between diverse rule sets (as adopted by registries) can
allow the market to provide the voice for the "governed" to be heard. That's
why it is important not to allow the development of objective minimum
qualifications for new TLDs to slip off the agenda. And that's why those
calling for reform, in various ways, need to think outside the box of
traditional regulation and legislation -- and ask themselves when those
voluntarily connecting to an inter-network should (and will) agree to abide
(in the unforeseeable future) by policies with which they don't happen to
agree at the time.

The basic bargain that gave rise to ICANN was not (1) a delegation of power
from the USG, (2) a conspiracy among a technical elite, or (3) an upwelling
of virtual nation building by netizens. It was, instead, the shared view
that everyone involved in the dns ought to be willing not to "hold out" for
selfish advantage if most of those similarly situated and similarly affected
were willing to go along with the general view that a global rule is needed.
That's the deal. It's not about voting (though some voting might be useful
to most the discussion along). It's not about empowering a new regulatory
structure. It's about talking (hopefully, mostly, online) until we can
figure out what most of those involved DO agree upon. It's about...
consensus.

-----Original Message-----
From: DannyYounger@cs.com [mailto:DannyYounger@cs.com]
Sent: Tuesday, March 26, 2002 8:05 PM
To: ga@dnso.org
Cc: DJohnson@wilmer.com
Subject: Consensus on consensus?

Karl Auerbach in his "Prescription-to-Promote" has argued that:  "The
concept
of "consensus" must be discarded", with all decisions to be based on counted

voting using clearly defined procedures such as Robert's Rules.   Stuart
Lynn
has likewise argued that a private sector body, based on consensus and
consent, has been shown to be impractical.

This begs the question... is it time to replace the consensus process?  If
so, how do we avoid establishing a structural model that relegates certain
groups automatically to minority status?   ICANN seems to be enamoured with
voting blocks... Can we move to a one-man/one-vote mechanism, and will such
a
move be accompanied with full membership rights for all participants?

ICANN doesn't have the greatest track record with respect to honoring
consensus... can we expect it to honor an actual vote of the complete
membership?  More questions than answers at this point...

for Karl's treatise, see:
http://www.cavebear.com/rw/prescription-to-promote.pdf

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



<<< Chronological Index >>>    <<< Thread Index >>>