The Big Question Facing ICANN’s Contractual Governance Regime

ICANN never ceases to pose fascinating issues in global governance. At ICANN 77, held in Washington DC June 12 – 16, a dramatic debate took place about ICANN’s proper scope of authority. Some interest groups (mainly Registries and GAC) want ICANN to be empowered to enforce compliance with Registry Voluntary Commitments (RVCs), formerly known as Public Interest Commitments (PICs). Civil society groups and some Internet businesses see in the proposed change a threat to freedom of expression on the internet and an attempt to undermine ICANN’s multistakeholder policy development process.

Underlying this debate are important questions about the relationship between private contracting, multistakeholder governance, and public policy.

The unavoidable background information

As is so often the case with ICANN, understanding this issue and the stakes requires a long explanation of how ICANN’s system of governance works. Here is the essential background information.

ICANN regulates the domain name system (DNS) by entering into contracts with domain name registries and registrars. The Internet community supported a private sector-based, contractual regime because its scope would be global, like the Internet’s domain name system itself, and because it would avoid control of internet infrastructure by governments, who tend toward authoritarian restrictions and/or jurisdictional fragmentation.

ICANN gets its regulatory power by acting as the gatekeeper of the DNS root. It awards registries top-level domain names only if they sign contracts with ICANN. The contracts commit registries to certain practices and policies (and the payment of fees to ICANN). The same goes for registrars. To be accredited by ICANN, registrars must sign a standard contract that commits them to certain things (and to payments of fees to ICANN).

What policies govern those contracts? The policy parameters of the contracts are supposed to come from the multistakeholder community, which is instantiated in bottom-up policy development organs such as the Generic Names Supporting Organization (GNSO) and various Advisory Committees (ACs). The reason for community-developed policy should be obvious: ICANN Inc., the root’s gatekeeper, is a monopoly. Entering into a “contract” with a private company in exclusive control of an essential input into a business is almost an oxymoron; it is not really a private, market-based agreement. So the terms of ICANN’s contracts cannot be dictated unilaterally by ICANN, Inc., they must be the product of a collectively binding, public process in which a broad set of Internet stakeholders are represented.

ICANN’s bylaws are another important constraint on its contracting power. Specifically, its Mission (Section 1.1) limits ICANN’s power much as the U.S. Bill of Rights or the European Charter of Fundamental Rights limits the power of the respective national governments. From ICANN’s inception, there have been strong, legitimate concerns that centralized control of DNS could be used to regulate content, services and applications on the Internet. What was the solution to this problem? Binding ICANN to a well-defined, narrow mission with enforceable boundaries. This was one of the main goals of the accountability reforms that led to the transition in October 2016. Malcolm Hutty expressed the prevailing view of the Cross-Community Working Group on Accountability (CCWG) in December 2015:

“CCWG wants to draw a bright line between the area where ICANN is supposed to develop policy (and enforce that policy through contracts) and the area where we believe ICANN should not have a policy. And we want this line to be enforceable by the IRP [independent review process].”  (December 16, 2015)

ICANN’s First Amendment

This demand to limit ICANN’s scope via the mission was successful. ICANN’s fundamental bylaws now contain the following language, which I like to call ICANN’s First Amendment:

Section 1.1

(a) The mission of the ICANN is to ensure the stable and secure operation of the Internet’s unique identifier systems as described in this Section…

(b) ICANN shall not act outside its mission

(c) ICANN shall not regulate (i.e. impose rules and restrictions on) services that use the internet’s unique identifiers or the content that such services provide, outside the express scope of Section 1.1 (a)

Section (c) in particular was added during the accountability reforms. The community wanted strong, explicit language barring ICANN awarding or withholding top-level domain names in ways intended to regulate content, services and applications that use the DNS.

During the transition, negotiations over these mission limitations became very heated, because everyone realized how much of a constraint the redefined mission would be. Like the First Amendment (or Article 19) it defined a broad swath of internet activity that should not be controlled or regulated by the administrator of DNS, even though it used or relied on the DNS. It would mean less power for ICANN, or for those who wanted to use ICANN to impose their policies on the internet. As a result of these debates, two exceptions were added to the new mission statement:

Section (d)(i) said:

“the foregoing prohibitions are not intended to limit ICANN’s authority or ability to adopt or implement policies or procedures that take into account the use of domain names as natural-language identifiers”

This was a recognition that domain name policies cannot avoid intersecting with trademarks or other kinds of legally protected names. It leaves the door open to policies that reduce or mitigate trademark-domain name conflicts – although these policies must be developed through the multistakeholder process.

Section (d)(ii) was another limitation on ICANN’s First Amendment. It was a narrowly defined grandfathering clause targeting GAC-imposed Public Interest Commitments (PICs) predating the reforms. During the 2011-2013 new TLD round – well before the accountability reforms – governments expressed policy concerns about what they called “sensitive strings.” Applicants for domain names wanted to appease GAC concerns so that GAC would not object to their applications. As a result, these new TLD applicants added “Public Interest Commitments” (PICs) to their contracts, promising that they would manage their names in ways that satisfied the GAC.

