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.
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
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
- 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
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 creationto
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
- 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.
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.
the layout, construction and functionality of this site
should be sent to email@example.com.
The Internet Corporation for Assigned Names and Numbers.