"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:
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.
- 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
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.