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 email@example.com (Forum closed 18 August 2003).
Committee on ICANN Evolution and Reform
6 May 2002
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;
- Protocol port and parameter numbers.
2. Coordinates the operation and evolution of the DNS's root name server
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
[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
[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.
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)
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
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
- 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.
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:
- 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
- "Criteria for Establishment of New Regional
Internet Registries," ICP-2, June 2001.
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:
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,
- 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,
- J. Reynolds, "Assigned
Numbers: RFC 1700 is Replaced by an On-line Database,"
RFC 3232, January 2002.
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
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,
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
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,
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
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
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.
Questions concerning the layout, construction and functionality
of this site
should be sent to firstname.lastname@example.org.
©2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.