How ICANN policy is made
Date: Tuesday July 10 2001, @09:07AM
Topic: Alternate Roots

ICANN suddenly posted to its web site yesterday a new entry in its ICP series: Stuart Lynn's paper on "A Unique, Authoritative Root for the DNS," which now has official status as an ICANN statement of policy. (ICANN also retroactively relabelled ICP as standing for "Internet Coordination Policy," and -- amazingly -- sought to shore up the new phrase by quietly inserting new language containing the phrase into its two-year-old ICP-1 document. The web does present unparalleled challenges to the integrity of historical materials.) The transmogrification of Lynn's paper to official ICANN policy document without bottom-up process, adequate public warning, or even Board participation is stunning.

But -- you say -- doesn't Lynn explain that no bottom-up process was necessary because his paper merely recaps pre-existing policy rather than making new policy? And don't Lynn and Joe Sims have answers to any other objections? Read on . . .

Stuart Lynn explains in his message accompanying the new "ICP-3" that bottom-up process was unnecessary because his document does not say anything new; it merely recaps existing policy. While ICANN must go through community-based consensus-development processes in developing new policy, he explains, no such obligation exists in connection with "pre-existing policies (whether developed through previous ICANN processes or received by ICANN at its creation)." Indeed, ICANN has an obligation simply to follow such pre-existing policies.

So let's take a careful look at ICP-3. Does it merely restate policies already developed though a bottom-up ICANN process, or "received by ICANN at its creation"? The document, as I read it, contains three key points:

[1] Alternative roots, by creating the possibility that different resolvers will return different responses to identical queries, violate DNS design goals and endanger Internet stability.

[2] No particular TLD should be included in the root zone unless its inclusion has "been subjected to the tests of community support and conformance with consensus processes."

[3] In adding new TLDs, ICANN must not take cognizance of the fact that an applicant has many registrants in an alternate root. To do so would allow the applicant to circumvent ICANN's community-based processes, violate ICANN's own obligation to serve the public trust, and jeopardize Internet stability.

Lynn's point one has the strongest claim to consensus support -- Internet engineers for whom I have the highest respect urge that a unified root is necessary to DNS design principles (as does the Internet Architecture Board), although others (whom I also respect) argue to the contrary. On the other hand, this is a debate that has been most actively joined since ICANN was created, and that is still going on. Lynn's document strains hard and unconvincingly to argue that the answer was already settled when ICANN was formed; the document, thus, is able to cite only a single, general sentence from an DNS RFC predating ICANN's creation.

Also in Lynn's support is the fact that the White Paper expresses a similar skepticism about alternate roots: The White Paper defends the US government's decision that an organization should be created to "oversee the operation of the Internet root server system [and] oversee policy for determining the circumstances under which new top level domains would be added to the root system" on the ground that "[i]n the absence of an authoritative root system, the potential for name collisions among competing sources for the same domain name could undermine the smooth functioning and stability of the Internet." Yet the relevant White Paper policy decision was a limited one: it rejected the position that a thousand roots should bloom, with no body taking IANA's role of overseeing the legacy root. It did not welcome an environment in which users seeking an authoritative root had no place to find one. But it did not in terms reject the possibility that some users might choose to use alternate root systems alongside the legacy root; indeed, it somewhat equivocally stated that the alternate roots had "contributed to the community's dialogue on the evolution of DNS administration."

The Lynn paper's point two was unquestionably not settled when ICANN was created; indeed, it does not even correctly describe current ICANN policy. Nothing in the original DNS specifications requires a test of community support and bottom-up process before a particular TLD can be added to the authoritative root. Indeed, Jon Postel's May 1996 draft-postel-iana-itld-admin00.txt would have required only that each new TLD offer a minimum set of registration services, have adequate Internet connectivity and at least two nameservers running an up-to-date version of BIND, and present some reason to believe that it could survive five years of commercial operation. The Green Paper, for its part, proposed that five new TLDs be added to the root on a first-come, first-served basis. And ICANN itself, though requiring community support, demonstrated through bottom-up processes, for the idea of adding new TLDs to the root, chose the individual registries essentially without public input. .NAME, say, was not selected because it had more "community support" than competing applicants.

This error is important, because it feeds directly into the paper's crucial point three: That ICANN in constructing its own root may not pay attention to the fact that an applicant has many registrants in an alternate root. We are told that this would allow applicants to "circumvent[] the community-based processes that ICANN is required to follow" -- yet ICANN received no policy at its creation mandating that, in choosing which TLDs to add to its root, it ignore such facts. We are told that this would constitute a yielding of the public trust requiring ICANN to ensure that each new TLD serves the public good rather than private interest. But this is flummery. Nothing in the history of the DNS or the U.S. government's policy process would forbid ICANN from adopting an approach under which the identity of new TLDs was driven primarily by the private interests of would-be TLD operators; indeed, that was essentially the approach of draft-postel.

Nor, for that matter, is it the case that the only alternative to the Lynn paper's prescriptions would be to "yield ICANN's mandate . . . to those who would simply grab all the TLD names that seem to have any marketplace value." ICANN, if it chose, could certainly adopt a policy under which it treated differently alternate-root registries based on their size, or age, or number of TLDs in operation, rewarding those who had invested genuine sweat equity but not those who simply "grabbed" names. Such an approach, indeed, might be deemed to advance DNS design principles by unifying a fractured namespace. There are arguments both ways, and Lynn's approach to alternate roots is surely defensible. But it is wholly unsupportable to argue that Lynn's approach here is part of the policy "developed through previous ICANN processes or received by ICANN at its creation"; that simply isn't so. It is a set of new policy choices, and needs to be addressed through appropriate bottom-up processes.

I might have made these points earlier, had I had some warning that ICANN was considering the step of converting the Lynn draft into an official policy paper. ICANN gave no such warning, though. The initial draft of the paper was posted, we were told, simply "to prompt community discussion," with the addendum that "I welcome constructive comments and feedback." To suddenly convert this into official ICANN policy, with no warning to the Internet community, constitutes a complete failure of process.

And speaking of process, it is odd, to say the least, that this decision was made without Board participation. Joe Sims has defended the policy's issuance on the ground that "the Board in Stockholm authorized Stuart to finalize and publish this document as a statement of existing policy." Yet here is the relevant colloquy from the Stockholm Board meeting, in its entirety:

Cerf: "Stuart?"

Lynn: "I hate to go back to the previous topic, but I just want to say that what I am interpreting from the conversation is that at least the Board encourages me, after having received comment on that paper, encourages me to go ahead and finish it off and get it posted."

Cerf: "Yes indeed, I think you'll find a consensus on that."

Lynn: "Thank you."

If that constituted a Board direction to finish the paper and publish it as an official statement of ICANN policy, it was too subtle a direction for me (and some Board members) to understand.

In sum: The Lynn paper can claim two important props: the view of the Internet Architecture Board that DNS design principles call for a single namespace, and the White Paper's interest in an authoritative root. But the paper -- especially in its prescriptions regarding ICANN's addition of alternate-root TLDs to its own root -- ranges far beyond the support provided by those, and articulates policy judgments that cannot plausibly be deemed mere restatement of what has already been settled. The paper was issued without the necessary bottom-up process, without opportunity for informed public comment, and without participation by ICANN's Board. It should be withdrawn.

This discussion has been archived. No new comments can be posted.
How ICANN policy is made | Log in/Create an Account | Top | 13 comments | Search Discussion
Click this button to post a comment to this story
The options below will change how the comments display
Threshold:
Check box to change your default comment view
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Re: How ICANN policy is made
by Anonymous on Tuesday July 10 2001, @01:23PM (#1148)
ICANNís decisions are made by a small group of arrogant men who believe they are not accountable to anybody.

Is ICANN or that small group accountable? If so, to whom?
[ Reply to This | Parent ]
  • 1 reply beneath your current threshold.
  • 3 replies beneath your current threshold.




  • This article comes from ICANNWatch
    http://www.icannwatch.org/

    The URL for this story is:
    http://www.icannwatch.org/article.pl?sid=01/07/10/130744