[Federal Register Volume 76, Number 38 (Friday, February 25, 2011)]
[Notices]
[Pages 10569-10571]
From the Federal Register Online via the Government Printing Office [www.gpo.gov]
[FR Doc No: 2011-4240]


-----------------------------------------------------------------------

DEPARTMENT OF COMMERCE

National Telecommunications and Information Administration

[Docket No. 110207099-1099-01]
RIN 0660-XA23


Request for Comments on the Internet Assigned Numbers Authority 
(IANA) Functions

AGENCY: National Telecommunications and Information Administration, 
U.S. Department of Commerce.

ACTION: Notice of Inquiry.

-----------------------------------------------------------------------

SUMMARY: The United States Department of Commerce's National 
Telecommunications and Information Administration (NTIA) remains 
committed to preserving a stable and secure Internet Domain Name System 
(DNS). Critical to the DNS is the continued performance of the Internet 
Assigned Numbers Authority (IANA) functions. The IANA functions have 
historically included: (1) The coordination of the assignment of 
technical Internet protocol parameters; (2) the administration of 
certain responsibilities associated with Internet DNS root zone 
management; (3) the allocation of Internet numbering resources; and (4) 
other services related to the management of the .ARPA and .INT top-
level domains. The Internet Corporation for Assigned Names and Numbers 
(ICANN) currently performs the IANA functions, on behalf of the United 
States Government, through a contract with NTIA. Given the September 
30, 2011 expiration of this contract, NTIA is seeking public comment to 
enhance the performance of the IANA functions in the development and 
award of a new IANA functions contract.

DATES: Comments are due on or before March 31, 2011.

ADDRESSES: Written comments may be submitted by mail to Fiona M. 
Alexander, Associate Administrator, Office of International Affairs, 
National Telecommunications and Information Administration, 1401 
Constitution Avenue, NW., Room 4701, Washington, DC 20230. Paper 
submissions should include a three and one-half inch computer diskette 
in HTML, ASCII, Word or WordPerfect format (please specify version). 
Diskettes should be labeled with the name and organizational 
affiliation of the filer, and the name of the word processing program 
used to create the document. Alternatively, comments may be submitted 
electronically to IANAFunctions@ntia.doc.gov. Comments provided via 
electronic mail should also be submitted in one or more of the formats 
specified above. Comments will be posted to NTIA's Web site at http://www.ntia.doc.gov/ntiahome/domainname/IANAFunctions.html.

FOR FURTHER INFORMATION CONTACT: For questions about this Notice 
contact: Vernita D. Harris, National Telecommunications and Information 
Administration, U.S. Department of Commerce, 1401 Constitution Avenue, 
NW., Room 4701, Washington, DC 20230; telephone: (202) 482-4686; e-
mail: vharris@ntia.doc.gov. Please direct media inquiries to the Office 
of Public Affairs, NTIA, at (202) 482-7002.

SUPPLEMENTARY INFORMATION: The Internet Assigned Numbers Authority 
(IANA) functions were initially performed under a series of contracts 
between the Department of Defense's Advanced Research Projects Agency 
(DARPA) and the University of Southern California (USC), as part of a 
research project known as the Terranode Network Technology (TNT). As 
the TNT project and the DARPA/USC contract neared completion, the 
United States Government recognized the need for the continued 
performance of the IANA functions as vital to the stability and correct 
functioning of the Internet. In January 1999, NTIA initiated a 
procurement process to fulfill this need.\1\ NTIA awarded the IANA 
functions contract to ICANN in February 2000, and subsequently in March 
2001, March 2004, and August 2005.\2\ The current contract expires 
September 30, 2011.\3\ Given this impending expiration, NTIA is issuing 
this Notice of Inquiry (NOI) to seek public comment to inform the 
procurement process, leading to the award of a new IANA functions 
contract. We take this opportunity to ask a detailed set of questions 
on this topic as this is the first time NTIA has undertaken a 
comprehensive review of the IANA functions contract since the award of 
the first contract in 2000.
---------------------------------------------------------------------------

    \1\ To assist in this transition from the DARPA contract with 
USC to ICANN, in 1998, ICANN entered into an agreement with the 
University of Southern California Information Sciences Institute 
(USC/ISI) to transition certain functions, responsibilities, assets, 
and personnel to ICANN.
    \2\ Each contract and modifications are available at http://www.ntia.doc.gov/ntiahome/domainname/iana.htm.
    \3\ The current contract has an option to extend the performance 
