Draft

June 16, 2001

David R. Johnson

Susan P. Crawford

Restructuring ICANN

Summary

It is time to restructure ICANN. Given the currently unrepresentative Board, the problems experienced by key groups (such as ccTLDs and individual domain name holders) in being heard, the failure of the current DNSO to create consensus policies, and the tendency of ICANN management (frustrated with ICANN's dysfunctional structure) to undertake the creation of policy out of whole cloth, ICANN clearly needs reshaping. No restructuring will work, however, that does not bear a coherent relationship to ICANN's key goal: the creation of consensus policies that become binding on registries, registrars, and registrants through the contracts that give ICANN its power.

This paper proposes that:

• each key group within ICANN (each group that is affected by ICANN policies, has a direct or indirect contractual relationship with ICANN, and would have standing to object to a proposed consensus policy) be allocated a Supporting Organization
• each such Supporting Organization include both a forum for members and a forum for all stakeholders (including members and all others who might be affected by the actions of such members)
• each such Supporting Organization elect two directors to the Board (one selected by the members and one selected by the open forum)
• a cross-Supporting Organization General Assembly be created from which consensus policies would have to originate, and
• a distinct "At Large" membership be created, to represent all individuals whose interests might not fit within the open fora of particular Supporting Organizations, that elects two directors (and that proposes policies to the Board for consideration by the Supporting Organizations) .

These reforms may appear radical. But absent significant change, ICANN will continue to suffer from charges of gerrymandering and illegitimate top-down control of all decisions. If these changes are made, ICANN will be able to move forward with the creation of consensus policies that more accurately reflect the views of affected parties.

Background

ICANN's structure is already under review in many venues.

• The At Large Study Commission has been tasked with rethinking At Large membership and methods of selecting the Board of Directors (and, more generally, with considering all questions relating to ICANN's organizational structure).

• ccTLDs have called for their own Supporting Organization and the right to select some Board members.
• The role of the General Assembly within the DNSO is also being reviewed by various groups.
• The introduction of new TLDs promises to change existing power alignments.
• The Names Council and Board will be considering proposals to create an Individual Domain Name Holders Constituency of the DNSO.
• Many have noted that the DNSO has not proposed any true consensus policies since its establishment -- and many doubt its ability to do so.
• Many participants contend that the Board is not adequately representative of groups that need to be involved in recognizing consensus policies pertaining to domain names. Only three members of the Board speak for the entire DNSO.

No reorganization will make sense unless it is based on clear relevant goals and a sound understanding of ICANN's organizational powers and responsibilities.

The basic premise underlying ICANN’s establishment is that its policies should be supported by consensus that emerges from bottom-up processes involving all affected parties. ICANN does not have any power to enforce its rules other than by means of contracts with registries and registrars -- contracts that require registries and registrars to follow consensus policies. Thus, the major purpose of the ICANN structure is to develop consensus policies that can be enforced by contract.

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 documented consensus support. All registrars and registries have agreed to comply 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." 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. Only then can the ICANN Board of Directors adopt the policy. 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 impact of the policy in question, then all who must implement the rule should agree to do so.

Accordingly, the goal that should inform the re-creation of ICANN's structure is facilitation of the development of consensus policies (where these apply to appropriately limited subjects and where there is general agreement on the need for central coordination) and avoidance of false claims of consensus.

Some approaches to re-creation of ICANN's structure clearly would be bad ideas:

• "Balancing" of a Board based on power relationships -- or to achieve some other pre-determined relationship among factions -- won't work.
• Any balance would shift over time or become obsolete.
• Top-down decisions by a "balanced" Board could still be challenged as not reflecting a consensus among affected parties.
• Election of a Board by fee-paying parties, in proportion to fees paid, won't work.
• Payment of fees does not always correlate with identification of those affected by ICANN policies.
• Any such system would lead to financial capture by those most able to pay ICANN's fees.
• Attempts to create a global democracy (or keep half the Board elected by an "At Large" membership) won't work.
• No matter how open and transparent the process used to create the ICANN Board and the ICANN At Large Membership itself, these bodies cannot credibly claim to be "representative" of the body of those affected by and/or required to follow ICANN's rules. Indeed, the set of affected parties will vary from rule to rule, and the nature and size of the impacted group will evolve as participation in the internet develops. No one can realistically expect everyone with some stake in the domain name system to join ICANN and participate actively. Nor is there any good reason to believe that the tiny percentage of potential stakeholders who do join and vote will be "representative" of those who are affected.
• Decisions by a fully "democratic" Board (even if such a Board could be created) would not be enforceable via contracts unless they were also supported by a documented consensus among affected parties.
• The more "democratically representative" the Board feels itself to be, the more it may be tempted to make policy in a top-down fashion -- and the more likely its decisions will be successfully challenged as not comporting with ICANN's contractual obligation to develop and follow consensus policies.
• Creation of a ccTLD Supporting Organization that does not include other relevant stakeholders (and without making other structural changes) won't work.
• ccTLDs are no more "different" from other groups in the DNSO than registries are different from registrars, or domain name holders are different from ISPs. If ccTLDs have a separate SO, other groups should rightfully have their own SO as well.
• Each SO needs to allow relevant stakeholders who are not necessarily "members" of the SO to engage in the negotiation and compromise needed to find consensus on matters that require centralized coordination. (Indeed, ICANN's current bylaws require new SOs to include all impacted stakeholders.)
• Creation of a "business" SO that does not communicate with individuals, an "individuals" SO that does not communicate with business, or a "technology" SO that talks to no one, won't work.
• Real progress on any consensus policy won't happen unless all interested parties are intensively involved in discussion.
• Users and businesses (and technologists) need to understand all relevant views involved in the provision of domain name services, and assess together what policies are feasible and necessary. This discussion may at times be painful, but collisions among these groups need to occur on a continuous basis in order for work to be accomplished.

ICANN's structure should facilitate both (1) cooperation among similarly situated parties to develop harmonized views, and (2) dialogue among dissimilarly situated parties engaging in discussion, negotiation, and compromise.

Proposal

ICANN's mission (the creation of consensus policies) and its institutional needs (recognition of similar and dissimilar groupings, and facilitation of discussion and compromise among such groups) both point to the creation of multiple Supporting Organizations as a key element of any restructuring of ICANN.

A separate SO should be allocated to each group (i) that has a direct or indirect contractual relationship with ICANN, (ii) that is likely to be substantially differently affected by ICANN policies, and (iii) whose opposition to a proposed policy (if it can show substantial impact) would likely defeat a claim of consensus. These groups appear to be:

1. gTLD registries

2. ccTLD registries (on the condition they enter a contract with ICANN obligating them to follow consensus policies applicable to them)

3. sTLD (sponsored) registries

4. ICANN-accredited registrars

5. ISPs (who point their nameservers at the authoritative root zone file for which ICANN establishes policies)

6. Domain name registrants (who are bound by registration contracts)

• Business (generally)
• Trademark holders
• Non-commercial organizations
• Individual domain name holders

7. Protocol Supporting Organization

8. Address Supporting Organization -- IP Address Registries (and address block holders)

The current ICANN bylaws describe three SOs (DNSO, PSO, and ASO), and require any new SO to reflect the full diversity of relevant stakeholders. Although the bylaws must be revised to allow this proposed multiple-SO structure, the general need to preserve a voice for all stakeholders, and provide opportunities for conflicting voices to interact to seek consensus, remains. Therefore, within each SO, there should be a place for qualified "members" (a Council) and an open forum designed to allow participation by all stakeholders who are not members of the SO but who might be impacted by the actions of such members.

In many contexts, the creation of "member" and "stakeholder" fora within a particular SO would lead to opportunities for participation by a "producer" side and a "consumer" side. In the case of the proposed Domain Name Registrant SO, where no real "producer" vs. "consumer" side exists, it will be appropriate to divide the SO into subconstituencies reflecting commercial and noncommercial interests. But each new SO will be less complicated than the current, dysfunctional, DNSO.

Further, each SO should elect two directors -- one selected by the "council" of members and one selected by the open forum. In the Domain Name Registrant SO, one Board member could be elected by commercial interests and one by noncommercial interests. (Note that the mere ability to elect a Board member, or to speak as an organized SO, does not necessarily give veto power to any particular group. In order to successfully oppose a consensus policy, an SO would have to demonstrate that it is substantially affected by the proposed policy.)

Additionally, a cross-SO General Assembly should be created to facilitate dialogue and consensus documentation. It would meet to discuss issues that cut across SOs and to develop consensus policies. Support from all interested (and affected) SOs would be necessary for submission of a consensus policy to the ICANN Board for approval, and all proposed consensus policies would need to originate from this cross-SO General Assembly. The cross-SO GA should function as an open forum of all SO participants, to avoid filtering of important dissenting views by "elected" representatives. But it could also receive formal statements of support or opposition to proposed policies that are put forward by particular SOs. The existence of documented consensus in support of any given policy would be tested by the (now more representative and diverse) Board and (if challenged) by the Independent Review Panel.

Finally, a distinct "At Large" membership, open to any individual from any SO as well as any individual who is not active in any SO, should also select two directors. This reorganized At Large group must have the ability to propose policies directly to the Board for consideration by the appropriate SOs. Such an open forum, which will both elect Board members and propose policies, will provide a channel for the public voice to be heard, a place for meaningful work to be done by individuals, and a safety valve for any groups that believe they are substantially affected by ICANN policies but are not adequately represented in the SO structure. Because it will be electing only two Board members (instead of half the Board), the pressure of deciding how the At Large is populated will be relieved. Such an At Large will function at times as a meta-General Assembly, to which both SO members (who happen to be individuals) and non-SO members will bring their views.

At the moment, the GA of the DNSO has no power directly to elect members of the Board and is perennially frustrated by the machinations of the DNSO Names Council, but provides a forum for discussion of policies. By contrast, the current At Large structure has no forum for discussion (and no real work to do) but has the power to elect Board members. The existence of an At Large combining both an open forum and election power (and the creation of stakeholders' groups within each SO that have the power directly to elect Board members) will go a long way towards resolving these tensions.

With the additional ex officio director (the President of ICANN), this proposal would preserve a 19-member Board.

Process

One possible approach would be to have the in-person public meetings led by neutral, skilled, and rotating chairs who empanel varied working groups/panels to do their work in open session. Panel sessions could be interspersed with substantial open mike time during which the panel (or another group) would respond and question (led by the chair). The chair would need to play a strong role to keep the discussion moving along, and would ensure that agreement on drafts or other work product was achieved before voting occurred. These in-person meetings might need to be longer than the current compressed ICANN meeting schedule allows.

It should be obvious that much of the consensus-building work of these public fora should be taking place online in preparation for public meetings. Listservs have proved to be an inhospitable environment for true deliberation in the ICANN setting. As part of its overall restructuring, ICANN must confront the need to adopt online work settings that promote thoughtful decisionmaking without forcing participants to dig through hundreds of unorganized (even if well-meaning) email communications.

Key Principles

• A Board reflecting core ICANN goals must have some representation from all groups whose objections could lead to a successful challenge to a claim of consensus.
• All ICANN structures (and meeting formats) should facilitate dialogue among those with the greatest stake in any given policy proposal.