Reconsideration Request 01-5
Recommendation of the Committee
Date: 18 January 2002

Recommendation

In reconsideration request 01-5, Michael Froomkin and Jonathan Weinberg request review of the publication on the ICANN web site of a document entitled "A Unique, Authoritative Root for the DNS", with the designation "ICP-3". In their request, they ask that the document be withdrawn from the ICP (Internet Coordination Policy) series.

For the reasons discussed below, the committee recommends that the request for withdrawal of ICP-3 be declined. However, the committee recommends the adoption of the practice that designation of future documents within the ICP series be upon Board endorsement, so as to avoid future controversies regarding whether they are authoritative.

Background

Among the many types of documents published by ICANN is the ICP series, currently consisting of three documents.

• ICP-1, entitled "Internet Domain Name System Structure and Delegation (ccTLD Administration and Delegation)", was published in May 1999 at the time that ICANN assumed the responsibility for the IANA functions. ICP-1 collected in a single document the various policies followed by the Internet Assigned Numbers Authority (the IANA) concerning country-code top-level domain administration and delegation.
• ICP-2, entitled "Criteria for Establishment of New Regional Internet Registries", republishes criteria regarding recognition of new RIRs that were accepted by Board resolution 01.67 on 4 June 2001.
• ICP-3, entitled "A Unique, Authoritative Root for the DNS", was published on 9 July 2001 after discussion within the community and by the ICANN Board at the ICANN meeting held in June 2001 in Stockholm to document ICANN policies regarding support for a single, authoritative root.

In requesting that ICP-3 be withdrawn from the ICP series, reconsideration request 01-5 argues that the conclusions stated in ICP-3 "are not, even arguably, settled policy, 'developed through previous ICANN processes or received by ICANN at its creation.' Rather, they are new policies . . . ." The request then urges that these "new policies" can only be adopted through a bottom-up process involving a recommendation of the Domain Name Supporting Organization (DNSO), as contemplated by Article VI, Section 2 of ICANN's bylaws. Because that process has not been followed, the request asserts that ICP-3 should be withdrawn.

Analysis of Request

The policies stated in ICP-3 were not affirmatively adopted by the ICANN Board, as was the case with ICP-2. Instead, as reflected in the statement accompanying its issuance, ICP-3 is intended to articulate existing Internet and ICANN policy. As acknowledged in both that statement and the reconsideration request:

The creation of new policies implicates ICANN's community-based consensus-development processes, but until those processes achieve new policies the pre-existing policies (whether developed through previous ICANN processes or received by ICANN at its creation) should be evenhandedly followed.

The correctness of ICP-3 therefore depends on whether it faithfully recounts policies received by ICANN at its creation. These policies include those previously followed within the Internet community as well as principles expressed in ICANN's founding documents, including the June 1998 White Paper, and reflected in ICANN's Articles of Incorporation and Bylaws.

The committee has reviewed the reconsideration request's various assertions regarding pre-existing Internet policy, but finds them unconvincing. In particular:

• The request challenges ICP-3's conclusion that multiple public roots are inconsistent with DNS design principles. First, the request challenges ICP-3's citation of RFC 2826, the Internet Architecture Board's May 2000 "Technical Comment on the Unique DNS Root." Although RFC 2826 was published after ICANN's inception, that does not mean that it is unhelpful in determining what policies prevailed at the time. RFC 2826 is itself an IAB comment intended to "provide[ ] information for the Internet community," i.e., it does not state new policy. In its summary, RFC 2826 speaks of longstanding technical considerations stemming from the DNS's design fifteen years earlier: "To remain a global network, the Internet requires the existence of a globally unique public name space. The DNS name space is a hierarchical name space derived from a single, globally unique root. This is a technical constraint inherent in the design of the DNS." (Italicization added.) The RFC goes on to explain in detail the technical reasons why the DNS requires a single root to operate properly. Thus, although RFC 2826 was published after ICANN's creation, it describes technical considerations that clearly predate ICANN. There is nothing improper in referring to post-creation documents to clarify matters that occurred before ICANN's inception.
  
  Importantly, RFC 2826's explanations about the design principles of the DNS are well-supported historically. The DNS's design was documented in 1987 by two RFCs that were accorded "Internet Standard" status, RFC 1034 (Domain Names - Concepts and Facilities, P. Mockapetris, Nov. 1987), and RFC 1035 (Domain Names - Implementation and Specifications, P. Mockapetris, Nov. 1987). Those documents describe the "primary" design goal of the DNS as "a consistent name space which will be used for referring to resources", state that "[t]he domain space consists of a single tree" (italics supplied), and always refer to the "root" in the singular. Thus, RFC 2826's technical observations regarding the DNS's single-rooted design have a firm historical basis.
  
  The reconsideration request asserts that even RFC 2826 equivocates on the need for a single root, claiming that Section 1.2 of RFC 2826 "suggests that at least in theory – if not under existing implementation – 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." This assertion, however, takes a part of that section out of context. The full text of this passage of RFC 2826 reads: "It seems that a degree of cooperation and agreed technical rules are required in order to guarantee the uniqueness of names. In the DNS, these rules are established independently for each part of the naming hierarchy, and the root domain is no exception. Thus, there must be a generally agreed single set of rules for the root."
  
  As noted in the last sentence of the conclusion of RFC 2826, "There is no getting away from the unique root of the public DNS." While RFC 2826 may have been published after ICANN's creation, the DNS was designed and deployed well before ICANN, and the IAB's technical comments on the DNS's inherent design principles firmly support the technical basis of a unique root.
  
  