period for an additional six months. If necessary, NTIA will 
exercise this option in order to complete the contract procurement 
process. See Contract Clause 1.5 of the current contract, which can 
be viewed at http://www.ntia.doc.gov/ntiahome/domainname/iana/ianacontract_081406.pdf.
---------------------------------------------------------------------------

    The domain name system (DNS) is a critical component of the 
Internet that works like an address book, allowing users to reach 
websites using easy-to-understand domain names (e.g., http://commerce.gov) rather than the numeric network server addresses (e.g., 
http://170.110.225.168) necessary to retrieve information on the 
Internet. It is a hierarchical and globally distributed system in which 
distinct servers maintain the detailed information for their local 
domains and pointers for how to navigate the hierarchy to retrieve 
information from other domains. The accuracy, integrity, and 
availability of the information supplied by the DNS are essential to 
the operation of most systems, services, or applications that use the 
Internet.
    Essential to the DNS is the performance of the IANA functions. At a 
summary level, the IANA functions include: (1) The coordination of the 
assignment of technical Internet protocol parameters; (2) the 
administration of certain responsibilities associated with Internet DNS 
root zone management; (3) the allocation of Internet numbering 
resources; and (4) other services related to the management of the 
.ARPA and .INT top-level domains. A more detailed description of each 
of the IANA functions follows.
    The first of the IANA functions is the coordination of the 
assignment of technical protocol parameters. This function includes the 
review and assignment of unique values to numerous parameters (e.g., 
operation codes, port numbers, object identifiers, protocol numbers) 
used in various Internet protocols. This function also includes 
dissemination of listings of assigned parameters through various means 
(including on-line publication) and the review of technical documents 
for consistency with assigned values.

[[Page 10570]]

    The second function is the administration of certain 
responsibilities associated with Internet DNS root zone management. It 
includes receiving requests for and making routine updates of the top-
level domain contact, nameserver and DS record information. This 
function also includes receiving delegation and redelegation requests, 
investigating the circumstances pertinent to those requests, and making 
recommendations and reporting actions undertaken in connection with 
processing requests.\4\ Additionally, this function involves certain 
responsibilities related to DNSSEC operation at the root, including 
management of the root zone Key Signing Key (KSK).\5\
---------------------------------------------------------------------------

    \4\ Performance of this function in relation to country code top 
level domains (ccTLDs) has evolved over time to address specific 
issues, one of which has been how best to respect the legitimate 
interests of governments in the management of their respective ccTLD 
within the current model.
    \5\ At present, the process flow for root zone management (see 
diagram at http://www.ntia.doc.gov/DNS/CurrentProcessFlow.pdf) 
involves three roles that are performed by different entities 
through two separate legal agreements with NTIA. The process itself 
includes the following steps: (1) TLD operators submit change 
requests to the IANA Functions Operator; (2) the IANA Functions 
Operator processes the request and conducts due diligence in 
verifying the request; (3) the IANA Functions Operator sends a 
recommendation regarding the request to the Administrator for 
verification/authorization; (4) the Administrator verifies that the 
IANA Functions Operator has followed its agreed upon verification/
processing policies and procedures; (5) the Administrator authorizes 
the Root Zone Maintainer to make the change; (6) the Root Zone 
Maintainer edits and generates the updated root zone file; and (7) 
the Root Zone Maintainer distributes the updated root zone file to 
the thirteen (13) root server operators. Currently, ICANN performs 
the role of the IANA Functions Operator, NTIA performs the role of 
Administrator, and VeriSign performs the role of Root Zone 
Maintainer. NTIA's agreements with ICANN (IANA functions contract) 
and VeriSign, Inc. (Cooperative Agreement) provide the process 
through which changes are currently made to the authoritative root 
zone file.
---------------------------------------------------------------------------

    The third function involves responsibilities for allocated and 
unallocated IPv4 and IPv6 address space and Autonomous System Number 
(ASN) space, including the delegation of IP address blocks to Regional 
Internet Registries (RIRs) for routine allocation. This function also 
includes reservation and direct allocation of space for special 
purposes, such as multicast addressing, addresses for private networks 
and globally specified applications.
    Other services related to the performance of the IANA functions 
include the management of .ARPA and .INT top-level domains.
    The responsibilities encompassed within the IANA functions require 
cooperation and coordination with a variety of technical groups and 
stakeholder communities. For example, protocol parameters are developed 
through and overseen by groups such as the Internet Engineering Task 
Force (IETF) and the Internet Architecture Board (IAB), policies and 
procedures associated with Internet DNS root zone management are 
developed by a variety of actors (e.g., the Internet technical 
community, ccTLD operators, and governments) and continue to evolve, 
and policies and procedures related to Internet numbering resources are 
developed within the RIRs. NTIA is cognizant and respectful of the 
policy and technical standards development roles these organizations, 
their constituencies, and other relevant Internet community 
stakeholders play.
    NTIA recognizes that the IANA Functions Operator, in the 
performance of its duties, requires close constructive working 
relationships with interested and affected parties if it is to ensure 
quality performance of the IANA functions. Applicable to each of these 
functions and their performance are relevant policies, technical 
standards, and procedures developed and administered outside the 
purview of the IANA functions contract.
    Given the importance of the Internet as a global medium supporting 
economic growth and innovation, continuing to preserve the security and 
stability of the Internet DNS remains a top priority for NTIA. This is 
a shared responsibility among all stakeholders in the Internet 
community. Currently, the IANA Functions Operator is required to 
operate computing and communications systems in accordance with best 
business and security practices. This includes utilizing authenticated 
communications between it and its customers. The IANA Functions 
Operator is also required to submit annually an IANA functions 
information security plan. The annual plan addresses controls that the 
IANA Functions Operator has employed to ensure the confidentiality, 
integrity and availability of the IANA functions processes and 
information assets. Additionally, the IANA Functions Operator is 
required to submit monthly performance reports. The monthly reports 
contain statistical and narrative information on the performance of the 
IANA functions (i.e., assignment of technical protocol parameters; 
administrative functions associated with root zone management; and 
allocation of internet numbering resources) for the previous 30 
days.\6\
---------------------------------------------------------------------------

    \6\ For reports on IANA functions activities see: http://www.iana.org/reports and https://charts.icann.org/public/index-iana-main.html.
---------------------------------------------------------------------------

    Request for Comment: The current IANA functions contract will 
expire on September 30, 2011. Given the impending expiration of this 
contract, NTIA is seeking public comment to enhance the performance of 
the IANA functions. These comments will be considered in the 
procurement process to award a new IANA functions contract.
    Comments that contain references, studies, research, and other 
empirical data that are not widely published should include copies of 
the referenced materials with the submitted comments.
    1. The IANA functions have been viewed historically as a set of 
interdependent technical functions and accordingly performed together 
by a single entity. In light of technology changes and market 
developments, should the IANA functions continue to be treated as 
interdependent? For example, does the coordination of the assignment of 
technical protocol parameters need to be done by the same entity that 
administers certain responsibilities associated with root zone 
management? Please provide specific information to support why or why 
not, taking into account security and stability issues.
    2. The performance of the IANA functions often relies upon the 
policies and procedures developed by a variety of entities within the 
Internet technical community such as the IETF, the RIRs and ccTLD 
operators. Should the IANA functions contract include references to 
these entities, the policies they develop and instructions that the 
contractor follow the policies? Please provide specific information as 
to why or why not. If yes, please provide language you believe 
accurately captures these relationships.
    3. Cognizant of concerns previously raised by some governments and 
ccTLD operators and the need to ensure the stability of and security of 
the DNS, are there changes that could be made to how root zone 
management requests for ccTLDs are processed? Please provide specific 
information as to why or why not. If yes, please provide specific 
suggestions.
    4. Broad performance metrics and reporting are currently required 
under the contract.\7\ Are the current metrics and reporting 
requirements sufficient? Please provide specific information as to why 
or why not. If not, what specific changes should be made?
---------------------------------------------------------------------------

    \7\ See Appendix A and Appendix B of the current contract, which 
can be viewed at http://www.ntia.doc.gov/ntiahome/domainname/iana/ianacontract_081406.pdf.
---------------------------------------------------------------------------

    5. Can process improvements or performance enhancements be made to

[[Page 10571]]

the IANA functions contract to better reflect the needs of users of the 
IANA functions to improve the overall customer experience? Should 
mechanisms be employed to provide formalized user input and/or 
feedback, outreach and coordination with the users of the IANA 
functions? Is additional information related to the performance and 
administration of the IANA functions needed in the interest of more 
transparency? Please provide specific information as to why or why not. 
If yes, please provide specific suggestions.
    6. Should additional security considerations and/or enhancements be 
factored into requirements for the performance of the IANA functions? 
Please provide specific information as to why or why not. If additional 
security considerations should be included, please provide specific 
suggestions.

    Dated: February 22, 2011.
Lawrence E. Strickling,
Assistant Secretary for Communications and Information.
[FR Doc. 2011-4240 Filed 2-24-11; 8:45 am]
BILLING CODE 3510-60-P