The recent extension of the Memorandum of Understanding between the Department of Commerce and ICANN provides both parties with an opportunity to focus on what is most important about the ICANN experiment. DOC will be requiring ICANN to report quarterly on its progress, and will presumably be watching ICANN more closely than it has in the past. The following is a proposed roadmap for consideration of the key issues and a set of suggestions for immediate next steps."

Reaffirming the consensus policy process. Two fundamental limits will prevent abuse of ICANN's claimed powers. First, it must only address certain subjects. Second, it must only impose mandatory rules under certain conditions: notably, when most of those substantially affected by the rules agree to go along (or don't object vigorously and rationally).

After establishing its narrow mission, ICANN's next priority should be to reaffirm the role of the consensus policy process. DOC has noted that ICANN must improve its processes for transparency and accountability, and has stated that such improvements should include "clear policy development procedures." Clearer, more efficient, and timelier processes are undoubtedly necessary, and many have been suggested in the course of ERC's work. But such processes are a means to an end -- consensus policies -- rather than an end in themselves. The original answer to the question of ICANN's source of power, an answer present in the origins of ICANN and essential to its legitimacy, is that mandatory policies should be made when and only when most of those affected by such policies agree that they are necessary (or, at least, acceptable).

ERC should recall that, under the express terms of contracts between ICANN and the gTLD registries and registrars, any mandatory ICANN policy must be the result of consensus as 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. Under the express terms of all the contracts that give ICANN its power, the role of any cross-constituency council (and the Board itself) is not to act as a legislature but instead to facilitate and evaluate the results of the consensus policy development process. These contracts also spell out particular issues that may be the subject of mandatory consensus policies. The recommendations developed by the Names Policy Development Process Assistance Group expressly did not address the relationship between these existing contracts and the process the Assistance Group was recommending, because the Group viewed that analysis as outside their scope. The most cursory review of the proposed policy development process will reveal to ERC that, in fact, ERC has been presented with a process that is ineffective vis-à-vis the registries and registrars because it does not meet applicable contractual standards.

As suggested by the Names Policy Development Process Assistance Group, ERC should immediately call for an analysis of the changes that would be required in the policy development process it is proposing in order for resulting policies to be enforceable as against gTLD registries and registrars. ERC will learn that some ICANN policies (non-mandatory or administrative policies) may certainly be developed through the process the Assistance Group has proposed. But mandatory consensus policies, binding on gTLD registries and registrars, cannot be. Reaffirmation of the need to demonstrate and document consensus in support of binding policies would fill this gap.

Putting in place the Independent Review Panel. Greater assurance that ICANN really is staying within the scope of a narrowly defined mission and developing consensus policies, rather than merely claiming the existence of broad consensus for policies the Board itself has decided to adopt (or the staff has chosen to impose), can be achieved by prompt establishment of the Independent Review Panel that is itself required by ICANN's contracts and contemplated by its bylaws. Availability of a neutral forum for review of claims that ICANN had exceeded its core mission would reduce both suspicions about ICANN's legitimacy and resistance to participation in its processes. ERC has suggested the creation of an "ombudsman," and we think that is a fine idea. Whatever the function of the "ombudsman," however, he/she would not reduce the need for an Independent Review Panel, the "constitutional court" that, in order to ensure ICANN's accountability, must review challenged consensus policies before they can be imposed on registries and registrars. Current contracts provide that ICANN's policies are not binding on gTLD registries and registrars unless and until an IRP is created. To make itself "effective," ICANN should comply with this contract clause.

DOC has required ICANN to implement accountability mechanisms to address claims by members of the ICANN community "that they have been adversely affected by decisions in conflict with ICANN's ... contractual obligations." Establishment of the IRP will go a long way towards satisfying this requirement.

Establishing minimum criteria for new TLDs. DOC has instructed ICANN to "continue the process of implementing new top level domains (TLDs)," and to "develop criteria upon which to base its selection of gTLD operators." This is a subject on which ERC has not focused. ERC should recognize that it is essential to relieve the pressure created by the perception that ICANN has no plans to open up the name space to new competitors. Establishment of minimum technical and functional criteria (and publication of a schedule for acting on new applications) will make clear that ICANN does not seek to prevent competition or to create artificial scarcity on which it can base subjective rulemaking powers. One of ICANN's (and ERC's) top priorities should be to call for the "public articulation of the process, selection criteria, and the rationale for selection decisions" for new TLDs required by DOC, and to make each of these elements as objective and light-handed as possible.

