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 request: ICANN's "Authoritative Root" paper
    posted by jon on Wednesday August 08 2001, @03:24PM

    Michael Froomkin and I asked ICANN today to reconsider its adoption of Stuart Lynn's "Unique, Authoritative Root" paper as part of the ICP policy-document series. Speaking only for myself: I'm a little surprised to find myself in this position. I've got serious concerns about new.net and some of the other folks out there. I don't in fact expect alternate roots to get any significant portion of resolver queries any time in the foreseeable future. I think that some of Lynn's paper is well-taken. But it seems to me that ICANN's justification of its top-down embrace of the paper -- its explanation that the paper did no more than restate "pre-existing" ICANN policy -- is simply wrong. Whether or not the policy articulated in the paper is good or bad, the fact is that ICANN has no pre-existing policy on how it should deal with alternate roots. It should develop one. And it should do so though a bottom-up policy process. I think that point is worth filing a reconsideration request to make.

    Here's the reconsideration request:

    Re: Reconsideration of ICP-3, “A Unique, Authoritative Root for the DNS”

    On July 9, 2001, ICANN posted a paper by Stuart Lynn entitled “A Unique, Authoritative Root for the DNS” as the third member of the ICP series of ICANN policy documents. The paper, thus, now appears to represent official ICANN policy. We respectfully request that the Lynn paper be withdrawn from the ICP series. The Lynn paper at its heart relates to substantive policy matters that are within the proper sphere of the Domain Name Supporting Organization, and that must be explored through bottom-up processes. Its adoption as ICANN policy without bottom-up policy development violates Article VI, sec. 2 of ICANN’s bylaws. Dr. Lynn urged, in a statement he released accompanying the paper, that no bottom-up process was necessary because the paper “did not create new policy”; rather, it simply articulated “pre-existing policies (whether developed through previous ICANN processes or received by ICANN at its creation).” An examination of the record, however, reveals that statement to be incorrect. The report announces multiple new policy judgments that are by no means a restatement of already-settled matters. Such new policy determinations should not be announced by staff fiat, without the bottom-up processes appropriate for a consensus-based organization.

    The ultimate policy content of ICP-3 lies in its approach to the key policy question now facing ICANN in this area: How should ICANN deal with the fact of alternate roots? When considering a request by a prospective TLD registry for inclusion in the ICANN root, what weight, if any, should it give to the fact that a competing registry, using the same TLD string, is already in operation in an alternate root? Should this answer depend on particular facts about the competing registry? What if such a registry is itself seeking inclusion in the ICANN root? What special factors, if any, should ICANN consider in deciding whether to include it?

    ICP-3 gives an unequivocal 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. To do so would violate the public trust and jeopardize the stability of the DNS. Indeed, for ICANN to pay any attention to the existence of TLDs in non-ICANN roots would violate fundamental principles, for it would inhibit new names with the same TLD string from being incorporated into the DNS “through the community’s processes.”

    These conclusions are not, even arguably, settled policy, “developed through previous ICANN processes or received by ICANN at its creation.” Rather, they are new policies, announced in this document. In order to reach its conclusions, ICP-3 relies on several subsidiary statements. These statements too, for the most part, are not settled policy. They are new decisions, which must be addressed through appropriate bottom-up processes.

    The paper’s starting point is that alternate roots violate DNS design principles, and inherently “endanger” and “impair” DNS stability. This is the ground on which the paper is strongest. Some of its characterization is well-accepted; specifically, it is well-accepted that the existence of alternate roots means that, to some extent, names may not all be globally unique. The significance of that fact, however, and the extent to which it would “impair the Internet’s utility,” are disputed. Further, it is disputed whether mechanisms other than a single root would adequately address these concerns.

    The proposition that alternate roots are inconsistent with DNS design principles is supported by a recent document – RFC 2826 – issued by the Internet Architecture Board. Any document endorsed by the IAB is entitled to great respect. On the other hand, it is difficult to argue that this document was “received by ICANN at its creation”; it was not released until May 2000. There is scant discussion of alternate roots in the earlier RFCs; Dr. Lynn’s paper can identify only a single, general sentence that is even arguably relevant in a DNS RFC pre-dating ICANN’s creation. (Nor is the matter so clear-cut even in RFC 2826. Section 1.2 of that document suggests that at least in theory – if not under existing implementations – multiple bodies could control the root space so long as the various roots were characterized by “a degree of cooperation” and followed an adequate set of agreed technical rules.)

    Also in support of Dr. Lynn’s paper is the fact that passages in the White Paper expresses 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" in part 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."

    Dr. Lynn’s paper, in moving to its ultimate policy prescriptions, moves from arguably contested ground to ground on which its lack of support in agreed-on policies is palpable. The reason the paper most vigorously gives in support of its conclusion that ICANN may not count a hypothetical applicant’s many subscribers in an alternate root in its favor, is that this would violate ICANN’s obligation not to include a TLD in its root zone unless the inclusion of that TLD has “been subjected to the tests of community support and conformance with consensus processes.” The inclusion of entries in ICANN’s root zone would end up being driven by the private choices of would-be registry operators, rather than by a deliberate public-interest determination made by ICANN itself; 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 conclusion is doubly unsupported.

    First of all, the proposition that no particular TLD should be included in the ICANN root zone unless its inclusion has “been subjected to the tests of community support and conformance with consensus processes” was not received policy when ICANN was created, and it is not ICANN policy now. Nothing in the original DNS specifications requires consensus community support for every TLD that is added to the authoritative root. 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. Under that approach, in which new TLDs would have been added to the root zone essentially on a first-come-first-served basis, the private interest of would-be TLD operators would have largely determined the identity of the new TLDs. The Green Paper, similarly, 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, has required nothing comparable in choosing the individual registries. It did not rest its approval of particular applications last year on a conclusion that, for example, Neulevel’s .BIZ or Global Name Registry’s .NAME had more “community support” than competing applications.

    Nor, for that matter, is it the case that the only alternative to the 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. That approach could also address concerns about the incentive effects of ICANN’s policy. Such an approach, indeed, might be deemed to *advance* DNS design principles – and promote Internet stability – by unifying a fractured namespace.

    In submitting this reconsideration request, we do not express any opinion on the ultimate merits of any policy ICANN might choose to adopt on this topic. Dr. Lynn’s prescriptions in this paper are surely defensible; members of the ICANN Board may well believe them to be correct. It may be that, if bottom-up processes are allowed free rein, they will result in a similar approach. But the statement is unsupportable that the policy set out in the paper was "developed through previous ICANN processes or received by ICANN at its creation." ICANN has developed no such policy, and its actions to date regarding TLD registries in alternate roots reflect no consistent theme. (These actions, indeed, include one Board vote not to include the Afilias .WEB in the ICANN root, after Dr. Cerf expressed concerns about the .WEB registry present in the ORSC root.) Dr. Lynn’s paper articulates a plausible but *new* set of policy choices, on matters that – until recently – have not been extensively discussed. ICANN should develop that policy through appropriate bottom-up processes.

    Again, we do not express any opinion on the merits of the policy expressed in ICP-3. Our concern, rather, is that ICANN should ground any policy it adopts in a bottom-up consensus process. If only because it prevents us from participating in and contributing to a genuinely bottom-up policy development process, ICANN’s precipitous action affects us personally. We request that it be reconsidered and withdrawn.

    Michael Froomkin
    University of Miami School of Law
    1311 Miller Drive, Coral Gables, Florida 33124-0221

    Jonathan Weinberg
    Wayne State University Law School
    471 West Palmer Street, Detroit, MI 48202

      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. ]

    This discussion has been archived. No new comments can be posted.
    Reconsideration request: ICANN's "Authoritative Root" paper | Log in/Create an Account | Top | 7 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 request: ICANN's
    by DannyYounger on Wednesday August 08 2001, @04:20PM (#1720)
    User #2979 Info
    I fully support this reconsideration request.

    ICP-3 was issued without the necessary bottom-up process, without any public comment, without General Assembly consensus, without constituency input, without Names Council evaluation, and without full informed participation by ICANN's Board.

    Danny Younger
    Chair, General Assembly -- DNSO
    [ Reply to This | Parent ]
    • 1 reply beneath your current threshold.
    Re: Reconsideration request: ICANN's
    by sergio on Thursday August 09 2001, @12:02AM (#1726)
    User #27 Info
    Both points can be meaningful. On the one hand it's interesting to see the reconsideration request procedure working again, until now we haven't got much results from this instrument even if it COULD be a very usefull one. On the other hand there's here a procedure point that touches the way ICANN has acted, both relating the consensus policy and the substance of the ICP-3 policy itself.
    Even if it is hard to expect much results from the *request*, I support it.
    [ Reply to This | Parent ]
  • 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