• The reconsideration request also asserts that received policy does not support "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'". In this comment, the reconsideration request argues that "Nothing in the original DNS specifications requires consensus community support for every TLD that is added to the authoritative root" and references a 1996 Postel draft (draft-postel-iana-itld-admin00.txt) which would have required only that each new TLD offered a minimum set of conditions.
  
  However, the referenced 1996 draft is not authoritative. The referenced Postel draft underwent two subsequent revisions (01 and 02) but eventually expired and was never published as an RFC.
  
  As ICP-3 correctly notes, what is authoritative in this context is the White Paper. That document, after summarizing the framework under which the DNS root was then coordinated, proclaimed that a change was required. In its section entitled "Need for Change", the White Paper observed: "As Internet names increasingly have commercial value, the decision to add new top-level domains cannot be made on an ad hoc basis by entities or individuals that are not formally accountable to the Internet community." This observation reflects a fundamental motivation underlying ICANN's creation—to provide a more formal accountable mechanism than previously existed for adding new top-level domains. This need led to the creation of ICANN, and represents a policy received by ICANN at its creation. It fully supports ICP-3's statement that existing policy provides that the decision to introduce new TLDs must be accountable to the Internet community and "subjected to the tests of community support and conformance with consensus processes."
  
  
• The reconsideration request both misstates the substance of the Green Paper (which did not propose addition of "five new TLDs . . . on a first-come, first-served basis") and fails to acknowledge that the Green Paper's proposals were not implemented, but were replaced by the White Paper, which articulated the policy that new TLDs should be added to the root only through a formally accountable, community-based process.
  
  
• The reconsideration request states that "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 . . . ." That observation, however, is beside the point. The issue is what ICANN policy is, not what it might be. ICP-3 does not state that TLDs operated within alternative roots may never be incorporated into the authoritative root. Instead, it states that "[n]o current policy would allow ICANN to grant such preferential rights" to TLDs included in alternative roots. The committee concludes that this statement that there is no policy of preference is well supported; indeed, the reconsideration request does not claim that there is such a policy of giving such preferences. Instead, the received policy is that new TLDs are added to the root through community decision rather than the self-implemented decisions of would-be operators. The inclusion of a proposed TLD in an alternative root does not entitle that TLD to preference over other TLD proposals.

Conclusion

After reviewing ICP-3 as a whole, the committee concludes that it accurately reiterates pre-existing and already-settled policy. The committee therefore recommends that the request for its withdrawal be denied.

The request for withdrawal has caused the committee to consider the circumstances under which documents should be designated within the ICP series. Documents should be included in the ICP series, of course, only to document existing policies (whether longstanding or newly established by Board action within the ICANN policy-formulation framework). Designation of a document in the ICP series should not itself create new policy; where new policies are being established or existing policies are being modified ICANN's various procedures for policy formulation must be followed.

In addition to the formulation of policies, however, their proper documentation is also important to ICANN's overall function. This allows members of the Internet community to clearly understand the policies. On the one hand, explanations in varying forms (e.g., advisories, FAQs, press statements, formal statements of policy) enhance the transparency of ICANN's operations and should be encouraged. On the other hand, the committee believes that it would be helpful to have an "official" series of documents articulating basic ICANN policies in an orderly manner, so that the Internet community has a convenient, authoritative source to learn these policies. The convention that documents with ICP designations are endorsed by the Board would provide an authoritative series of policy documents, and in that regard the committee recommends that the Board formally adopt the designation of the existing members of the ICP series and adopt the practice that additional designations be made upon Board endorsement. This practice, of course, should not discourage publication of informational materials in other forms.