Toward a Statement of the ICANN Mission
Posted: 7 March 2002
Revised: 10 March 2002
|
Toward a Statement of the ICANN Mission Note:As the dialogue about ICANN reform continues, it is useful to also focus on the ICANN mission. It is difficult to arrive at a consensus about ICANN's structure and procedures unless there also exists a consensus on what ICANN's mission is – and what it should be going forward. It is quite clear that, to date, ICANN's mission has not been limited to only technical coordination. As one obvious example, the promotion of competition is not a technical objective, but it has been an important part of ICANN's mission from the beginning. Nevertheless, ICANN's mission cannot be open-ended; there must be understood boundaries, or ICANN risks losing its focus. Thus, the development of a common general understanding of what types of global coordination activities are either required or highly desirable for the proper functioning of the Internet's naming and address allocation systems, and thus reasonably fall within the ICANN mission, is an important component of the ongoing ICANN reform effort. This document is an attempt to provide a beginning point for that discussion by enumerating the most significant activities that ICANN does today. It is not intended to be an exhaustive list, or a defense of a particular structure or mission, but simply a statement of current fact. The hope is that this description of the status quo will facilitate a substantive debate about what (if any) changes – additions or subtractions – are appropriate going forward, and how the boundaries that result from that discussion can best be articulated. That in turn should be a useful contribution to the community discussion about the nature of the reforms to ICANN's structure and procedures that are best suited to ICANN effectively carrying out its mission. |
What ICANN Does
Staff Draft - Version 1.1 - 10 March 2002
The Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for coordinating the Internet's naming, address allocation, and protocol parameter assignment systems. These systems enable globally unique and universally interoperable identifiers for the benefit of the Internet and its users.
These systems are highly distributed: hundreds of registries, registrars, and others, located around the world, play essential roles in providing naming and address allocation services for the Internet. ICANN's paramount concern is the stability of these remarkably robust services.
As overall coordinator of the Internet's systems of unique identifiers, ICANN's role, while defined and limited, includes both operational and policymaking functions.
In the operational sphere, the ICANN staff perform a range of day-to-day services, including:
(1) maintaining the DNS root zone file,
(2) allocating top-level blocks of IPv4 and IPv6 addresses and AS numbers to the regional Internet registries,
(3) maintaining 120+ registries of protocol port and parameter numbers,
(4) publishing online databases of information about the top-level domain registries included in the DNS root zone file,
(5) operating one of the thirteen authoritative DNS root name servers, and coordinating the overall DNS root name server system,
(6) publishing the InterNIC website and related functions,
(7) operating the .int registry,
(8) maintaining common/technical IP address spaces, such as the private-use address space,
(9) managing the reverse delegation namespace at the top level, and
(10) administering the DNS implementations of certain technical registries, such as .arpa and the legacy infrastructure-related .int zones.
In addition, ICANN staff perform a set of day-to-day administrative and policy functions relating to the generic top-level domain (gTLD) registries, including:
(1) accreditation of competitive registrars;
(2) supervising the administration of the Uniform Dispute Resolution Policy;
(3) handling of complaints about registrations;
(4) monitoring and enforcement of registry and registrar agreements, and
(5) implementation of data escrow programs.
For the country-code top-level domain (ccTLD) registries, ICANN staff handle, investigate, and process requests for delegation and redelegation, and for changes in the TLD nameservers specified in the root zone file.
Finally, ICANN has the responsibility for policy coordination with respect to the security of the various parts of infrastructure that make up the operational DNS. This activity is reflected in the recent creation of the Standing Committee on Security and Stability. In addition, ICANN has certain operational security responsibilities with respect to ICANN's operational activities. Finally, ICANN attempts to nurture and encourage continuing and serious attention to security and stability issues by all participants in the DNS, and to ensure that necessary tasks are undertaken by some responsible party.
In the policymaking sphere, ICANN is responsible for developing and implementing policies related to each of its operational functions. The nature and scope of ICANN's policymaking role differs for each function.
For example, in the area of IP address and AS number allocation, ICANN's responsibility extends only to global addressing policies; local policies are made by each regional Internet registry or lower-level Internet registries. ICANN's policy role for the country-code top-level domain registries (ccTLDs) is similarly limited to global policy coordination with deference to each local Internet community's responsibility to set its own registry-level policies (i.e., registration criteria, pricing, dispute resolution, mechanisms for local community participation and policymaking, etc.). In the area of protocol numbering, ICANN administers the IANA registries pursuant to the instructions of the Internet Engineering Task Force (IETF).
By contrast, ICANN plays a more direct and significant role in setting registry-level policies for the global top-level domain registries (gTLDs), such as .com, .net, .org, .info, .name, and .biz. In effect, ICANN serves as the global Internet community's open policymaking forum for the gTLD registries.
In its initial charge from the U.S. Government, embodied in the 1998 White Paper, ICANN policymaking was to be guided by a set of non-technical principles: preserving stability; promoting competition; relying where possible on private-sector, bottom-up, participatory mechanisms that reflect the functional and geographic diversity of the Internet; development of efficient dispute resolution alternatives (for the gTLD registries); and promoting accountability in management (for all registries).
These principles are necessarily somewhat general, which has led to some confusion and disagreement about the exact boundaries of ICANN's policymaking mission. This has led some to suggest that those boundaries should be restated and described in as much detail as is feasible, taking into account the necessary flexibility required to effectively deal with the rapidly changing nature of the Internet. Such an effort, to the extent it produced useful guidance both for ICANN and the Internet community as a whole, would undoubtedly be a helpful contribution to the current ICANN reform discussions.
A note on terminology: Historically, most of the operational functions described above were performed under the label of the Internet Assigned Numbers Authority (IANA). Though administered by a single team at the Information Sciences Institute of the University of Southern California, the IANA functions were performed at the direction of two sources: the IETF and the U.S. Government. Pursuant to an agreement with the U.S. Government and a Memorandum of Understanding with the IETF, ICANN is currently responsible for the full set of IANA functions. Thus, one should keep in mind that IANA refers to a set of functions, and that ICANN is the organization designated separately by the U.S. Government and the IETF to perform the IANA functions for the benefit of the global Internet community.
The following sections describe ICANN's responsibilities and activities in greater detail.
On an operational level, ICANN's Internet naming responsibilities center on two functions: the DNS root zone file and the DNS root name server system.The DNS root zone file consists of a list of all top-level domains in the authoritative public DNS (currently 259 TLDs), along with the names and IP addresses of the primary and secondary name servers that are authoritative for each TLD. As part of the IANA functions, ICANN is responsible for defining the contents of the DNS root zone file, which means maintaining and updating the list of recognized TLDs and the name servers for each TLD. ICANN is also responsible for promulgating the file for publication by the 13 authoritative root name servers.
The policy tasks related to the root zone file correspond to the three basic operational functions required to maintain it: TLD delegation, TLD re-delegation, and TLD name server changes. The particular scope of ICANN's responsibilities for these functions differs for generic TLDs and country-code TLDs, and varies according to the terms of the formal registry agreements.
Under ICANN's existing relationship with the U.S. Government, all TLD delegation, re-delegation, and name server change requests require the final approval of the U.S. Government. Thus, at the moment ICANN's role in this regard is limited to making recommendations for changes to the US Department of Commerce, which has the operational oversight responsibility for the DNS root zone file.
The term "delegation" refers to the addition of a new TLD to the DNS. In narrow technical terms, this means that a new TLD entry is added to the DNS root zone file, along with the names and IP addresses of the authoritative name servers for the new TLD. The addition of new gTLDs is one of the policy objectives specifically assigned by the U.S. Government's White Paper. In November 2000, ICANN selected an initial group of seven diverse new generic TLDs (.info,. .biz, .name, .pro, .aero, .museum, and .coop) to be added to the DNS as a proof of concept.
The policy tasks necessary to delegate new gTLDs include the preparation of a request for proposals, the definition of selection criteria, the evaluation of the proposals in light of those criteria, the analysis of any public or expert comments, the selection of registries and registry operators, and the negotiation of registry agreements (including, as appropriate, the documentation of registry policies like pricing, registrar competition, dispute resolution, data escrow, and Whois service).
Following the launch of a new TLD, ICANN is responsible for the monitoring and enforcement of the registry agreement, the implementation of data escrow requirements, and, in most cases, the administration of a registrar accreditation program.
The term "redelegation" refers to a change from one gTLD sponsoring organization or manager to another. Once created, a new gTLD is subject to potential redelegation if: (a) the sponsoring organization or manager voluntarily chooses to abandon the registry; (b) it breaches its registry agreement with ICANN; or (c) the term of the current registry agreement expires.
For example, the registry agreement for the .org TLD calls for the current operator's delegation to terminate by 31 December 2002. ICANN thus must undertake a redelegation process that covers the same basic elements of the delegation process noted above.
On occasion, TLD registries modify one or more of their existing TLD name servers. For example, a gTLD name server might change from one ISP to another, or might decide to improve overall name resolution performance by adding a new name server, or replacing an existing one. These changes involve a change request to the IANA, followed by verification and implementation procedures, according to the terms of the given registry agreement and relevant technical considerations.
4. Monitoring, Enforcement, and Implementation of gTLD Agreements
ICANN is responsible for monitoring and enforcement of the gTLD registry agreements, along with certain operational tasks, including the accreditation of competitive registrars, the implementation of data escrow programs, and the administration of the Uniform Dispute Resolution Policy. Where there are formal agreements for registration accreditation and data escrow, ICANN must also undertake monitoring and enforcement of them, along with any related operational tasks, such as the verification that any registry data escrowed with ICANN is complete and generated in the correct technical format.
As part of monitoring and enforcement, ICANN staff handles complaints about registries and registrars, thus seeking to ensure that the policies embodied in the agreements are being properly implemented (for example, the requirement that registrars provide a free, online, query-based Whois service, which provides contact information for gTLD domain name registrants).
ICANN performs a number of tasks in connection with the administration of dispute resolution policies applicable to the gTLDs with which ICANN has written agreements, such as the Uniform Dispute Resolution Policy (UDRP), sunrise policies, and charter enforcement mechanisms. For example, the UDRP provides a mandatory, non-binding, non-judicial, and relatively inexpensive system for the resolution of claims of abusive, bad-faith cybersquatting. ICANN's responsibilities include the approval of dispute resolution providers and the maintenance of a master database of proceedings.
5. Internationalized Domain Names
As the Internet becomes more accessible to more of the world, and usage by non-English speaking populations increases, the need for some workable system of internationalized domain names also increases. This is both a technical and a policy issue. The technical problem is extremely complex, and is the subject of intense activity at the IETF aimed at the creation of a workable technical standard. The policy issues are similarly complex, as exemplified by the reports of the ICANN IDN Committee available on the ICANN website.
Turning to the country-code TLDs, ICANN is responsible for the DNS zone file administrative functions of ccTLD delegation, ccTLD re-delegation, ccTLD TLD name server changes, and the implementation of ccTLD registry agreements (where completed). ICANN policies for ccTLDs are set forth in ICP-1, which is an updated description of current practices for the implementation of RFC 1591, the 1994 document that sets forth the basic IANA principles and policies for TLD structure and delegation.
The term "country-code TLD" is in fact a bit of a misnomer, as a number of the two-letter TLDs in that category are not countries. Specifically, the term refers to TLDs created on the basis of the ISO 3166-1 table, which is the International Standards Organization's list of countries and geographically distinct territories together with the unique 2- and 3-character abbreviations assigned to each. A more accurate term would be "geographic TLDs," since this class of TLDs is defined by their association with defined geographic units. The ISO 3166-1 table is widely used for a variety of purposes, from currency abbreviations in the world's banking systems and financial markets to the national origin stickers on the backs of automobiles. ICANN relies on the ISO 3166-1 table both for the determination of whether a given country of geographic territory exists and, if so, what two-letter code should be used as its TLD label. By relying on this standard, ICANN keeps itself out of the business of determining what is and is not a country (or geographically distinct territory), and leaves that issue to a politically recognized and expert authority.
To date, 245 ccTLDs have been delegated, leaving only two undelegated codes. Thus, at this point, ICANN's responsibility for ccTLD delegation involves little day-to-day work. The existing undelegated codes - along with any new codes that may be added by the ISO 3166 Maintenance Agency - are available for delegation under the terms set forth in ICP-1 and RFC 1591. Those documents require that a proposed new ccTLD manager demonstrate technical competence, the support of the local Internet community in the country or territory to be served, and a commitment to accept the basic community service and trusteeship responsibilities that lie at the heart of the ccTLD concept.
Far more common than ccTLD delegation matters are requests to ICANN for the re-delegation of already-delegated ccTLD registries. Requests for redelegation are judged according to the same basic criteria as delegation requests, with the focus on technical competence, support from the local Internet community, and commitment to accept the fundamental public service responsibilities that are inherent in ccTLD trusteeship.
The handling of ccTLD redelegation requests requires significant ICANN staff work, for reasons that may not be obvious. In some cases, these requests arrive with the full support of the existing ccTLD manager; more often, however, the requests are submitted without the knowledge or with the open opposition of the current ccTLD manager. In all cases, the requests must be investigated and evaluated against ICANN's published criteria. Under ICP-1, ICANN generally makes re-delegations only with the cooperation of the existing ccTLD manager. Where the manager disagrees with the proposed re-delegation, IANA policy calls upon the disputing parties to engage in cooperative dialogue, together with the local Internet community, until a mutually agreeable solution can be found. Only in cases of intractable conflict or recurrent technical failure by the current manager has the IANA undertaken involuntary redelegations.
For all redelegation requests, IANA policy conducts an evaluation of the views of the local Internet community, seeking input from affected stakeholders and interested parties, including but not limited to governments. This investigation and evaluation function is highly staff-intensive and can lead to significant delays in the processing of re-delegation requests. For major redelegations, ICANN publishes an IANA Report detailing the request, its background, the results of its investigation, and its conclusions.
ICANN is responsible for processing ccTLD name server change requests. As with redelegation requests, TLD name server changes require a surprising amount of staff time and resources. Whenever a ccTLD manager wishes to change one or more of its authoritative primary or secondary name servers in the DNS root zone file, a name server change template must be submitted to ICANN. ICANN reviews the request for completeness, and ensures that the proposed change is consistent with published standards for TLD name servers, such as the requirement that secondaries be placed at dispersed locations on the Internet, to minimize the likelihood of a single failure disabling all of them. ICANN then proceeds to verify the request with the delegated administrative and technical contacts, to make certain that it does not constitute an unauthorized hijacking or stealth relegation of the ccTLD. Once the request has been verified, ICANN tests the new name servers to see that they are functioning properly, and proceeds to promulgate a new DNS root zone file with the updated name server information for the ccTLD.
ICANN maintains an online IANA database of contact information for each ccTLD and gTLD registry, including the identity of the sponsoring organization (meaning designated "trustee" for the ccTLD); the name, physical address, e-mail address, and phone and fax numbers for the delegated administrative and technical contacts; and the URL for registration information. The IANA TLD database is available through online web indices and via port 43 and port 80 Whois queries. ICANN carefully investigates and verifies requested changes to this information to prevent unauthorized hijacking and stealth redelegation in violation of the IANA procedures documented in ICP-1 and RFC 1591.
B. DNS Root Name Server System
ICANN is responsible for coordinating the stable functioning of the DNS root name server system. For top-level resolution of DNS queries, the DNS relies upon 13 geographically distributed root name servers (identified by letters of the alphabet). There are 12 different root name server operators, ranging from universities to military institutions to commercial enterprises to not-for-profit organizations (such as ICANN). All of the root name server operators are independent volunteers, receiving no outside compensation for their services. ICANN is responsible for overall coordination of this system, which includes day-to-day communication on operations and incident response. Through its Root Server System Advisory Committee (RSSAC), which consists of the root name server operators and invited experts, ICANN is also responsible for developing and implementing policies relating to, for example, the distribution, location, and identity of the root name server operators.
In partnership with the root name server operators, ICANN also participates in research, measurement, and testing initiatives aimed at the overall improvement of the DNS root name server system. For example, when planning and implementation testing are complete, ICANN will operate a dedicated primary root name server, a significant security enhancement that will eliminate the need of the root name servers to rely on one of the machines that handles public DNS queries to also provide the authoritative version of the root zone file.
ICANN is the operator of the L root name server, one of the thirteen authoritative DNS root name servers. This responsibility is purely operational and entails a significant allocation of resources to support the necessary technical staffing, hardware, and bandwidth.
ICANN is responsible for a set of Internet services designated by the InterNIC service mark. These include the www.internic.net website, which provides information on the gTLD registries, such as a listing of accredited registrars and FAQs on dispute resolution.
ICANN currently operates the registry for the .int TLD, which is for organizations established by international treaty. Historically, the .int registry was also used for international Internet infrastructure-related uses, such as .ip6.int, which was for a time designated as the location of the reverse delegation tree for IPv6 addresses. In cooperation with the IETF, ICANN is working to transition the infrastructure-related domains away from .int into more appropriate TLDs, for example the new .ip6.arpa.
ICANN is responsible for the global allocation of top-level blocks of IPv4 and IPv6 addresses and blocks of autonomous system (AS) numbers to the recognized regional Internet registries (RIRs), which in turn allocate smaller blocks to ISPs and other local Internet registries within a particular geographic area. Currently, there are three RIRs (APNIC, ARIN, and the RIPE NCC); in the near future, there will likely be two more (LACNIC and AfriNIC). In allocating IPv4 addresses and AS number blocks, ICANN undertakes careful analysis of RIR requests, applying policies of responsible stewardship designed to balance the need for conservation with the principle of availability to all who need them. In addition, ICANN has responsibilities for the higher levels of the DNS reverse delegation tree, and responsibility for maintaining a set of common/technical address spaces, such as the private-use address space.
Through its Address Supporting Organization, and in close cooperation with the regional Internet registries, ICANN is responsible for developing global address policies for IP address and AS number allocation.
ICANN creates, maintains, and disseminates over 120 registries of protocol port and parameter numbers and other protocol identifiers. Through a memorandum of understanding, ICANN has been designated by the Internet Engineering Task Force (IETF) to perform this set of IANA functions. ICANN staff do so as directed by the IETF and documented in the RFC series, taking guidance from the Internet Engineering Steering Group (IESG).
In addition, ICANN is responsible for maintaining the DNS implementation of certain Internet infrastructure-related registries, such as .arpa and the legacy technical .int domains.
Following is an incomplete list of references to documents that define ICANN's operational and policymaking responsibilities.
U.S. Department of Commerce, "Statement of Policy, Management of Internet Names and Addresses," 5 June 1998, 63 Fed. Reg. 31741(1998) (commonly known as the White Paper).
Memorandum of Understanding Between the U.S. Department of Commerce and ICANN, 25 November 1998.
Amendment 2 to ICANN/DOC Memorandum of Understanding, 30 August 2000.
Amendment 3 to ICANN/DOC Memorandum of Understanding, 25 May 2001.
Amendment 4 to ICANN/DOC Memorandum of Understanding, 24 September 2001.
Third Status Report to the U.S. Department of Commerce, 3 July 2001.
Contract Between ICANN and the United States Government for Performance of the IANA Function, 21 March 2001.
J. Postel, "Domain Name System Structure and Delegation," RFC 1591, March 1994.
IANA ccTLD News Memo # 1, 23 October 1997, <>.
"Internet Domain Name Structure and Delegation," ICANN Internet Coordination Policy 1 (ICP-1), May 1999.
Internet Protocol Addresses and Autonomous System Numbers
J. Hawkinson and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
K. Hubbard, et al., "Internet Registry IP Allocation Guidelines," RFC 2050, November 1996.
"Criteria for Establishment of New Regional Internet Registries," ICP-2, June 2001.
"RIR Comparative Policy Overview (version 1.0)".
"European Internet Registry Policies and Procedures", RIPE-185, October 1998.
Guidelines for Requesting IP Addresses and AS Numbers in the ARIN Region.
IETF-ICANN Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority, RFC 2860, 10 March 2000.
T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
S. Bradner and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", RFC 2780, March 2000.
R. Droms, "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", RFC 2939, September 2000.
N. Freed and J. Postel, "IANA Charset Registration Procedures", RFC 2978, October 2000.
Z. Albanna, et al., "IANA Guidelines for IPv4 Multicast Address Assignments", RFC 3171, August 2001.
J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.
Page Updated
10-Mar-2002
©2002 The Internet Corporation for
Assigned Names and Numbers. All rights reserved.