[ga] FYI: Staff Draft towards Mission Statement

[Alexander Svensson <alexander@svensson.de>]

FYI -- please don't respond with full quotes!
Best regards,
/// Alexander

ICANN Staff Draft: Toward a Statement of the ICANN Mission (7 March 2002)
http://www.icann.org/general/toward-mission-statement-07mar02.htm


[...]

What ICANN Does
Staff Draft - 7 March 2002

OVERVIEW

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 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. 

Operations

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.

Security

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. 

Policymaking

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.


I. NAMES

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.

A. DNS Root Zone File

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.

1. gTLD Delegation

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.

2. gTLD Re-Delegation

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.

3. gTLD Name Server Changes

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 and implementation of data 
escrow programs. 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).

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.

6. ccTLD Delegation

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.

7. ccTLD Re-Delegation

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. 

8. ccTLD Name Server Changes

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 both 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.

9. IANA ccTLD Database

ICANN maintains an online IANA database of contact information for each 
ccTLD 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. 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, ICANN is also responsible for 
developing and implementing policies relating to, for example, the 
distribution, location, and identity of the root name server operators.
ICANN also supports 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 also supporting research into the use of IP addressing protocols that 
would allow for a greater number of root name server machines without 
requiring disruptive changes to the existing framework.

C. L Root Name Server

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.

D. InterNIC Service

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.

E. .int Registry

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.


II. ADDRESSES

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.


III. PROTOCOLS

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.

[...]

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html