ICANNWatch
 
  Inside ICANNWatch  
Submit Story
Home
Lost Password
Preferences
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
ICANNWatch FAQ
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)


     
    ICANN Staff and Structure Why (and when) Consensus Matters (and doesn't)
    posted by michael on Thursday March 29 2001, @03:20AM

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

     
      ICANNWatch Login  
    Nickname:

    Password:

    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

     
      Related Links  
  • ICANNWatch.org
  • "Why Consensus Matters"
  •  
    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
    Threshold:
    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 ]


    Search ICANNWatch.org:


    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com