ICANN Logo

Working Paper on ICANN Mission and Core Values
Posted: 6 May 2002

Committee on ICANN Evolution and Reform
Working Paper on ICANN Mission and Core Values

In an effort to advance the community discussions on ICANN evolution and reform that are now ongoing, we offer the following working paper on ICANN's mission and core values for further discussion. These are not conclusions, so these thoughts may or may not actually form the basis of specific recommendations to the Board or the community as a whole. We hope they do provide a platform for more detailed discussion by the community in the next few weeks. The most useful comments will be those received by 17 May 2002.

We invite the community to send comments on this working paper to reform-comments@icann.org (Forum closed 18 August 2003).


Committee on ICANN Evolution and Reform
6 May 2002

ICANN Mission Statement

The Internet Corporation for Assigned Names and Numbers (ICANN) is the private-sector body responsible for coordinating the global Internet's systems of unique identifiers.

The mission of ICANN is to coordinate the stable operation of the Internet's unique identifier systems. In particular, ICANN:

1. Coordinates the allocation and assignment of three sets of unique identifiers for the Internet:

  • Domain names (forming a system referred to as "DNS");
  • Internet protocol (IP) addresses and autonomous system (AS) numbers; and
  • Protocol port and parameter numbers.

2. Coordinates the operation and evolution of the DNS's root name server system.

ICANN Core Values

In performing its mission, ICANN adheres to these core values and principles:

[a]. Preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet.

[b]. Respect the creativity and innovation made possible by the Internet by limiting ICANN's activities to those matters within ICANN's mission requiring or significantly benefiting from global coordination.

[c]. To the extent feasible, delegate coordination functions to responsible entities that reflect the interests of affected parties.

[d]. Promote international participation at all levels of decision-making and policy-making.

[e]. Seek broad, informed participation reflecting the functional and geographic diversity of the Internet.

[f]. Introduce and promote competition in the registration of domain names where practicable and beneficial.

[g]. Where feasible, depend on market mechanisms to promote and sustain a competitive environment.

[h]. Employ open and transparent policy-making mechanisms that promote well-informed, technically sound decisions.

[i]. Make allocation and assignment decisions by applying documented policies neutrally and objectively.

[j]. Act with a speed that is responsive to the needs of the Internet but obtain informed input from those most affected as part of the decision-making process.

[k]. Remain accountable to the Internet community though mechanisms that enhance ICANN's effectiveness.

[l]. While remaining rooted in the private sector, act with sensitivity to governmental concerns for the public interest so that the need for direct governmental action is minimized.

Implications of the ICANN Mission Statement

A question that is often raised in the ICANN reform process is: To what extent can ICANN extract itself from policy issues, limiting itself instead to administrative technical functions? The question reflects a near-universal recognition that the organization's mission should dictate ICANN's structure and way of functioning, that is, ICANN's structure should assist it in performing its mission. The structure and operation should likewise inspire confidence in ICANN among the communities of the global Internet.

The heart of the debate over ICANN's structure, then, lies in the scope of its policy-making role: the more that ICANN's mission entails policy-making, the greater the perceived need for mechanisms of public participation and accountability. And conversely: the more that ICANN's policy-making role is limited and constrained, the less significant those needs are.

Some have argued that the key to reforming ICANN's structure lies in redefining its mission so as to eliminate policy-making from its assigned responsibilities. This argument holds a great deal of appeal on the surface. However, a fair assessment of ICANN's actual responsibilities demonstrates that, though fundamentally technical in nature, the organization's mission inherently and inescapably necessitates a limited role in non-technical policy-making. Policy-making responsibilities cannot be eliminated; they can only be shifted or subcontracted to some other institution, as already takes place in significant areas, as seen by delegations of various kinds of policy-making responsibility to RIRs, sponsors of specialized generic top-level domains (gTLDs), and country-code top-level domain (ccTLD) managers.

