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)

    The Big Picture Legitimacy and Effectiveness Through Consensus
    posted by tbyfield on Monday June 24 2002, @08:54PM

    susan writes "Legitimacy and Effectiveness Through Consensus By David R. Johnson, Susan P. Crawford and Becky Burr"

    This week's Evolution and Reform Committee "blueprint" document identifies one perceived cause of ICANN's dysfunctionality: stakeholders in the ICANN process lack incentives to come to the policy development table prepared to make a deal. As a consequence, important policy decisions are now either not made or are made by staff, rather than being based on a "true consensus" (ERC’s words). The ERC blueprint proposes to solve this problem by eliminating the consensus requirement altogether – giving the Board ultimate power to make decisions it considers to be in the global “public interest." Even if a true consensus existed, the ERC blueprint would give the Board the power to override or modify it with a two-thirds vote.

    For a number of reasons, both practical and profound, we think that eliminating the consensus requirement is the wrong answer to solving ICANN’s legitimacy problem. As a practical matter, ICANN has entered into binding legal agreements with registrars and registries that give ICANN enforcement power only when a documented consensus exists (and when an Independent Review Panel is available to review the Board’s determinations that this is so). The ERC blueprint assumes renegotiation of key provisions of contracts that strictly limit the subject matters ICANN may address and that require, as a condition to enforcement of any policy, that there be a demonstration of consensus support. It is not clear to us why registries and registrars (much less ccTLDs) would agree to eliminate these protections. Nor are we aware of any grant of authority from any source that would permit ICANN to modify these contracts unilaterally. On a more profound level, ICANN's authority and legitimacy is deeply rooted in its commitment to bottom-up consensus policy development. If ICANN makes policy based on the agreements pursuant to which registries and registrars promise to go along with the community consensus, it can plausibly answer accusations that it has usurped governmental powers. If ICANN simply claims the right to make rules that no one has agreed to obey, it will sooner or later face fatal challenges to its authority. Those same challenges will arise if ICANN uses its authority to recommend changes in the root to force registries and registrars to agree to excessively regulatory contracts.

    The ERC blueprint suggests that the consensus process is unworkable because there will be holdouts who rationally, but for selfish reasons, will refuse to support any proposals that might prevent them from conducting their business as they see fit, even where that course of action imposes serious costs on the global internet community. We disagree. Properly understood, the consensus process would allow the Board to ignore dissent that is based solely on a desire to continue to engage in unjustifiable wrongdoing.

    ICANN doesn't always have to operate by consensus. When the Board makes decisions about how many staff to pay for, for example, or even how many TLDs to open up, it is and should be able to do that without documented consensus. (Decisions regarding when to allow new actors to enter the marketplace should always be made in a manner that increases competition, absent a clear showing of serious harm -- so as to fulfill ICANN’s obligation to foster competition -- but that’s a different question.) Indeed, the Board can already adopt a temporary specification or policy mandating (or prohibiting) particular action by a registry or registrar 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..."). ICANN is required to document the existence of consensus only when it is imposing a non-emergency mandatory policy on a registry or registrar (i.e., a policy that requires a registry or registrar to take some action of the prohibits a registry or registrar from taking an action).

    We think the Board should be more active in pushing the consensus policy process along. It could do so by: · calling for work on a particular consensus policy, · indicating its preliminary beliefs about which parties would be affected by the policy, · appointing a facilitator who would be personally responsible for creating the written consensus policy report (and could be trusted to do an unbiased job), and · setting strict deadlines for submission of the report to the relevant Supporting Organization.

    The SO should have a set period of time to consider the report and pass on it, and the Board itself should have a set period to consider the proposed policy.

    Leadership on the part of the Board and staff can make a big difference. At a minimum, establishing clear processes can force those who oppose a proposed policy to clearly articulate their objections. More generally, the Board and staff can more clearly express their own views concerning proposed solutions. So long as the ultimate decision by the Board concerns whether a “true consensus” has been generated, there is no requirement for Board or staff neutrality about the outcome. Any claim to neutrality risks disillusionment and cynicism once it becomes clear that the Board has a view on the merits. It would be much better for ICANN’s Board to acknowledge that it cannot impose rules absent a documented consensus – and also to take a proactive role in attempting to find and support constructive solutions to real problems.

    Such leadership can force dissenting parties to articulate the reasons why they oppose a proposed policy. And, notably, when presented with a report that documents widely-held support for a proposed rule, the Board may consider (among other things) whether the dissenters’ opposition to the consensus policy is is based solely on a desire to continue to engage in unjustifiable wrongdoing. The Board should start by asking: · Is the party raising the question substantially impacted? · Is its opposition rational or reasoned?

    If either of the answers is "no," the Board may adopt the policy as supported by consensus despite the dissenter’s opposition. Even if the answers to both of those initial questions are "yes," the Board may go on to find that rational/reasoned opposition of an impacted party may be disregarded to the extent that: · the opposition is based on a desire to continue or commence an activity o that imposes substantial unjustified costs on third parties or o that will disrupt an orderly, competitive marketplace

    This "unjustifiable opposition" test is implicit in the consensus standard. To date, too many have assumed that any refusal to agree to a new policy could prevent ICANN action. To the contrary, just as ICANN can reasonably override dissent from those who are not impacted by its policies and from those who won’t make reasoned arguments, it may (under the current contracts, we submit) reasonably determine to disregard opposition from parties who seek unjustifiably to impose harm on others. What it may not do is to set itself up as the sole determiner of what is in the public interest.

    We want to stress the importance of the use of the word "unjustifiable" rather than "unjustified." The Board may not itself perform a balancing test to determine where in its view the "public interest" lies – that is a level of power not ceded to it by the contracts (or anything else). But, when it determines whether or not a true consensus exists, the Board must necessarily make a judgment concerning what kinds of dissent must be respected and what may be overridden. If a dissenter is only claiming the right to engage in what the community as a whole considers wrongdoing, or only seeking to persist in activities that disrupt an orderly, competitive marketplace, then that opposition is clearly entitlted to little respect. The test should be a high one – we disregard objections by wrongdoers to the rules that curb their conduct, but we also are careful to define “wrongdoing” narrowly and to apply any such rules to everyone on an equitable basis.

    The existing contracts require the Independent Review Panel to exist in order for registries and registrars to be bound by consensus policies. We think a serious problem with the ERC blueprint is that it eliminates the Independent Review process. ICANN has proposed to resolve disputes through arbitration, which is fine as far as it goes, and is certainly an important backstop to this process. But we see a real value in creating the Independent Review Panel as an ongoing, persistent group that considers over time the question whether the Board has followed the rules for adopting a consensus policy.

    The value of a persistent IRP rather than rotating panels of generalist arbitrators is that an ongoing, independent group will create a set of precedents on these difficult issues. The IRP (if it is a stable body with knowledge of the community) will be a good place to consider whether the Board has followed the rules for finding consensus -- by, in part, ignoring unjustifiable opposition to a particular policy. Some have expressed concern that the IRP will be another Board, but we don't think that's right. The IRP will be a neutral judicial branch of ICANN, considering only the questions that are brought before it (and if we all do our job right during the consensus development process, there won't be many questions). Like all the other parts of the process, the IRP should be subject to strict time limits within which to make its decisions.

    If the IRP determines that the Board adhered to the criteria for finding consensus in the face of dissent, the dissenter will then be required to comply with this policy unless it has obtained a temporary stay or injunctive relief from an arbitration panel or a court -- or until an arbitrator renders a final decision based on the documented materials prepared in connection with the consensus process.

    We think the consensus process, properly understood and supported by a proactive Board and staff, can work. Indeed, the consensus process (along with the contracts that embody it) is the fundamental source of ICANN’s legitimacy. Without it, no matter how open, transparent and fair the Board's processes, its authority to impose rules on others will always be subject to attack. No amount of "process" can authorize ICANN to make its rules stick. In contrast, contracts that registries and registrars have freely entered into obligate them to go along with consensus policies. Let's fix the consensus process and make those contracts the basis for supporting a legitimized ICANN. ++++

    Consensus process steps

    1. Not everything needs to be done through the consensus process · Board can always act in an emergency to create a temporary policy o if adopted by a two-thirds vote o if Board reasonably determines that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the operational stabilityof Registry Services, the DNS, or the Internet, and the proposed specification or policy is as narrowly tailored as feasible to achieve those objectives. o temporary policies can last for as long as a year · As long as it is not mandating or prohibiting particular acts of parties under contract with ICANN, the Board can act without a consensus policy in place. Examples: o hiring staff o deciding how many new TLDs to open up in a given year 2. Board calls for work on a particular consensus policy (either on its own or when requested to do so) · Indicates its preliminary beliefs about which parties would be affected by the policy; · Chooses SO that will be responsible for reviewing report; · Appoints a facilitator who is personally responsible for creating the written consensus policy report (and can be trusted to do an unbiased job); · Sets strict deadlines for submission of a report to the relevant SO (e.g., 60 days).

    3. Report drafter/facilitator goes to work · Interviews/meets with affected parties · Gathers position papers · Facilitates consensus to the extent possible · Prepares report documenting o the extent of agreement among affected groups o the outreach process used to obtain the views of groups likely to be affected, and o the nature and intensity of reasoned support and opposition to the proposed policy · Sends report to relevant SO within time limit

    4. SO receives the report · Has (e.g.) 30 days to review the report · Council of SO must vote on or before 30th day whether or not to recommend that the policy be established · Sends report (as revised in collaboration with facilitator) promptly to Board, including dissenting views

    5. Board receives the report · Hears presentation from faciliator/drafter · Has (e.g.) 30 days to review the report · Must vote on or before 30th day whether or not to establish policy · May override dissents if unreasoned and/or from unaffected groups

    6. Questions for Board will be: · Is party raising the question substantially impacted? · Is opposition rational or reasoned? If one of the answers is "no," Board may adopt consensus policy. Even if the answers to both these questions are "yes," Board may go on to find that rational/reasoned opposition of an impacted party may be disregarded to the extent that: · the opposition is based on a desire to continue or commence an activity o that imposes substantial unjustified costs on third parties or o that will disrupt an orderly, competitive marketplace · this is the "unjustifiable opposition" test · Board must decide within 30 days.

    7. If dissenter does not agree that consensus was adequately documented (disputes the presence of a consensus), it may request IRP review within 15 days of decision by the Board.

    8. Question for IRP will be: did Board answer the questions presented correctly?

    9. If IRP sustains Board's determination that the specification or policy is based on a consensus among Internet stakeholders represented in the ICANN process (because opposition is coming from a party that isn't substantially affected by the policy, or opposition is irrational/unreasonable; or, if these two first tests are met, Board has gone on to find that dissenter's opposition is unjustifiable using the test described above), then dissenter must implement such specification or policy unless it promptly seeks and obtains a stay or injunctive relief from a court or arbitrator. Time: 60 days (report creation) plus 30 days (SO consideration) plus 30 days (Board consideration) plus 15 days (time to appeal to IRP) plus 30 days (IRP prepares opinion): 165 days (5-6 months) (does not include arbitrator-court action). Note 1. David Johnson is the founder of Graphical Groupware. Susan Crawford and Becky Burr are partners with Wilmer, Cutler & Pickering. This article was written in our personal capacities, and not on behalf of any client of Wilmer, Cutler & Pickering.

      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.
    Legitimacy and Effectiveness Through Consensus | Log in/Create an Account | Top | 2 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.
  • 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