Developing "thin" contracts for ccTLDs. DOC specifically notes that "an agreement that would appeal to the majority of ccTLD operators has not yet been defined," and repeats its admonition (present in various forms in every other revision of the MOU) that "establishing stable agreements with country code top level domain operators is an important component of securing the future stability of the Internet." ICANN should focus its staff's efforts on developing "thin" contracts that would actually be attractive to ccTLDs. Such contracts would, among other things, allow ccTLDs to have a determinative say regarding which issues are properly local and which policies should be mandatory for all ccTLDs. We note, again, that building the consensus policy clause into the ccTLD contracts would have this effect. Eliminating the claim that IANA may hold off on database changes in order to force ccTLDs to accept a contract that (1) ignores their views in determining which policies are global, and (2) exposes ccTLDs to risks of redelegation over the opposition of the ccTLD community, would go a long way towards securing ccTLDs' agreement.

Developing "thin" contracts for RIRs. DOC has underlined the importance of establishing stable relationships and formal legal agreements between the RIRs and ICANN. ICANN should focus its efforts on finalizing the draft "memorandum of understanding" between the RIRs and ICANN that was posted in April 2002. This agreement should not permit the RIRs to withdraw if they do not agree with an ICANN policy, but should respect their views by allowing ICANN to impose mandatory addressing rules only if significant opposition from the RIR community is not heard.

Changing ICANN's vision of itself. The most fundamental change DOC should look for over the next few months is a modification of ICANN's views regarding its own importance. Recent responses by ICANN to statements by the RIRs and the ccTLDs have revealed a disturbing blindspot in ICANN's vision of its role. It appears that ICANN cannot imagine any circumstances in which its judgments regarding what is best for the net are unnecessary. The tragedy is that this ICANN-centric viewpoint obscures better ways to "coordinate" the net.

ICANN's most recent expression of its self-perceived essentiality took the form of a response to the RIRs, who had had the temerity to suggest that they could develop policy and coordinate IP block allocation, cooperatively, themselves. In its response to the RIRs, ICANN staff patiently explained that the interests of the Global Internet Community could not possibly be "truly" reflected within the "regional" processes that have been implemented by the RIRs. ICANN completely discounted the RIRs' claim that "address allocation policies are best developed within the RIR process by those who understand and represent the needs of the interested constituencies," as well as the RIRs' concern that ICANN does not have the resources to carry out policy tasks with respect to address allocation.

Similarly, when the ccTLDs claim a right to decide which policy issues are global and when global ICANN policies should be binding on them (and to otherwise be responsible for their own local decision-making in consultation with their "local internet communities"), ICANN has responded that only ICANN can decide what issues may be solved locally and what issues must be addressed by mandatory global rules. Along the same lines, when gTLDs explain that they are constrained by the market and should be free to run their businesses as they see fit (absent a consensus that new rules are needed), ICANN responds that it must approve any change in their operations. These approaches reflect ICANN's view that it alone can act to protect the interests of the Global Internet Community.

The ICANN-centric worldview suffers from a critical blindspot: ICANN simply cannot see the possibility that local and decentralized organizations and actors may actually best reflect the views and values of all local actors. Particularly where the local organizations in question are open to broad participation or are constrained by market forces because customers can make choices among several options, deferring to actions by local organizations may produce optimal global solutions from the bottom up. Instead of reserving final approval powers to itself, ICANN could decide to increase potential competition, to delegate as much decision-making as possible to local or decentralized, autonomous groups that can more reliably reflect local values, and to allow these local groups to compete against each other to make policies attractive to participants.

It is admirable that the staff takes its responsibilities so seriously -- less so that they cannot see the value of reducing the burdens placed on global policy-making by ICANN. The founding goals of ICANN were to create bottom up decision-making and increase competition. Those involved in creating ICANN assumed that it would make relatively few global rules and would do so only when there was broad agreement that such rules were necessary.

There may be some need for some global rules. There is certainly a need to assure competition at all levels of a system that is capable of providing end users with too few choices or presenting risks of "lock in" to the choices they have made. But the need for competition would best be served by an ICANN decision to make it easier for new competitors to enter the business -- and for existing competitors to experiment with new business models and diverse terms and conditions.

We need a kind of ICANN that believes in the same kind of decentralized, cooperative action that gave rise to the net in the first place. Above all, DOC should now be watching for this central change in attitude to begin to manifest itself in ICANN's day-to-day decisions.

David R. Johnson is the founder of Graphical Groupware. Susan P. Crawford is a partner with Wilmer, Cutler & Pickering. This article was written in our personal capacities, and does not necessarily reflect the views of any client of Wilmer, Cutler & Pickering.

And just in case that, or anything else, became a credible threat, they created at-large.org. If ever forced into having to deal with a union, they already have one in place. The setting up of so-called company unions is not new, in fact particularily in the US it has a long tradition. Getting in on the ground floor and making an otherwise non-docile union beholden to you from its inception in case your first choice isn't accepted is another timeworn tradition. So ICANN just went with tradition. The problem with that is that there is little in the traditional world that maps to the internet. We don't have to join unions, we can all act individually and independently, coalescing only around a particular issue as and when necessary and then freeing ourselves to move on in ever more unpredictable trajectories. That is, near-impossible to control. That is one strength of the internet. Use it, and ICANN can't win. -g