Why (and when) Consensus Matters (and doesn't)
Date: Thursday March 29 2001, @03:20AM
Topic: ICANN Staff and Structure

djohnson@wilmer.com writes "The very loose and unfortunate language in the names counsel meeting today about the nature of "consensus" obscures important issues about what a consensus is and how one documents it.

The Names Council and others have a tendency to talk as if the question is "consensus in the names council" -- measured by 2/3rds vote -- rather than consensus in the impacted community -- recognized by 2/3rds vote of NC but also documented by a report and a real, demonstrable state of the world."

There is also often an apparent lack of understanding of the difference between

  • the use of "consensus policy" for those things that are flowed down by means of voluntary contract (for those who have signed contracts with ICANN -- not yet, for example, including ccTLDs) and
  • the use of "consensus policy" for those questions that have to do with entering into new contracts that expand or change the scope of ICANN's consensus-policy-making reach.

In "Why Consensus Matters" Susan P. Crawford and I attempted to explain why

  1. ICANN is not and should not be a global democracy,
  2. no amount of "due process" or open and "fair" opportunity for comment (whether or not based on the US APA) can give ICANN full legitimacy,
  3. the DNSO and Board structure should be designed to assure that a voice for every impacted group can be heard (not to balance pre-ordained constituencies in some log-rolling balance),
  4. Names Council members who view themselves as "representatives" empowered to deliberate and legislate (rather than as a steering committee charged with facilitating and documenting dialogue) should have their new-found epaulettes torn off,
  5. the real issue about the new TLD contracts is that they give ICANN staff to refuse agreement to modifications in TLD business operations without any regard to whether or not ICANN has established a policy to the contrary, and
  6. it's slightly crazy to establish global competition policy and negotiate contracts regarding renewals of "delegations" of TLD registry roles in a committee that can't credibly claim to "represent" any fixed citizenry or membership or to exercise any sovereign enforcement power.

I have great hopes for ICANN. But we have to keep in mind both its limited mission and the very special nature of the private sector, contractual obligations that give it power. The absence of "consensus" is decentralized power -- the very stuff of which the net was built. Let's not allow the Names Council's institutional hubris lead us down the road of empowering ICANN to act as if it were a government! And let's not confuse the question whether ICANN should enter into any particular contract, with any particular amount (hopefully a great deal) of community input, with the question whether there is a sufficient showing of consensus such that those who have signed up for the ICANN regime should be bound by contract to follow policies with which they disagree. If we demand "consensus" for every Board decision, including opening of a new TLD, we'll have ceded control of the namespace to the most conservative factions. If we require the staff of ICANN to negotiate contracts based on community consensus, they'll never be able to negotiate any contracts. And if we allow the staff to impose contracts that require agreement by ICANN staff to any changes in registry/registrar operations, regardless of the existence of any true consensus policies, we will have created an unaccountable global bureaucracy.

So let's pay careful attention the context in which the idea of "consensus" is invoked -- and distinguish between those who use it to prevent action or innovation, those who use it to declare themselves the center of a self-aggrandizing policy-making clique, and those who use it, properly, to summarize the core contractual bargain entered into by participants in the collaborative ICANN standards-setting enterprise.

David Johnson

[To respond, or start a new comment thread, click the "Send Your Comment" button in the yellow box to the right.]

This discussion has been archived. No new comments can be posted.
Why (and when) Consensus Matters (and doesn't) | Log in/Create an Account | Top | 1 comments | Search Discussion
Click this button to post a comment to this story
The options below will change how the comments display
Check box to change your default comment view
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re: Why (and when) Consensus Matters (and doesn't)
by lextext on Thursday March 29 2001, @04:32AM (#460)
User #6 Info | http://www.lextext.com
The Names Council and others have a tendency to talk as if the question is "consensus in the names council" -- measured by 2/3rds vote -- rather than consensus in the impacted community -- recognized by 2/3rds vote of NC but also documented by a report and a real, demonstrable state of the world.

I have no doubt that some on the Names Council's believe "consensus" is a consensus in the council, not the community -- a view that I believe is shared by ICANN's outside counsel who drafted the bylaws specifically to make council votes a surrogate for documented community consensus.

But this particular vote was reasonably well documented, especially given the short deadlines. Eight separate reports were received from the General Assembly and each of the seven constituencies. (GA, NCDNHC, IPC, ISPC, Registrars, Registry, ccTLD, and B&C (attached to the NC statement). That's remarkable. In fact, a decent argument can be made that this is one of the best attempts by the NC to date to document the impact of a proposed ICANN action on the relevant community.

-- Bret Fausett
[ Reply to This | Parent ]

This article comes from ICANNWatch

The URL for this story is: