Inside ICANNWatch  
Submit Story
Lost Password
Site Messages
Top 10 Lists
Latest Comments
Search by topic

Our Mission
ICANN for Beginners
About Us
How To Use This Site
Slash Tech Info
Link to Us
Write to Us

  Useful ICANN sites  
  • ICANN itself
  • Bret Fausett's ICANN Blog
  • Internet Governance Project
  • UN Working Group on Internet Governance
  • Karl Auerbach web site
  • Müller-Maguhn home
  • UDRPinfo.com;
  • UDRPlaw.net;
  • CircleID;
  • LatinoamerICANN Project
  • ICB Tollfree News

  •   At Large Membership and Civil Society Participation in ICANN  
  • icannatlarge.com;
  • Noncommercial Users Constituency of ICANN
  • NAIS Project
  • ICANN At Large Study Committee Final Report
  • ICANN (non)Members page
  • ICANN Membership Election site

  • ICANN-Related Reading
    Browse ICANNWatch by Subject

    Ted Byfied
    - ICANN: Defending Our Precious Bodily Fluids
    - Ushering in Banality
    - ICANN! No U CANN't!
    - roving_reporter
    - DNS: A Short History and a Short Future

    David Farber
    - Overcoming ICANN (PFIR statement)

    A. Michael Froomkin
    - When We Say US™, We Mean It!
    - ICANN 2.0: Meet The New Boss
    - Habermas@ discourse.net: Toward a Critical Theory of Cyberspace
    - ICANN and Anti-Trust (with Mark Lemley)
    - Wrong Turn in Cyberspace: Using ICANN to Route Around the APA & the Constitution (html)
    - Form and Substance in Cyberspace
    - ICANN's "Uniform Dispute Resolution Policy"-- Causes and (Partial) Cures

    Milton Mueller
    - Ruling the Root
    - Success by Default: A New Profile of Domain Name Trademark Disputes under ICANN's UDRP
    - Dancing the Quango: ICANN as International Regulatory Regime
    - Goverments and Country Names: ICANN's Transformation into an Intergovernmental Regime
    - Competing DNS Roots: Creative Destruction or Just Plain Destruction?
    - Rough Justice: A Statistical Assessment of the UDRP
    - ICANN and Internet Governance

    David Post
    - Governing Cyberspace, or Where is James Madison When We Need Him?
    - The 'Unsettled Paradox': The Internet, the State, and the Consent of the Governed

    Jonathan Weinberg
    - Sitefinder and Internet Governance
    - ICANN, Internet Stability, and New Top Level Domains
    - Geeks and Greeks
    - ICANN and the Problem of Legitimacy

    Highlights of the ICANNWatch Archive
    (June 1999 - March 2001)

    Alternate Roots How ICANN policy is made
    posted by jon on Tuesday July 10 2001, @09:07AM

    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.

      ICANNWatch Login  


    [ Don't have an account yet? Please create one. It's not required, but as a registered user you can customize the site, post comments with your name, and accumulate reputation points ("karma") that will make your comments more visible. ]

      Related Links  
  • initial draft
  • defended
  • Stuart Lynn's paper on "A Unique, Authoritative Root for the DNS,"
    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
    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.

  • Search ICANNWatch.org:

    Privacy Policy: We will not knowingly give out your personal data -- other than identifying your postings in the way you direct by setting your configuration options -- without a court order. All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 by ICANNWatch.Org. This web site was made with Slashcode, a web portal system written in perl. Slashcode is Free Software released under the GNU/GPL license.
    You can syndicate our headlines in .rdf, .rss, or .xml. Domain registration services donated by DomainRegistry.com