Section (d)(ii) was a recognition that existing GAC-oriented PICs would no longer be legal if the strict mission limitations of the new bylaws were enforced. It order to avoid confusion, and further wrangling over the transition, it grandfathered existing PICs. So the equilibrium solution was this: old PICs are safe, new ones must be subject to mission limitation tests.

The new push for PICs/RVCs

Enough background already! Why is this an issue now?

It all has to do with ICANN’s impending new round of TLD additions. Registries want to be given free rein to make “Registry Voluntary Commitments” (RVCs) – and have ICANN enforce them. Their desire for RVCs is a function of ICANN’s – and the GAC’s – gatekeeping role. In a crowded field of new TLD applicants, prospective registries want to appease any objections from governments, intellectual property holders, or anyone else who might want to oppose their applications. So they have come up with the idea of RVCs, which allows them to promise to do whatever the GAC or any other objector might want. If the government of France is concerned about geographical indicators in a .WINE domain (this is just an example), the applicant making an RVC might promise that the .WINE TLD will strictly enforce French notions of name protections, even though ICANN has not adopted such a policy and they are not hard-coded in international law. This will make the French government happy and preclude any objection.

In principle, RVCs could be about anything. A registry concerned about the proverbial “woke mob” could promise never to issue domains to anyone whose opinions are not in accord with the principles of Diversity, Equity and Inclusion. A registry hoping to avoid objections from religious conservatives could promise to banish all blasphemy. A registry hoping to enter the China market could tack on a commitment never to allow any websites that mention the June 4 Tiananmen Square incident, or never allow any reference to the Hong Kong protests. A registry seeking to avoid objections from intellectual property lobby could promise to give copyright owners special powers to monitor or take down domains.

A free market in DNS services would certainly allow any registry to institute its own policies of this type. Sure, let there be “woke” TLDs, conservative TLDs, communist TLDs, trademark maximalist TLDs, whatever.

What’s perverse and disturbing about the new push for RVCs, however, is that they are not talking about private policies, encoded in the registry’s own terms of service and self-enforced. They want ICANN to enforce them! And ICANN seems to want to enforce them. Why? Because RVCs are being used as competitive advantage in the contention for new TLDs. They are becoming a condition of market entry. And if ICANN is using them as a condition of the award, the argument is, if you promise to do this, and were given a TLD on that basis, then ICANN has to enforce that commitment.

The problem is, the RVC idea is making ICANN into an enforcer of policies intended to regulate content and services on the Internet, and this is a direct and obvious violation of its limited mission. ICANN cannot take on the role of enforcing such RVCs without violating a fundamental bylaw.

Incredibly, some people are so committed to this bad idea that they are talking about modifying a fundamental bylaw. They are literally hoping to push for a constitutional amendment that abolishes ICANN’s first amendment.

Bypassing multistakeholder policy making

Aside from crushing ICANN’s commitment to not using the DNS to regulate content and services, enforcing RVCs would have a terrible knock-on effect on the multistakeholder policy process. Because once ICANN starts enforcing contractual commitments that are made unilaterally by registries in a bargaining process designed to get them into the DNS root, the multistakeholder process is no longer in control of the basic policy parameters of registries and registrars. Governing policy emerges as a byproduct of bilateral bargains between GAC, ICANN Inc., and a registry during the application process. The consensus-based, collective, uniform rules and constraints that are supposed to govern all registries are no longer set by the GNSO in a bottom up process, where all stakeholder groups are represented. It is a private negotiation between the applicant and the ICANN board.

It would work like this: the ICANN board says, “hmmm, there were a bunch of people objecting to your application, or lobbying against it, but we see that all those objectors have disappeared now that you have added a RVC that commits you to do what potential objectors want you to do. So now we will approve your application.” Unless RVCs are subject to mission limitation tests, this is exactly what will happen. And ICANN will become the Internet police committed to enforcing these things. Such a process would be a disaster for keeping ICANN in mission, and protecting Internet freedom.

The fundamental problem

The RVC problem is really a derivative of a more fundamental flaw in ICANN’s new TLD processes. Instead of defining clear, simple rules for nondiscriminatory awards of new TLDs, ICANN has created a bureaucratic morass of regulations and veto powers. The fate of a TLD application is not governed by any predictable rules. It is all discretionary, and the GAC in particular wants to be in a position to veto or modify applications and names that it doesn’t like.

Fortunately, Registry commitments that are designed to regulate content and services and make ICANN their enforcer are clearly violations of ICANN’s fundamental bylaws. The plot to bypass bottom up policy making process cannot succeed unless those bylaws are modified, and the modification would be so fundamental and the social gain so miniscule that it is hard to imagine it ever happening.

Never underestimate the ability of ICANN’s board, the GAC and DNS industry short-term self-interest to screw things up, however. Keep an eye on this process, and we hope this blog post helped you understand the stakes.