on Establishment of the .aero Top-Level Domain
(19 December 2001)
Subject: Establishment of the
.aero Top-Level Domain
The Internet Assigned Numbers Authority (the IANA) is responsible for various administrative functions associated with management of the Internet's domain-name system root zone, including reviewing the appropriateness of various contemplated changes to the content of the root zone and preparing reports on those changes. This report gives the findings and conclusions of the IANA on the establishment of the .aero top-level domain (TLD).
The Internet domain-name system (DNS) was deployed under the guidance of Jon Postel in 1984 and 1985 (see RFC 921) as a distributed database for information about resources on the Internet, replacing the prior "hosts.txt" system. The DNS contains resource records that map easy-to-remember domain names to the unique numeric addresses assigned to every computer on the Internet.
The DNS is organized hierarchically with several top-level domains (TLDs) containing second-level domains (SLDs), which in turn contain third-level domains (3LDs), etc. A domain name consists of a series of labels, separated by dots, tracing the hierarchy from the top-level domain down to the specific computer being identified: <3LD>.<SLD>.<TLD>. Thus, the domain name "www.icann.org" is within the "www" third-level domain of the "icann" second-level domain of the "org" top-level domain.
To take advantage of the DNS's hierarchical nature, it was initially contemplated that there would be a limited number of top-level domains. In RFC 920, entitled "Domain Requirements" (Oct. 1984), Dr. Postel and Joyce Reynolds proposed top-level domains with the names "arpa" (intended to be transitional for the "ARPA-Internet"), "com" (commercial), "edu" (education), "gov" (government), "mil" (military), and "org" (organization) as well as two-letter (alpha-2) names identifying countries according to the ISO 3166-1 list."1 By the time of actual implementation of the top-level domains in January 1985, an additional top-level domain named "net" was included. In November 1988, an additional top-level domain named "int" was added for international organizations established by intergovernmental agreements.
In March 1994, Dr. Postel published RFC 1591, entitled "Domain Name System Structure and Delegation" (J. Postel March 1994), which described the overall structure of the DNS at the time. He described the top-level domains as follows:
Beginning in 1995-1996, some members of the Internet community expressed concern over lack of choice concerning registration services in the generic top-level domains (gTLDs). By January 1998, the U.S. Department of Commerce, in issuing its Green Paper3 as a discussion draft concerning possible improvements in the technical management of the DNS, listed "widespread dissatisfaction about the absence of competition in domain name registration" as a principal motivation for its conclusion that improvements in the Internet's technical management were necessary. The Green Paper discussed the introduction of additional TLDs in this context.
In June 1998, the U.S. Department of Commerce issued its White Paper,4 calling on the Internet community to form a new, not-for-profit organization to assume responsibility for the necessarily centralized technical coordination functions then performed by the IANA. In response, the Internet community formed the Internet Corporation for Assigned Names and Numbers (ICANN) in late 1998.5
The White Paper specified that one of ICANN's principal responsibilities would be to "oversee policy for determining the circumstances under which new TLDs are added to the root system," including "development of policies for the addition, allocation, and management of gTLDs and the establishment of domain name registries and domain name registrars to host gTLDs . . . ." As the White Paper recognized, "The challenge of deciding policy for the addition of new domains will be formidable." To address this challenge, in the White Paper the U.S. Government observed, "At least in the short run, a prudent concern for the stability of the system suggests that expansion of gTLDs proceed at a deliberate and controlled pace to allow for evaluation of the impact of the new gTLDs and well-reasoned evolution of the domain space."
For nearly the entire time since it was formed, ICANN has devoted a significant part of its activities to the consideration of the establishment of new generic TLDs. At the ICANN meeting in Berlin in May 1999, ICANN's Board referred the issue of new TLDs to the (then newly formed) Domain Name Supporting Organization (DNSO).6 In response to this referral, in June 1999 the DNSO Names Council (which manages the process for development of policy recommendations within the DNSO) created a group, known as Working Group C, to study the issues raised by the introduction of new TLDs.7 After nine months of extensive discussions8 and review of several position papers,9 Working Group C submitted its report to the DNSO Names Council on 21 March 2000,10 recommending introduction of a limited number of TLDs, and posted the report for public comment. Public comments were solicited and received through the ICANN's web-based comment forum and via e-mail to the dnso.org site.
The Names Council discussed the report and comments at a telephone conference held on 18/19 April 2000. At that meeting, the Names Council adopted the following statement, by a vote of 16-0 (two members were absent):
The DNSO recommendation continued:
On 16 July 2000, after considering well over 1000 public comments, the ICANN Board adopted the DNSO recommendations and authorized the ICANN President to formally call for proposals to operate or sponsor new TLDs.
On 15 August 2000, ICANN posted a public call for applications on its web site11 and broadly announced the availability of the application materials. At the same time, ICANN published detailed criteria for the consideration of any applications received. In response to the call, forty-four completed applications were received.
Once these applications were submitted, they were posted on ICANN's web site for public comment. Over 4000 comments were received; all appeared on ICANN's web site. ICANN also assembled a team of technical, financial, and legal experts12 to review and evaluate the applications, which issued a 326-page evaluation report on the applications. Additional public comments were received on this report, both on a web-based forum established by ICANN for this purpose (over 1000 comments received) and at an all-day public forum held in Marina del Rey, California, USA on 15 November 2000.
The introduction of new TLDs was the principal issue addressed at ICANN's annual meeting in November 2000. Leading up to that meeting, the Internet community had spent several weeks reviewing the applications and the detailed evaluation report, engaged in a robust dialogue on ICANN's web-based public forums (with a total of over 5000 postings), and intensely discussed the issues through ICANN's constituency and supporting organization structures. After extensive study of the materials in advance of the meeting and participation in the all-day public forum, the ICANN Board discussed the applications in a several-hour open session on 16 November 2000. As a result of this review, seven proposals to operate or sponsor TLDs were selected for an initial introduction of TLDs, as recommended by the DNSO.
In late 2000, ICANN and the proponents of the selected proposals began negotiations for appropriate agreements under which those TLDs could be introduced while preserving the stability of the DNS. These discussions led to the development of two model agreements: one for "sponsored" TLDs and another for "unsponsored" TLDs. Generally speaking, an unsponsored TLD operates under policies established by the global Internet community directly through the ICANN process, while a sponsored TLD is a specialized TLD that has a sponsor representing the narrower community that is most affected by the TLD. The sponsor thus carries out delegated policy-formulation responsibilities over many matters concerning the TLD.
In April and July 2001, negotiations of the unsponsored agreements for .biz, .info, and .name were completed and the agreements were subsequently signed. The IANA issued reports on .biz and .info (25 June 2001) and .name (16 August 2001). These three unsponsored TLDs have been added to the root zone.
In August and early November 2001, the .museum and .coop negotiations were completed; these agreements were signed (after review periods) on 17 October and 21 November 2001. On 30 October and 13 December 2001 the IANA issued reports concluding that .museum and .coop should be added to the root zone.
Negotiation of the third sponsored TLD agreementfor .aerowas completed and the agreement and all of its attachments was posted on 20 November 2001. After a review period, which precipitated a request for reconsideration, the .aero agreement was signed on 17 December 2001.
The .aero agreement, like the .museum and .coop agreements, establishes technical operational requirements, but delegates to the sponsor of .aero, Société Internationale de Télécommunications Aéronautiques SC (SITA), authority to create policies governing such topics as eligibility for registration within the .aero TLD. It also requires the sponsor to conduct its policy-development activities in manner that allows members of the .aero community to discuss and participate in the development of these policies. Thus, the sponsored TLD model ensures stable technical operation, by requiring adherence to the standard specifications on such topics as nameservice, data escrow, and use of valid host names, while providing a substantial degree of autonomy for development of community-specific policies.
This report is being provided under the 21 March 2001 contact for performance of the IANA function between the United States Government and the Internet Corporation for Assigned Names and Numbers. Under that contract, the IANA is responsible for various functions, known as the "IANA functions", associated with the management of the root zone of the Internet domain-name system.
As contemplated by the White Paper, the Internet community has pursued an extensive consensus-development process through ICANN and its Domain Name Supporting Organization. This process, which has included participation by hundreds of individuals and organizations in the Internet community, has reached the consensus position, as recommended by the DNSO Names Council without dissent, that "a limited number of new top-level domains [should] be introduced initially and that the future introduction of additional top-level domains [should] be done only after careful evaluation of the initial introduction." Following this policy and through additional community-based processes, ICANN has selected seven proposals for the initial introduction, with the goal of launching these TLDs cautiously, then observing and evaluating the results.
If the initial introduction is successful, this experience should lay the groundwork for future introductions as part of what the White Paper termed a "well-reasoned evolution of the domain space." On 13 August 2001, ICANN announced the formation of a "New TLD Evaluation Process Planning Task Force" charged with developing a plan for monitoring the introduction of new TLDs and for evaluating their performance impact on the performance of the DNS. That task force issued an interim report, on which public comment has been sought, on 3 December 2001.
ICANN has now completed contractual arrangements for the introduction of the sixth of the selected TLDs, with SITA for .aero.
The first goal of the community-based management of the DNS is to preserve the DNS's stable and reliable operation. One key prerequisite for ensuring stability is the formation of agreements creating a framework of accountability among those entities (ICANN, TLD sponsors, and registry operators) responsible for that operation. Like the previous registry agreements for .biz, .info, and .name and the previous TLD Sponsorship Agreements for .coop and .museum, the TLD Sponsorship Agreement for .aero has been designed to establish the necessary accountability framework, ensuring that .aero is introduced in a sound manner that will maintain stable and reliable technical operation of the DNS. In particular, the contract recites functional and performance specifications, data escrow requirements, and a detailed start-up plan that is designed to ensure that stable operation of the DNS is maintained, both during the startup phase and in the long term. User awareness is also relevant to smooth operation of the DNS; experience has shown that some level of confusion accompanies almost any change in the DNS. The operator of .aero however, has committed to information-dissemination measures that should keep any public confusion to a minimum.
Registration activities for .aero are scheduled to be phased in beginning
in early 2002. To assist in a stable introduction with the public awareness
needed to minimize confusion, the .aero top-level domain should be established
in the DNS at this time for testing and evaluation purposes. Initially,
the nameservice for the domains will be operated by the IANA, which will
conduct various testing procedures and then, according to schedules and
procedures developed jointly with SITA, transition the nameservice to
servers operated by those companies in time for the onset of regular resolution
of names within .aero.
The IANA concludes that the .aero TLD should be established by adding
it to the root zone at this time for testing and evaluation.
1. RFC 920 also indicated that top-level domains might be added in the future for "multiorganizations". This was never pursued, except to the extent of the .int top-level domain introduced in 1988.
2. Although the .arpa domain was intended to be used only in the transition to the DNS, it was not discontinued as originally planned because it contained the reverse-lookup domain for IP addresses (in-addr.arpa). See RFC 1101, "DNS Encoding of Network Names and Other Types" (P. Mockapetris Apr. 1989), for background. The continuing importance of the reverse-lookup facility and the practical difficulties in moving it to another domain, made it infeasible to eliminate the .arpa top-level altogether. In May 2000, the Internet Architecture Board published its "Statement on Infrastructure Domain and Subdomains", which recommends permanent retention of the .arpa TLD for Internet-infrastructure purposes. The "arpa" abbreviation was redesignated to "Address and Routing Parameter Area" to reduce confusion with the earlier network name.
3. "A Proposal to Improve Technical Management of Internet Names and Addresses" (30 Jan. 1998).
4. "Management of Internet Names and Addresses," 63 Fed. Reg. 31741 (1998).
5. In response to the White Paper, Internet stakeholders from around the world came together in an extensive process of discussions and negotiations. The process included meetings, conferences, and most appropriately for the purpose, extensive use of the Internet. By the beginning of October 1998, this process had reached a successful conclusion and on behalf of the global Internet community Dr. Postel submitted to the U.S. Commerce Department articles of incorporation and proposed bylaws for ICANN to "reflect the consensus judgment of the global Internet community as to how to form a corporation that will include the IANA function, and in addition take on other coordination and administrative responsibilities necessary for the continued operational stability and growth of the Internet. " See Letter of Dr. Jon Postel to William M. Daley (2 October 1998).
6. ICANN Board Resolution 99.48.
7. At its 25 June 1999 meeting in San Jose, California, USA, the Names Council also created another group, known as Working Group B, to study issues concerning the protection of famous trademarks in the context of any newly introduced generic TLDs.
9. These are linked from the 23 October 1999 Interim Report of Working Group C.
10. Working Group C provided a supplemental report on 17 April 2000.
12. A list of the team members and a description of their qualifications and the measures employed to ensure their independence is posted as part of the report.
Comments concerning the layout, construction and functionality of this site
should be sent to email@example.com.