IANA Report on Establishment of the .pro Top-Level Domain
Subject: Establishment of the .pro 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 .pro 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 second 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 November 2001, the negotiations for agreements with the three sponsored TLDs (.museum, .coop, and .aero) were completed; these agreements were signed (after review periods) on 17 October, 21 November, and 17 December 2001. On 30 October, 13 December, and 19 December 2001 the IANA issued reports concluding that the .museum, .coop, and .aero TLDs should be added to the root zone, and each has in fact been added.
Negotiations of the fourth unsponsored TLD agreement for .pro were required to address several novel complexities and therefore were not completed until 6 March 2002. The completed agreement and all of its attachments were posted on 7 March 2002 and discussed at the ICANN Public Forum held in Accra, Ghana, on 13 March 2002. The ICANN Board approved ICANN's entry into the agreement on 14 March 2002 and, after final corrections, the agreement was signed by both parties on 3 May 2002.
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, in 1999 and 2000 the Internet community pursued an extensive consensus-development process through ICANN and its Domain Name Supporting Organization. This process, which included extensive participation by hundreds of individuals and organizations in the Internet community, 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 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." In fall 2001, ICANN formed 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 has been undertaking that effort since that time.
ICANN has now completed contractual arrangements for the introduction of the seventh of the selected TLDs, with RegistryPro for .pro.
The first goal of the community-based management of the DNS is to preserve the DNS's stable and reliable operation. Like the previous registry agreements for the other new unsponsored TLDs (.biz, .info, and .name) the .pro registry agreement has been designed to ensure that this TLD 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. In addition, the .pro agreement's appendices include provisions tailored to the unique character of the .pro TLD. The .pro TLD is intended to contain domain names registered only to credentialed professionals (and related organizations) and to provide facilities to those accessing those domains to verify their authenticity. This presented several new challenges that have been addressed in the .pro appendices.
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 .pro however, has committed to information-dissemination measures that should keep any public confusion to a minimum.
Registration activities for .pro will commence over the next several months. To assist in a stable introduction with the public awareness needed to minimize confusion, ICANN has agreed with RegistryPro that the .pro TLD should be established in the DNS at this time for testing and evaluation purposes.13 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 RegistryPro, transition the nameservice to servers operated by the company in time for the onset of regular resolution of .pro domain names.
The IANA concludes that the .pro TLD should be established by adding it to the root zone at this time for testing and evaluation. To ensure a smooth and stable introduction, the nameservice should be operated initially by the IANA and then transitioned to the selected operator, RegistryPro, after the .pro zone is ready for population with the initial registrations and its nameserver constellations are demonstrated to be stable and robust.
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. See also RFC 3172.
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.
13. A similar procedure was followed with .biz, .info, and .name. In addition to revealing an issue concerning inappropriate DNS dynamic update attempts due to misconfigured client computers throughout the Internet, this procedure allowed the registry operators for those TLDs to establish their network information center websites at an early stage, before they were ready for full launch of their nameserver constellations. These websites assisted in efforts to educate the public about the new TLDs and also permited testing of interactive websites to determine whether they properly interact with computers in the domains of the new TLDs.
Comments concerning the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.