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

Our Mission
ICANN for Beginners
About Us
How To Use This Site
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 When Consensus Doesn't Matter, and What Does
    posted by jon on Monday July 15 2002, @08:16AM

    By J. Beckwith Burr, David R. Johnson and Susan P. Crawford

    Emotions are running high about a number of decisions for which some people believe the ICANN Board needs documented consensus support before it can act. We think it is important to understand exactly what the role of consensus is in the ICANN context -- and when consensus is not required. It's also important to understand that there are other constraints operating on the Board when it acts independently of the consensus regime.

    "Consensus" is a concept that has a particular, legal meaning and applies only in particular circumstances in the ICANN context. The ERC Blueprint relates to several different kinds of Board decisionmaking together, sometimes mixing them up. But only one kind of Board action requires consensus. Let's walk through the various actions the Board can take, and the corresponding, and differing, constraints on its actions.

    1. The Board can act administratively without consensus. When the Board needs to hire staff, or allocate tasks, or create a committee of experts, or rent new space, it can do so without the consensus of anyone. What matters in this administrative sphere is that the Board adheres to its fiduciary duty to run ICANN efficiently and to serve the Internet community. Each member of the Board has an obligation to act in the best interest of the corporation and to serve ICANN's nonprofit objectives.

    2. The Board can amend its contracts with registries, registrars, and others (or approve actions under these contracts) without consensus. When, for one reason or another, a contract is amended by the mutual agreement of ICANN and the other contracting party, only the Board can authorize such amendments on behalf of ICANN. The Board can authorize amendments to these contracts (amendments that are voluntary on both sides), or give approvals within parameters and for purposes set forth in the contracts, without consensus. Of course, the Board can ask anyone it likes for advice on the subject of contractual amendments and approvals. This is what has happened in the .org context: the ICANN Board has asked the DNSO for its views on what kind of entity should be the signatory of the next .org registry agreement. It will be the Board's decision, however (and not the DNSO's), which entity to pick. Similarly, this is what happens when ICANN amends the terms of its Cooperative Research and Development Agreement with the U.S. National Institute of Standards and Technology and the National Telecommunications and Information Administration -- the Board authorizes the amendment, and does not need community consensus to do so.

    Consensus isn't needed in these cases because Board actions with respect to contractual amendments and approvals are constrained in several ways. On the one hand, a decision by the Board to amend a contract is meaningless unless the other party agrees. On the other hand, a decision by the Board to withhold agreement to a particular contractual amendment, or approval pursuant to a contractual provision requiring such approval, would be constrained by:

    • the terms of the contract itself, which could require ICANN (for example)
      • not to withhold its consent to the amendment or approval "unreasonably"
      • to promote and encourage robust competition
      • to not single out registry operators for disparate treatment
      • (in the case of approvals) to exercise the approval for the purposes the contract was agreed upon to serve.
    • the terms of ICANN's Memorandum of Understanding with the U.S. Department of Commerce, requiring ICANN (for example)
      • to act in a manner that will permit market mechanisms to support competition
      • to ensure sufficient appeal procedures
      • to not apply standards inequitably
    These, among others, are the obligations that the Board must keep in mind in amending its contracts or granting contractually required approvals. The Board can and should, of course, seek advice from the community. But the Board doesn't need documented consensus in this context.

    3. The Board can act in an emergency without consensus. Importantly, the Board can always adopt a temporary specification or policy mandating (or prohibiting) particular action by registries or registrars in an emergency (when "the Board reasonably determines that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the operational stability of Registry Services, the DNS or the Internet..."). Even in the absence of documented consensus, such temporary policies can be treated as consensus policies for up to a year, while the real consensus process runs its course. So ICANN can always act if it needs to without waiting for a report to be created.

    4. But the Board cannot, in the absence of an emergency, adopt a mandatory policy that is binding on a registry or registrar without documented consensus. Under the current contracts ICANN has signed, when ICANN seeks to impose a policy on a registry or registrar with which it already has a contract, such policies must be the result of consensus. This is when consensus does matter. And there's a very specific process set forth in those contracts: a consensus must be demonstrated by a written report documenting (a) the extent of agreement among impacted groups, (b) the outreach process used to obtain the views of groups likely to be affected, and (c) the nature and intensity of reasoned support and opposition to the proposed policy -- and must be recommended by at least a two-thirds vote of the council of the ICANN Supporting Organization addressing the issue. In other words, when ICANN adopts policies that registries (or registrars) must follow, it can do so only when a documented consensus exists (and when an Independent Review Panel is available to review the Board's determination that this is so).

    The premise of the consensus policy regime is simple: if most of those affected by a rule agree that it will improve things, and intense opposition is absent, irrational, limited to those who do not bear the costs of the policy in question, or limited to those whose objection is based solely on a desire to continue to engage in unjustifiable wrongdoing, then those who must implement the rule have agreed, by contract, to do so. The concept of consensus limits ICANN's power to impose globally applicable, mandatory rules on entities with which it has a contract.

    Some cite the difficulty of reaching consensus as a justification for "reform" proposals that would eliminate the need for documented consensus as a precondition for imposing binding rules. But consensus is required on only a narrow range of matters, and the misapplication of a limited consensus requirement to matters where the need for consensus clearly does not apply should not be allowed to distort the important ongoing discussions about ICANN's powers and sources of legitimacy. Harold Feld has asserted that the Board has undermined the SO process and structure by making clear that the Board will make all final decisions, regardless of "compromises" worked out among constituencies. Whether or not that observation is correct, it should not be understood to imply that the current contracts permit the Board to act on its own, by any plurality of votes, to impose binding rules on gTLD registries and registrars in the absence of "consensus" as it is defined in the contracts. Nor do we think that could be the case in the post-reform future without fundamentally undermining ICANN's authority, which springs from the freely given consent of those who are to be bound by its policies. Correspondingly, the Board's ability to act without consensus on a wide range of matters that do not involve imposing binding rules on contracting parties needs to be clearly acknowledged -- as does the appropriateness of the Board's request for advice when making such discretionary decisions.

    One of the reasons "consensus" has developed such a bad reputation is that it can be and has been incorrectly invoked to slow progress on a number of fronts. We clearly need another word for those situations in which ICANN's Board is seeking advice regarding actions it can take on its own (subject only to ICANN's contractual and antitrust duties). In the meantime, however, let's all be clear about when it applies, and when it doesn't. And let's move forward with the reform of ICANN with this distinction clearly in mind.

      ICANNWatch Login  


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

    This discussion has been archived. No new comments can be posted.
    When Consensus Doesn't Matter, and What Does | Log in/Create an Account | Top | 11 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: When Consensus Doesn't Matter, and What Does
    by PeterBarron (pebarron@hotmail.com) on Monday July 15 2002, @09:05AM (#7867)
    User #3240 Info | http://www.icannwatch.org/
    What a fantastic essay! It conclusively demonstrates that the number of angels that can dance on the head of a pin is indeed 14! ICANN should call this consensus and move forward immediately!

    [ Reply to This | Parent ]
    • 1 reply beneath your current threshold.
    Re: When Consensus Doesn't Matter, and What Does
    by GeorgeK on Tuesday July 16 2002, @10:16AM (#7904)
    User #3191 Info | http://www.kirikos.com/
    J. Beckwith Burr is an attorney for SnapNames apparently, see:


    so that kind of document is very predictable coming from them, as the WLS debate reaches its crescendo.

    A SnapNames "partner" bucked from the pack, and came out against WLS today. See:

    [ Reply to This | Parent ]
    Re: When Consensus Doesn't Matter, and What Does
    by fnord (groy2kNO@SPAMyahoo.com) on Monday July 15 2002, @11:01AM (#7876)
    User #2810 Info
    I read the submission as an explanation/excuse for why many of those occurred. The problem is that those decisions were billed as consensus based at the time, and it was the BoD and Staff throwing the term around. -g
    [ Reply to This | Parent ]
    Re: Equally Important
    by fnord (groy2kNO@SPAMyahoo.com) on Monday July 15 2002, @03:49PM (#7881)
    User #2810 Info
    Much as Afilias' obvious corruption is offtopic regarding a proper definition of consensus, it shows exactly how that undefined consensus was spun on the public by the ICANN BoD, Staff, and insiders. There was supposed consensus for a limited number of new TLDs (in fact there was no such thing). From that artificial scarcity insiders were able to profit. As I say, rename ICANN to WorldCon. This stinks to high heaven. -g
    [ Reply to This | Parent ]
  • 2 replies beneath your current threshold.

  • 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