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 Reconsideration committee rejects our request to pull ICP-3
    posted by jon on Thursday January 24 2002, @07:13AM

    On Friday, ICANN's reconsideration committee rejected the request that Michael Froomkin and I filed last August, urging that ICANN withdraw the document entitled "ICP-3: A Unique, Authoritative Root for the DNS."

    For those of you who have mercifully forgotten: ICP-3, which sprang full-blown from the brow of Stuart Lynn last July, is primarily devoted to an attack on alternate roots. In addressing how ICANN should deal with the fact of alternate roots (and thus what weight, if any, it should give to the fact that a TLD registry seeking inclusion in the ICANN root is included in an alternate root, or that some other registry using the same string as the applicant is in an alternate root), ICP-3 gives an unequivocal blanket answer: When ICANN considers adding new TLDs to its root, it may not consider, in an applicant's favor, the fact that the applicant has substantial customers in an alternate root or the length of time it has been operating in that root. To do so would violate the public trust and jeopardize the stability of the DNS. Indeed, the paper indicates, for ICANN to pay any attention to the existence of TLDs in non-ICANN roots would violate fundamental principles.

    ICP-3 basically rests on two arguments. The first is that alternate roots are Bad, and ICANN should not do anything that might encourage them. The second is that ICANN may add a new TLD to the root only when its inclusion has "been subjected to the tests of community support and conformance with consensus processes"; for ICANN to pay attention, in its decision, to the existence of TLDs in alternate roots would violate this principle, allowing alternate root operators to hijack ICANN's processes, replacing the public interest with private self-interest.

    Froomkin and I didn't challenge any of this on the merits. Rather, we pointed out that the policies set out in ICP-3 were not – as the paper described them – old, long-settled ones, "received by ICANN at its creation." Rather, in crucial part, they were new policies, being announced by ICANN staff ex cathedra. ICP-3 thus violates ICANN's rule that new policies must be developed through bottom-up processes.

    We made three points. First, we addressed ICP-3's argument that alternate roots violate DNS design principles and impair DNS stability. This, we said, was the ground on which ICP-3 was strongest; that view of alternate roots is supported by, among other things, an IAB document (RFC 2826). But, we noted, the IAB document was released in May 2000, and could hardly have been "received by ICANN at its creation" in 1998. It is properly the grist for an ICANN policy process; it shouldn't be the basis for dispensing with such a process. ICP-3 doesn't bottom its conclusions in any statement in an RFC released before ICANN's creation except for a single non-specific sentence in RFC 1034.

    Next, we addressed ICP-3's statement that because it needed to base the addition of each new TLD in "community support and . . . consensus processes," it was free (say) to treat Neulevel's application for .BIZ more favorably because the applicant was highly capitalized, but could not (say) treat Image Online Design's application for .WEB more favorably on the ground that the registry has invested sweat equity in that domain. ICANN certainly never received that policy "at its creation." For starters, its premise is wrong: It has never been settled DNS policy that a new TLD may be added to the root only if the addition of that particular TLD had consensus community support. While ICANN has insisted that its overall decision to add new TLDs have such support, it did not select among the registries by asking, say, whether Neulevel's .BIZ or Global Name Registry's .NAME had more "community support" than competing applications. Indeed, Jon Postel's original proposals to expand the name space contemplated adding new domains essentially on a first-come-first-served basis, and the Green Paper proposed that "the first five entities (whether from a limited or unlimited pool) to meet the technical, managerial, and site requirements" described in that document should get TLDs.

    Finally -- and most obviously -- even if the premise of the statement were right, its conclusion wouldn't follow. That is, even if it were settled policy that ICANN could add no new TLD except on the basis of community support manifested through consensus processes, such a policy would not say anything about whether ICANN, in making that decision, should consider -- as one factor among many -- an applicant's position in an alternative root. ICANN has never developed a consensus policy on this point. It would be desirable to develop one, but it needs to do so via bottom-up processes.

    The reconsideration committee's statement rejecting our petition purports to respond to these points, but it doesn't do much of a job. On the ground where it is strongest, it begins by repeating ICP-3's position that the inconsistency of alternate roots with DNS design is a pre-1998 consensus. In support of that, it cites a sentence in RFC 1034 referring in passing to the domain space as a "single tree," and it points out that RFC 1034 and 1035 use the word "root" in the singular. It continues that because the IAB's statement in May 2000 describes itself as setting out basic DNS design considerations, we should take its views as reflecting a consensus in the technical community that had endured unchanged since the DNS was first designed.

    This isn't really satisfactory. Considerations of what is basic to the design of the DNS can change. When Paul Mockapetris designed the DNS in the mid-80s, he assumed that users would look to a single root – no one even suggested establishing alternate roots until the mid-90s. That fact, though, doesn't tell us whether to think of the single root as integral to DNS design, or simply an aspect of the system as originally implemented. Nor does the fact that IAB proferred an answer to the question in 2000 tell us whether that answer enjoyed consensus in 1998.

    Moving on to the ground where it is weaker, the response's arguments collapse entirely. It responds to our second point by saying that neither Postel's original proposals to expand the name space nor the Green Paper were implemented (and so, it says, we can ignore them). Rather, the statement in the White Paper that the entity in charge of adding new TLDs should be "formally accountable to the Internet community" establishes that the ICANN process for adding new TLDs must require that each addition have community support manifested through consensus processes.

    But this makes no sense. While Postel's proposals and that of the Green Paper were not implemented, they were made within the confines of the then-current consensus. That consensus was broad enough, at the time, to include any number of different approaches to choosing TLDs – public-interest-based selection, first-come-first-served, random selection, or others. The desire of the White Paper for accountability doesn't change that – indeed, the same language about the need for a "formally accountable" entity was in the Green Paper, alongside the proposal that the first five entities to meet basic requirements should get TLDs. When ICANN was formed, there was simply no consensus as to how new domains and registries should be selected.

    Then, in response to our third (and most obvious) point, the reconsideration committee is able to do no more than mischaracterize ICP-3. It suggests that ICP-3 goes no farther than a simple explanation that ICANN hasn't currently adopted a policy granting preferences to registries present in alternate roots. If that were all ICP-3 said, it would be fine. But ICP-3 doesn't just say that. Rather, it forbids any such preference, on the ground that such a step would "violat[]e the public trust under which ICANN was created and under which it must operate." ICANN can't justify treating that statement as settled consensus. And so it doesn't even try.

    The committee ends its response with a procedural fillip: it states that this and future documents in the ICP series should be formally endorsed by the Board, to ensure that they are viewed as authoritative. For the Board to pay attention to the ICP documents is indeed a good thing. But it would be better if the ICP documents were restricted to articulating matters that were already settled, rather than announcing answers to open questions on which staff would prefer not to allow bottom-up process.

      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  
  • ICANN's reconsideration committee rejected
  • request
  • "ICP-3: A Unique, Authoritative Root for the DNS."
    This discussion has been archived. No new comments can be posted.
    Reconsideration committee rejects our request to pull ICP-3 | Log in/Create an Account | Top | 2 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: Reconsideration committee rejects our request
    by fnord (groy2kNO@SPAMyahoo.com) on Thursday January 24 2002, @09:59PM (#4724)
    User #2810 Info
    The continued existence of ICP-3 may not entirely be a bad thing, given that the newest burning issue that ICANN must deal with is apparently Keywords and Other Non-DNS Identifiers. Say what? Are there no other issues that might be more important, like whether there has been any progress made on the security matters that were yesterday's burning issues; or the issue of expiring names, the WLS et al; or the issue of the new TLD rollout causing losses through fraud, perhaps into the millions of dollars, some of it by ICANN accredited registrars; or just how the Board, and SO's, will be constituted, some of which is time-sensitive, or...?

    Well, if this is the new agenda (did anyone see any bottom up consensus calling for it?), it is hard to imagine the topic of new.net won't come up, and ICP-3 might yet be a double edged sword. While it trashes alt-roots and even "pseudo-top-level domain name registries", and refers to Kent Crispin's now stale-dated internet draft which specifically uses new.net as an example, clearly new.net (and RealNames and suchlike) aren't within ICANN's purview, there is nothing within ICP-3 to support a contrary notion, and ICP-3 is now the law, as it were. By over-reaching perhaps ICANN has limited its range of motion.

    And perhaps I'm reading this all wrong, Karl Auerbach states in his Dec. 2001 diary entry on the IDN Committee:

    Director Mueller-Maguhn and myself have accepted an informal board request to create a document that describes the distinction between names as entered by users into the address bar of Microsoft's Internet Explorer and names as expressed as domain names. The purpose of this document would be to begin to delineate some of the limits of ICANN's responsibilities.
    Much as I think there are more pressing issues, if ICANN wants to give Karl and Andy top billing while they attempt to put ICANN on a short leash, this might not be a total waste of time. ICP-3 as written supports the short leash model. -g
    [ Reply to This | Parent ]

    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