Subject: 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 froomkin@law.miami.edu Jonathan Weinberg Wayne State University Law School 471 West Palmer Street, Detroit, MI 48202 weinberg@wayne.edu
Comments concerning the layout, construction and
functionality of this site
(c) 2000 The Internet Corporation for Assigned Names and Numbers All rights reserved. |