A more useful set of questions, then, is: To what extent are ICANN's policy-making functions limited to well-defined areas, consistent with its mission and circumscribed by principles of objectivity and neutrality, and/or subjected to public scrutiny and review? Should any current ICANN functions be shifted to other appropriate (i.e. legitimate and accountable) institutions?

This paper seeks to shed light on these questions by analyzing the connections between ICANN's mission and its practical responsibilities.

1. Sources of ICANN's Mission

Performing ICANN's mission necessarily entails a recourse to policy. Many of ICANN's substantive actions in technical coordination present choices that can have far-reaching consequences. Conversely, policy decisions very often have technical implications. To avoid or limit the possible arbitrariness of such actions, they need to be based on explicit, publicly understood policies. A key strength of ICANN is that it creates policies through open, participatory processes based on community involvement. Although many organizational units and staff may be involved in the process of policy development, the ICANN governing Board (now the Board of Directors) makes ultimate decisions on the acceptance or modification of policies. Many policies needed to support ICANN's operations must respond to the non-technical implications of decisions made by ICANN; this requires a Board composed of individuals well-qualified to respond to these broader challenges.

This confluence of technical function and the broader policy and societal effects of those technical functions, with the need for an inbuilt policy-making process, has clearly been recognized and discussed since the first steps toward the establishment of ICANN began. In fact, this inevitable confluence of technical coordination and related policy development is what galvanized individuals, institutions, and organizations of the academic, governmental, business, and many other sectors to work to establish a broadly inclusive ICANN framework. In this sense, there is nothing new in stating that ICANN must act within a policy-making environment.

ICANN's mission (see the draft Mission Statement) encompasses the functions historically clustered together as the Internet Assigned Numbers Authority (IANA). The IANA functions, which have been performed by ICANN since 1998, derive from two principal sources: (1) the United States government, which funded the IANA prior to the creation of ICANN, and (2) the Internet Engineering Task Force (IETF) the vehicle through which the underlying Internet standards (including the Internet Protocol and the Domain Name System) were developed.

The various components of ICANN's overall mission are documented in the following:

The following documents detail the scope of ICANN's mission relating to the DNS top-level domains:

The following documents detail the scope of ICANN's mission relating to the allocation of IP addresses and autonomous system (AS) numbers:

Among numerous other relevant RFCs, the following documents describe the scope of ICANN's mission relating to the operation of protocol port and parameter registries on behalf of the IETF:

Of these, the most important for understanding the sources and scope of ICANN's mission are the White Paper, the ICANN/US government Memorandum of Understanding, as amended, the IANA contract, and the IETF-ICANN MoU.

2. Policy-Making Is Inherent in ICANN's Responsibilities

ICANN's four general areas of coordination responsibility (allocation and assignment of Internet domain names, IP addresses, protocol numbers, and coordination of the DNS root name server system) necessitate varying degrees of policy making. In some cases (such as protocol-number assignment, where IETF guidance is authoritative), an established policy framework comprehensively guides the performance of the IANA function. At the other end of the range (such as DNS root-zone file management) questions frequently arise requiring the development of new policy or elaboration of existing policy. (For a detailed account of ICANN's current specific responsibilities, see "What ICANN Does.")

a. IP addresses and AS numbers

In the area of IP address and AS number allocation, ICANN's policy-making responsibility extends only to global addressing policies. Each regional Internet registry (or lower-level Internet registry) fashions its own local IP address and AS number allocation and assignment policies. The need for global addressing policy derives from the fact that all regional and lower-level Internet registries allocate and assign numbering resources from the same three address spaces (IPv4, IPv6, and AS numbers). The IANA has highest-level responsibility for these numbering spaces and allocates them in large blocks to regional Internet registries according to their established needs. The IANA's coordination of allocations is essential to preserve Internet-wide uniqueness, and adherence by both the IANA and Internet registries at all levels to global addressing policy ensures that allocations and assignments are made in keeping with goals of global concern such as conservation, routability, and accurate registration. Existing global addressing policies were developed and refined over the past decade and beyond, and most recently documented in RFC 2050. Any changes (for example, in response to new Internet protocols or technologies) of global concern must be coordinated across all Internet registries at all levels. Under ICANN's procedures, global addressing policies are assessed and developed through its Address Supporting Organization, which employs the bottom-up, participatory structures supported by each existing regional Internet registry.

