When Consensus Doesn't Matter, and What Does
Date: Monday July 15 2002, @08:16AM
Topic: ICANN Staff and Structure

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.

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
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: 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!

++Peter
[ 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:

http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00333.html

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:

http://www.dnso.org/clubpublic/nc-transfer/Arc00/msg00370.html
[ 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.




  • This article comes from ICANNWatch
    http://www.icannwatch.org/

    The URL for this story is:
    http://www.icannwatch.org/article.pl?sid=02/07/15/121624