What’s Wrong with ICANN -- and How to Fix It
By: David R. Johnson and Susan P. Crawford
ICANN has lost track of its core mission and failed to build the institutions and processes that would give it legitimacy and make it effective.Almost all of the mistakes ICANN has made along the way stem from a collective failure to understand that ICANN is not engaged in “internet governance” (democratic or otherwise) but, rather, a form of substantive standard-setting on specific topics -- based on a demonstration of widespread community support -- as to which registries, registrars and registrants have contractually agreed to be bound.
In order for newcomers to understand ICANN's intended mission, some background may be helpful.In the early days, when the internet was a U.S.-based research medium, Dr. Jon Postel (under contract with the U.S. government) maintained lists of assigned internet host numbers and published technical parameters for use on the internet.These functions collectively became known as the Internet Assigned Numbers Authority, or IANA.Every Internet computer has a unique internet protocol (IP) number, and IANA coordinated this system by allocating blocks of numerical addresses to regional IP registries.Under IANA, decisions about the domain name system were made by consensus.Memoranda called Requests for Comments (or RFCs) on engineering, technical, and other protocols were circulated to prompt discussion and generate consensus.In the mid-1980s, IANA announced an approach by which names would be associated with IP addresses, and the domain name system began.In 1991-92, the National Science Foundation took responsibility for coordinating and funding the management of the internet infrastructure, and at the end of 1992 NSF signed an agreement with Network Solutions, Inc. for providing domain name registration services in the important .com, .net and .org domains.
By 1998, although global commercial use of the internet was growing quickly, the domain name system was still subject to agreements with the U.S. government.The Clinton Administration, in an effort headed by Ira Magaziner, issued a June 1998 White Paper calling for the creation of a private-sector group to establish policy for the domain name system based on principles of stability, competition, private bottom-up coordination, and representation.By "bottom-up coordination," the White Paper meant a process that would, "as far as possible, reflect the bottom-up governance that has characterized development of the Internet to date" that would be coordinated by responsible private-sector action.
The White Paper states that it "applies only to management of Internet names and addresses and does not set out a system of Internet 'governance.'"In addition, a guiding principle of the policy was that "neither national governments acting as sovereigns nor intergovernmental organizations acting as representatives of governments should participate in management of Internet names and addresses," although global representativeness was an important priority.Finally, the White Paper stated clearly that it was not proposing a monolithic structure for internet governance:
We doubt that the Internet
should be governed by one plan or one body or even by a series
of plans and bodies.Rather, we
seek a stable process to address the narrow issues of
management and administration of Internet names and numbers on an ongoing
The four functions to be taken on by this new private-sector actor were:(1) to set policy for and direct the allocation of IP number blocks; (2) to oversee the operation of the Internet root server system; (3) to oversee policy for determining the circumstances under which new top level domains would be added to the root system; and (4) to coordinate the assignment of other Internet technical parameters as needed to maintain universal connectivity on the internet.In October 1998, ICANN was established by Dr. Postel and others, and in November of that year the Department of Commerce entered into a memorandum of understanding under which ICANN would assist in transferring domain name system management responsibilities to the private sector.
the most basic premise underlying ICANN’s establishment is that its policies
should be supported by a consensus that emerges from bottom-up processes
involving all impacted parties
-- the same process that had been used for the operation of the domain
name system since the beginning.ICANN
was not established by (and should not be run by) the U.S. government,
and -- most importantly -- does not have any power to enforce its rules
other than by means of contracts with registries and registrars.
existing contracts strictly limit the subject matters it may address and
require, as a condition to enforcement of any policy, that there be a demonstration
of consensus support.All registrars
and registries have agreed to comply only with ICANN policies that are
specifically set forth in the contracts
or that relate to "issues for which uniform or coordinated resolution is
reasonably necessary to facilitate interoperability, technical reliability
and/or stable operation of the Internet or domain-name system."(See,
e.g., Registrar Accreditation Agreement, Section II.D.1.b.i.)Such
policies must be the result of consensus 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 impacted,
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
id., Section I.B.1.)Only
then can the ICANN Board of Directors adopt the policy.And
if a registrar or registry disputes the presence of such a consensus, the
issue will be reviewed by an Independent Review Panel established under
basic premise is simple: if most of those impacted by a rule agree that
it will improve things, and intense opposition is absent or irrational
or limited to those who do not bear the costs of the policy in question,
then those who must implement the rule should agree, by contract, (as some
have) to do so.
ICANN's existing contracts strictly limit the subject matters it may address and require, as a condition to enforcement of any policy, that there be a demonstration of consensus support.All registrars and registries have agreed to comply only with ICANN policies that are specifically set forth in the contracts or that relate to "issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability and/or stable operation of the Internet or domain-name system."(See, e.g., Registrar Accreditation Agreement, Section II.D.1.b.i.)Such policies must be the result of consensus 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 impacted, 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.(See id., Section I.B.1.)Only then can the ICANN Board of Directors adopt the policy.And if a registrar or registry disputes the presence of such a consensus, the issue will be reviewed by an Independent Review Panel established under ICANN's bylaws.The basic premise is simple: if most of those impacted by a rule agree that it will improve things, and intense opposition is absent or irrational or limited to those who do not bear the costs of the policy in question, then those who must implement the rule should agree, by contract, (as some have) to do so.
The process of developing and documenting consensus among impacted parties differs fundamentally from the processes and forms of representative democracy.Proposals must be discussed among all impacted groups. Objections must be overcome, not overruled by vote.The dialogue that leads to consensus fosters a search for better solutions that almost all concerned can at least live with. Consensus is not a zero-sum seat claiming exercise -- it results from real conversation and joint problem solving. Consensus decisions are not based on geographic allocation of one-person-one-vote. They reflect the distribution of burdens and benefits created by any given policy. When consensus is not achieved, the result is allocation of decision-making authority to the decentralized, diverse networks that make up the internet. The very structure of ICANN is designed to centralize and decide policy questions only when there is widespread agreement -- not to centralize all decisions or to “cram down” policies on those who cannot marshal votes at higher levels of ICANN's hierarchy.ICANN has no delegated rulemaking power, except insofar as the “delegation” comes upward from those who have agreed to go along with its policies when they emerge from open processes that produce widespread support for such policies among impacted communities.
One critical mistake ICANN made was to allocate Domain Name Supporting Organization (DNSO) constituencies to specified interest groups, rather than allowing an open DNSO General Assembly membership to coalesce into alliances that could be granted participation in the election of a steering committee once they achieved a minimum number of members.This top-down gerrymandering has at times convinced the Names Council that it sits as a representative legislature, empowered to make rules, rather than as the facilitator of the consensus-generating process. It has also allowed intellectual property interests to achieve far greater influence than is warranted by the size of their stake in the resulting decisions.
Another key mistake has been to treat the Government Advisory Committee as a rule-making part of the ICANN structure. The original concept of the GAC was that it would facilitate an open and constructive dialogue between ICANN and governments -- so that consensus-based rules could co-evolve constructively with governmental laws. Under ICANN's bylaws, the GAC considers and provides nonbinding advice on ICANN activities that may relate to concerns of governments.(See ICANN Bylaws, Article VIII. Section 3(a).)If the GAC is treated as a source of virtually unchallengeable “recommendations," and if the conversations between the ICANN Board and the GAC take place in private, that co-evolution cannot occur and there will be no effective check on the power of governmental representatives (acting beyond both treaty and due process) to influence policies they might seek to impose on private sector participants whom they do not represent.ICANN has too often treated the GAC as providing the “last word” on matters it chooses to address and the Board has too rarely conversed with the GAC in public.
Ironically, the one area of ICANN’s decision-making as to which a call for “consensus” has slowed progress dramatically is the establishment of new TLDs. Yet the entry by ICANN into contracts with new registries is not the kind of question on which consensus is required. It is one thing for a registry to agree to follow the community’s wishes (assuming these are supported by a consensus among impacted parties, including registries).It is quite another thing for ICANN to open new territory by allowing a new registry to sign on to this contractual standard-setting regime.The concept of consensus limits ICANN’s power to impose rules on those with whom it already has a contract.It does not apply to the entry into new contracts that fit the basic mold.Assuming equitable treatment for all who sign up to the basic “consensus policy” regime, ICANN should be free to open many new competing TLDs -- even if existing registries object and even if intellectual property interests are not fully satisfied -- because the opening of a new TLD does not require any existing registry or registrar (or trademark owner) to accept and act on a policy with which it disagrees.Trademark interests have inappropriately used the idea of “consensus” to prevent competitive expansion of the name space, while treating the DNSO Names Council (and Board deliberations) as a seat-claiming, vote-counting exercise when it serves their purposes.
The process for electing ICANN Board members has also been the subject of gerrymandering (to assure geographic diversity even when this does not correspond with the distribution of impacts of ICANN’s policies) and, most unfortunately, has been structured to imply that the role of the ICANN Board is to deliberate and pass rules (like, at best, a democratic legislature) when that is not its role. Basic constitutional documents of ICANN, and the contracts through which it achieves its only enforcement powers, require the Board to facilitate and recognize community consensus, not debate and pass laws in a top-down fashion. The “representative” characteristics of the Board would be seen to matter less if the community recognized that it is not electing a government but merely choosing a steering committee, which must facilitate discussion and agreement in a far larger group. Failure by the Board actively and continuously to participate in consensus-generating community-wide discussions would be more widely condemned if the Board were properly understood to have no real power to act on its own in the absence of demonstrably widespread support for any policy it might seek to impose on registries and registrars.
Finally, as a result of this unfortunate focus on seat-claiming and gerrymandering and top-down decision-making, the entire community has neglected the process of actually generating consensus on standards that would address real, practical problems and that could be enforced under existing contracts. Very little has been done to discuss optimal registrar practices, to review and improve the operation of the Uniform Dispute Resolution Policy, or to address the problems of domain name hijacking and domain name security. The working groups of the DNSO have, unfortunately, done very little real work.This may be because many members of the working groups believe that all ICANN decisions are pre-planned, made behind closed doors, and imposed top-down -- in sharp distinction to the consensus-building processes ICANN was intended to facilitate.It may be that true consensus is hard to achieve on some topics -- but that is not surprising and does not prove that widespread support could not be generated on issues that fall within ICANN’s mandate.
The way to fix all of these problems is to recognize the true nature of and limitations on ICANN’s power.It is, again, not a government (and should not act as the agent of governments).It is a private party that contracts with registries and registrars.Those contracts obligate the registries and registrars to abide by consensus policies on carefully delimited subjects and to pass those policies down via contracts with registrants.If a policy is not demonstrably supported by a consensus among impacted parties, as ultimately found by an Independent Review Panel, registries and registrars need not comply. Thus, if ICANN’s Board (and the DNSO Names Council) continued to act as if they were representatives elected to a legislature, they would by doing so destroy their own power and legitimacy.If the “constituency” structures are gerrymandered to prevent emergence of true consensus policies, nothing enforceable can come out of ICANN’s processes.If working groups and task forces do not do the hard work of finding the “high ground” policy standards that most of the internet community will recognize as in their interests, and to which no seriously impacted minority will strenuously object, nothing of substance will get done.
Not that ICANN should try to get too much done.There are those who believe ICANN may be the appropriate vessel for intergovernmental management of content control and intellectual property piracy issues.Such efforts would be far beyond ICANN's scope -- ICANN is a private party, not the U.N., and it is limited by contract to considering a narrow range of questions.The absence of consensus with respect to a particular domain name management issue does not lead to inaction -- it merely allows decentralized action by the various registries and registrars and registrants and networks that all have a stake in making the internet work.In the absence of widespread agreement among impacted parties regarding how to resolve a particular issue, decentralized decision-making is the optimal solution. It allows internet users to find those networks and online spaces with which they are comfortable, and it leaves to local governments the use of force to compel compliance by their citizens with local laws. The ICANN Board does have some very limited emergency powers to deal with real threats to the core operations of the net -- again delegated to them, upward, by contracts with registries -- but there is no basis for them to claim any greater “sovereign” powers.
The net is a diverse place.Its various local “sovereigns” are not neatly, hierarchically, nested.There is no commerce clause, yet, to determine which problems ought to be dealt with centrally and which ought to be allocated to the “local” level.There may not even be agreement regarding what is of global concern and what is a local prerogative.In this context, the path to progress is dialogue, not zero-sum “representative” elections and top-down legislation. The White Paper that gave rise to ICANN sets forth the goal of establishing rules by bottom-up consensus.It did not delegate governmental powers or envision the creation of an internet government.The contracts that give ICANN its power clearly set forth the substantive and procedural limits on its ability to force a registry or registrar to comply with the policies it develops. All we have to do to fix ICANN is to remember its true nature -- and act accordingly.