b. Internet Domain Names

For the DNS, ICANN's responsibilities include both technical and non-technical policy functions. Both derive from the IANA's longstanding responsibility for the "overall coordination and management of the Domain Name System (DNS), and especially the delegation of portions of the name space called top-level domains" (RFC 1591), which includes its role as manager of the DNS root-zone file. The root-zone is the Internet's authoritative index of DNS top-level domains, including the two-letter ccTLD registries and the three-or-more-letter gTLD registries. In the present architecture of the DNS and its foreseeable evolution, the uniqueness of identifiers is based on the hierarchical nature of the DNS. Therefore ICANN's policies for domain names appropriately recognize the need of central coordination, while at the same time seeking to delegate those issues that do not require central coordination to responsible organizations that reflect the interests of affected parties. The decentralized nature of the DNS database allows for the delegation of large spheres of policy-making responsibility, e.g., in the operation of the DNS within geographically constrained areas, as long as the uniqueness of identifiers and other aspects pertinent to the global interoperability of the Internet are guaranteed.

The historic preference for delegation of responsibilities for policies primarily of TLD-specific concern is exemplified by the IANA's historic practice of delegating to ccTLD managers the responsibility for establishing registration criteria, pricing, dispute resolution, business models, and mechanisms for local community participation and policymaking. Subject to the need to shift to another manager where accountability to the local Internet community has been lost, the IANA's ccTLD practices help ensure that decisions are made in a way that best reflects the community's interests. More recently, the historic preference for sensible delegation of responsibilities is reflected in the express delegations of policy-making responsibility to the sponsors of special-purpose gTLDs .aero, .coop, and .museum.

By contrast, ICANN plays a more direct and significant role in establishing whatever registry-level policies are deemed appropriate in accordance with ICANN's mission for the general-purpose gTLDs, such as .com, .net, .org, .info, .name, and .biz, that operate without sponsors. In effect, ICANN serves as the global Internet community's open policy-making forum for the unsponsored gTLD registries.

Affecting both ccTLDs and gTLDs, the management of the DNS root-zone file also entails complex technical policy decisions that may arise from the implementation of evolving new protocols, such as the DNS Security and Internationalized Domain Name protocol suites. Some of these decisions also have wide-ranging non-technical policy implications and requirements which must be considered.

Though some of ICANN's registry-level gTLD policies are non-technical in nature, all relate directly to ICANN's mission to coordinate the assignment of unique identifiers to ensure stable functioning of these systems. For example, the need for dispute resolution mechanisms in the gTLDs flows from the problem of unique assignment: it is the assigned domain name string itself that is at issue. (Many ccTLDs have chosen to implement dispute resolution mechanisms for the same reasons.) Similarly, mandated registrar competition relates directly to the ability of the gTLD registry to serve the needs of domain name holders – at least until and if registry competition itself would meet that objective. By contrast, disputes over the content of an e-mail message, ftp file, or web page bear no inherent relation to the assigned domain name, and therefore fall outside the scope of ICANN's policy-making scope. ICANN therefore does not base its policies on the content served by websites, contained in e-mail messages, or otherwise accessed by domain names.

Decisions about how and when new TLDs will be placed in the root, and who will operate them, are not only technical in nature, but are inextricably linked to the technical act of actually managing the root-zone file. Thus, those decisions are appropriately made on a global basis, and should logically be made in conjunction with the technical coordination responsibilities of ICANN. These decisions could theoretically be made by some other entity, but it is not obvious why that would be desirable, effective, efficient, or optimal.

