An ICANN reform plan

Harald Tveit Alvestrand <>, speaking for himself only

version 1.0 - June 22, 2002

This is the week before the Bucharest ICANN meeting, and the air is swarming with reorganization plans, alliances, cabals, opinions and thoughts.

It seems therefore fitting that I, remaining an outsider to ICANN process, and not having read the current proposals for reform, should make my own opinions publicly known.

As remarked in my previous notes on ICANN, the technical jobs of ICANN are not big and complex tasks. But for parts of the tasks, the job of figuring out what orders to give is complex.

A huge segment of the ICANN technical work is not controversial; IANA protocol parameter registrations are carried out under the sole, competent and uncontroversial oversight of the IETF; address allocation policies are well handled by industry self-regulation through the open forum of the Internet registries; many (but not all) country-code domains are handled with full understanding between a government that understands the Internet and organizations that are fully trusted by their government and fully competent to operate within its jurisdiction.

Yet problems remain; the addition of new top level domain, common rules for the "global" TLDs that have extensive usage in many countries, introduction of security records in the root zone, and so on.

The problems faced in these two modes of operation are very, very different. This document argues that keeping them within the same organization is not a recipe for success, and suggests an alternative.

The Split

For each task currently assigned to ICANN, one should try to identify two parties - NOT one. 

To avoid reusing old reactions, I've picked names for the two organizational types here that, to my knowledge, have never been used before in this debate: The TrustWorthy Operator (hereafter referred to as the TWO) and the Policy Decision Forum (hereafter referred to as the PDF). One advantage of these acronyms is that they are not what anyone would want to keep around as permanent names for these functions.

A TWO will take care of technical operation of Internet-critical registries under two conditions:

A PDF is a forum that will take care of deciding policy issues, consulting with all relevant parties and testing proposed results in the courts of public opinion.

A PDF will be one, but not the only, type of client of the TWO.

There is no particular need for all ICANN functions to be bundled within a single TWO; one can imagine many scenarios, from each individual function that ICANN currently does acquiring its own TWO to a situation where a TWO function is performed by a body that also does other functions.

Neither is there a need for all ICANN problems to be settled within a single PDF; there is no particular reason that the same body that is competent to set policy for IPv6 address allocations will be competent to decide upon procedures for reallocation of hijacked domains; the problems have very little in common.

The only limit to the division is technical soundness - for instance, one TWO must be the steward for the content of the DNS root zone file.

Characteristics of a trustworthy TWO

A TWO needs to avoid two errors:

Therefore, a TWO should have the following characteristics:

Such organizations exist, or can be created. Their configuration, their board membership or their "representativeness" does not matter so much, because they do not make policy decisions.

A Policy Decision Forum

For certain matters ICANNish, there is a real need for discussion.

The Right Answer is not obvious, there are multiple parties with conflicting interests, and there are multiple possibly reasonable outcomes where a decision will have to be made.

Competent technical input is still essential - demanding the impossible can never be a constructive action - but consideration of the interests of the Internet-using public, both present and future, needs to be an essential part of the process leading to a decision.

The poster child of this class of problem is the issue of adding new top level domains, where considerations of competition logistics led to the consensus that some should be added, technical considerations led to the consensus that the number of new domains should be low, and considerations of experiment design led to the chartering of domains with a wide range of policies.

The design of policy fora is outside this author's area of competence; still, a few matters are pretty clear by now:

The poster child of the ICANN process may very well be the Uniform Dispute Resolution Policy (UDRP) - this policy is enormously better for the Internet user than the "NSI wants to avoid being sued" policy that it replaced. Its progeny lay with the WIPO process (a pool of trademark legal expertise, which chose to listen to input from Internet technical and social expertise); its conclusions got heavily modified through public input (and the hard work of a few dedicated individuals), and the result, while far from perfect and still reviled by many, has served the Internet community far better than the previous incarnation of policy.

Some of the needed properties of a policy forum include:

Note that these properties are different from the ones required for a TWO. Part of ICANN's misery can probably be traced back to exactly that fact.

Policy fora exist in many incarnations. Some of them have elaborate rules for consensus forming, veto rights and representation. Others are based strictly on the buying of membership, and accord voting rights according to financial contributions. Still others have more informal structure.

In some areas of ICANN space, for instance in the ASO, adequate policy fora seem to exist already.

It is not the purpose of this writer to suggest any single form that would be best for the formation of the policy forum that would be the client of a trustworthy operator on TLD administration issues.

But if one can separate the problem of operational stability from the problem of adequate representation on contentious issues, it might be a little easier to take a step forward.