Insertion of a new TLD into the root or redelegation of an old TLD necessarily involves answers to the questions of what TLDs, who should operate the associated registries, what restrictions if any should be placed on those TLDs and registries, when and for how long should the right to operate be delegated, who should have the authority to determine when change should or should not occur, how should technical and other performance criteria be assessed, etc. And cutting across these questions is what should be predefined, what should be left to the marketplace, and what degree of decision enforcement is required. All of this takes place within the framework of preserving the stability of the Internet, and also is related to other core ICANN values such as competition and internationalization.

These are all inescapable policy questions that must be addressed in the course of managing the root-zone file. Some suggest these questions should be addressed by one or more other organizations, and that ICANN should essentially be limited to the technical implementation of decisions by those other organizations. It is unclear what is to be gained from such fragmentation involving, as it inevitably will, more administrative overhead and coordination complexity, and potential collision of policy decisions in the absence of a single coordinating body. In the end, splitting ICANN along functional division lines will again give rise to the need of a new coordinating body for the separate components. It would likely just replicate the contentious milieu that characterizes much of ICANN, that is, it will distribute and multiply the issues, not solve them. Undoubtedly, ICANN can and should continue to delegate coordination responsibilities to appropriate organizations whenever it is sensible to do so; the preference should be to decentralize whenever that is consistent with ICANN's mission. Ultimately, however, there must be a single body to coordinate root policy-making and the other technical functions, even if it does so by respecting the decisions on certain matters that are delegated to others. If this single body is not ICANN (reformed if necessary) then who? The US Government? An international treaty organization?

c. Protocol Numbers

In the area of protocol numbering, ICANN follows a long-established, and easily implemented policy: it simply administers the registries of parameter and protocol values according to the guidance developed by the "creator" of the particular registry involved, in nearly all cases the Internet Engineering Steering Group (IESG) and the Internet Architecture Board (IAB).

d. DNS Root Name Server System

ICANN is responsible for coordinating the stable functioning of the DNS root name server system, including policy-oriented as well as technical and operational tasks. For top-level resolution of DNS queries, the DNS currently 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. The root name server operators are volunteers, receiving no outside compensation for their services.

The proper functioning of the DNS requires that the root name server operators perform their responsibilities in close collaboration. The ICANN Root Server System Advisory Committee (RSSAC), which consists of the 12 root name server operators and invited experts, facilitates the coordination of the development and implementation of policies relating to, for example, the distribution and location of the root name servers, and the implementation of improved architectures and protocols. Historically, the root server operators themselves have carried out the bulk of the coordinated activity needed to insure stable operation of the root server system.

These policy decisions include inextricably interrelated technical and non-technical components. They require central coordination. Even a decision to continue the status quo in the operation of the root name servers is a central policy decision taken, perhaps, because the strength in diversity outweighs other considerations. Again, it is not intuitively obvious why some other entity would be better suited to undertake these tasks than is ICANN.

3. Implications for ICANN Structure and Reform

The foregoing discussion is meant to highlight several points: (a) certain core aspects of ICANN's mission inherently and unavoidably entail non-technical policy-making; (b) the extent of ICANN's policy-making role varies considerably among the sets of identifiers within the scope of its mission; (c) ICANN's policy-making responsibilities are (and should be) limited to areas of appropriate global responsibility; and (d) those global policy-making functions cannot be eliminated entirely – they must be carried out by ICANN or by some other entity.

Flowing from these observations about ICANN's mission are some implications for the reform of ICANN's structure.

First, when ICANN's mission and responsibilities are examined closely, it is difficult to identify areas of current ICANN policy-making that do not fall within the above description, and thus are not appropriate responsibilities of ICANN. At best, it is possible to identify policy-making functions that could theoretically be shifted to another entity. For example, it would be possible to shift ICANN's responsibility for ccTLD delegation and re-delegation to the United States government or an international treaty organization such as the United Nations. In each case, however, that entity would necessarily have the same need to evaluate requests for ccTLD redelegation; rather than being performed by ICANN as part of the IANA functions, those tasks would simply be performed by a different entity. In the 1990s, a situation as described here provoked an outcry of the international community that essentially makes this approach infeasible, both in principle and practice, at present and for the foreseeable future. And should such a separation occur, there would be need to coordinate technical policy with the other entity to assure that, as a whole, the DNS mechanisms are globally sound and consistent.

Second, ICANN should continue to limit its policy-making activities to only those areas where global coordination or policy-making is both related to its core mission and appropriately done on a global basis. This conclusion acknowledges that ICANN will function best if it respects the roles of appropriately accountable partner organizations, such as the regional Internet registries, the IETF, the DNS root name server operators, and ccTLD and sponsored gTLD organizations.

Third, ICANN's policy-making structure should be tailored to be proportionate to the scope of its policy-making activities as to each particular identifier space within the scope of its mission.

For example, no separate policy-making mechanism is required for the IANA protocol port and parameter registry functions, because ICANN's role is strictly administrative, subject to the guidance of the IETF. In essence, the IETF serves as the policy-making mechanism for those functions, and in performing the IANA function ICANN defers to the policies that result. By contrast, ICANN itself serves as the global policy forum for the unsponsored gTLDs, in keeping with its necessarily broader role with those registries. In between these two outliers fall the coordination of global policy-making for sponsored gTLD registries, ccTLD registries, and IP address allocation.

Fourth, the mechanisms of policy-making for each identifier space should, where sensible, be kept separate and distinct from the others. This means that the ICANN structure should accommodate tailoring of the policy-development channel for each of the following:

  • Unsponsored gTLD registries
  • Sponsored gTLD registries
  • ccTLD registries
  • IP addressing and AS numbers
  • Protocol port and parameter registries
  • DNS root name servers

With its three supporting organizations and RSSAC, the current ICANN structure does, in fact, attempt to recognize divisions of this type. ICANN's very different posture with regard to unsponsored gTLDs, sponsored gTLDs, and ccTLDs, however, counsels in favor of separately analyzing the appropriate policy-making mechanisms for each.

Similarly, because of the differences in ICANN's policy-making responsibilities concerning IP address and protocol number coordination, a single policy-making channel for these two activities may not be appropriate. A related implication is that protocol port and parameter registries must be handled in a way that recognizes that the IETF alone, and not the other members of the current Protocol Supporting Organization, determines policies for those registries.

Fifth, certain of ICANN's responsibilities cut across all of ICANN's areas of responsibility, necessitating some mechanism of cross-organizational coordination. A good example is security, which is handled in the current ICANN framework by an advisory committee charged with analyzing security risks across the Internet's naming and address allocation systems, and recommending coordinated responses.

Sixth, while a well-tailored structure and well-defined mission are crucial for ICANN to succeed, neither is alone adequate to guarantee that ICANN stays within its assigned global policy-making boundaries. No matter how thoughtful the structure, a policy-making process will encounter new demands for new policies in new areas. No matter how carefully drafted, a written statement of mission will inevitably harbor gray zones. Reliance on structure and a mission statement must be tempered with thoughtful attention to the human element. The ICANN Board and its councils and committees must be populated with high-quality individuals capable of understanding the problems that arise and of applying good and broadly approved judgment to assess potential solutions, while respecting the procedural channels of ICANN's structure and the substantive limits of ICANN's mission. It is important that members of the ICANN Board be able to reach agreements among themselves, look for a benefit more general than the specific constituencies they may work with in their daily operations, and communicate effectively both to obtain input and to explain the results of their deliberations.

Click here to read comments on this working paper.

Questions concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 20-Aug-2003
©2002 The Internet Corporation for Assigned Names and Numbers. All rights reserved.