[Federal Register Volume 76, Number 114 (Tuesday, June 14, 2011)]
[Notices]
[Pages 34658-34667]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2011-14762]


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

DEPARTMENT OF COMMERCE

National Telecommunications and Information Administration

[Docket No. 110207099-1319-02]
[RIN 0660-XA23]


The Internet Assigned Numbers Authority (IANA) Functions

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

ACTION: Further Notice of Inquiry.

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

[[Page 34659]]

SUMMARY: Critical to the Internet Domain Name System (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 (TLDs). 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 United States Department of Commerce's National 
Telecommunications and Information Administration (NTIA). On February 
25, 2011, NTIA released a Notice of Inquiry (NOI) to obtain public 
comment on enhancing the performance of the IANA functions. NTIA 
received comments from a range of stakeholders: Governments, private 
sector entities, and individuals. After careful consideration of the 
record, NTIA is now seeking public comment through a Further Notice of 
Inquiry (FNOI) on a draft statement of work (Draft SOW), a key element 
of the procurement process for the new IANA functions contract.

DATES: Comments are due on or before July 29, 2011.

ADDRESSES: Written comments may be submitted by mail to Fiona M. 
Alexander, Associate Administrator, Office of International Affairs, 
National Telecommunications and Information Administration, U.S. 
Department of Commerce, 1401 Constitution Avenue, NW., Room 4701, 
Washington, DC 20230. Comments may be submitted electronically to 
[email protected]. Comments provided via electronic mail 
should be submitted in a text searchable format using one of the 
following: PDF print-to-PDF format, and not in a scanned format, HTML, 
ASCII, MSWord or WordPerfect format (please specify version). Comments 
will be posted to NTIA's Web site at http://www.ntia.doc.gov/ntiahome/domainname/IANAFunctionsFNOI.html.

FOR FURTHER INFORMATION CONTACT: For questions about this FNOI contact: 
Vernita D. Harris, Deputy Associate Administrator, Office of 
International Affairs, 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: [email protected]. Please direct media inquiries to the Office 
of Public Affairs, NTIA, at (202) 482-7002.

SUPPLEMENTARY INFORMATION: Critical to the Internet DNS is the 
continued performance of the 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 TLDs. 
ICANN currently performs the IANA functions, on behalf of the United 
States Government, through a contract with NTIA. The current contract 
is set to expire on September 30, 2011.\1\
---------------------------------------------------------------------------

    \1\ 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. The current contract is available on NTIA's Web site at 
http://www.ntia.doc.gov/ntiahome/domainname/iana.htm.
---------------------------------------------------------------------------

    NTIA issued an NOI on February 25, 2011, seeking public comment to 
inform the procurement process leading to the award of a new IANA 
functions contract.\2\ The NOI requested comments on a detailed set of 
questions related to enhancing the performance of the IANA functions. 
The NOI represented the first comprehensive review of the IANA 
functions contract since the award of the initial contract in 2000.
---------------------------------------------------------------------------

    \2\ Notice of Inquiry, Request for Comments on the Internet 
Assigned Numbers Authority (IANA) Functions, 76 FR 10569 (Feb. 25, 
2011), available at http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf.
---------------------------------------------------------------------------

Comment Summary and Policy Discussion

    NTIA received over 80 comments in response to the NOI.\3\ This 
summary identifies key issues and themes raised in the docket and 
frames a draft statement of work for which we seek comment in this 
notice. The following summary does not intend to respond to all the 
comments received in response to the NOI. To the extent that NTIA has 
included specific language in the Draft SOW to address a comment, NTIA 
provides a brief explanation of its policy rationale.
---------------------------------------------------------------------------

    \3\ The comments in their entirety are available for review on 
the NTIA's Web site at http://www.ntia.doc.gov/comments/110207099-1099-01/.
---------------------------------------------------------------------------

General Comments

    Some commenters stated that the IANA functions are performed for 
the benefit of the global Internet community and therefore 
accountability, transparency, and trust are required.\4\ While not 
specific to the questions asked in the NOI, most commenters stated 
their support for multi-stakeholder, private sector-led technical 
coordination of the DNS.\5\
---------------------------------------------------------------------------

    \4\ See e.g., Cisco Comments at 2 (March 28, 2011), available at 
http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/Cisco.pdf; ictQatar Comments at 1 (March 30, 2011), available at 
http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=D5E26B75-D14A-40C6-820F-7BBD8CC07412; NetChoice 
Comments at 1 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/NetChoice%20on%20IANA%20Contract.pdf; Shawn Gunnarson at 7 (March 
31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=050ECD10-F12C-47E3-AE78-793AFE1F67E0.
    \5\ See e.g., Country Code Names Supporting Organization (ccNSO) 
Comments at 2 (March 29, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/ACF31A.pdf; 
Internet Architecture Board (IAB) Comments at 2 (March 30, 2011), 
available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=5EBBB0ED-CBE1-44EA-9FAF-0AFC662A1534; Internet Society 
(ISOC) Comments at 2 (March 30, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/ISOC%20Response_Docket%20110207099-1099-01.pdf.
---------------------------------------------------------------------------

    Some commenters expressed the view that NTIA should transition the 
IANA functions to ICANN.\6\ However, other commenters did not share 
this view and stated that no changes should be made to the current 
structure of the IANA functions contract.\7\ These commenters expressed 
concerns about transparency and accountability of the current 
contractor's decision-making. Some commenters proposed a multi-

[[Page 34660]]

stakeholder group be established to manage the IANA functions without 
the involvement of NTIA.\8\ Other commenters suggested the IANA 
Functions Operator should become an independent organization.\9\
---------------------------------------------------------------------------

    \6\ See ICANN Comments at 3 (March 25, 2011), available at 
http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/
ACF2EF.pdf; European Telecommunications Network Operators (ETNO) 
Comments at 2 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=0658E8D9-D4A9-4121-B7D9-4E26A9587859; Minds and Machines Comments at 1 (March 
31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=994F7CBE-F46D-45B8-82E1-BABCAE6046A2.
    \7\ See Canadian Internet Registration Authority (CIRA) Comments 
at 1 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=68F1E2E0-5671-4F26-9770-1701FD41BBE2, Coalition for Online Accountability (COA) Comments at 
2 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=68F1E2E0-5671-4F26-9770-1701FD41BBE2; International Trade Mark Association (INTA) Comments 
at 3 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/Comments%20of%20the%20International%20Trademark%20Association%20%28INTA%29.pdf; Tech Freedom Comments at 2 (April 1, 2011), available at 
http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/IANA%20NOI%20Comments%20-Final.pdf; PayPal Comments at 1 (March 31, 
2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/PayPal-NTIA-Response.pdf.
    \8\ See China Internet Network Information Center (CNNIC) 
Comments at 2 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=3A835CB9-68ED-4ABF-A376-7A4FF0F430A6; Kenya Comments at 2 (March 31, 2011), 
available at http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/Kenya%20comments%20on%20Notice%20of%20Inquiry%20by%20NTIA%20on%20IANA%20Contract%20v4.pdf; United Arab Emirates (UAE) Comments at 3 
(March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=9342F887-C549-4A01-AB56-D50F1C7460DF.
    \9\ See e.g., Internet Governance Capacity Building (IGCBP) 2011 
Comments at 1 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=AB73A9F5-4283-4783-9E10-D547EE1D9179.
---------------------------------------------------------------------------

    Commenters also expressed their views on the current contractual 
framework. Some commenters suggested that the IANA functions contract 
be transitioned to a Cooperative Agreement. Some commenters raised 
concerns that short-term contracts create instability in the IANA 
functions process and would prefer to see longer contracts.
    NTIA Response: As stated in the NOI, NTIA is committed to the 
multi-stakeholder process as an essential strategy for dealing with 
Internet policy issues. However, there is a need to address how all 
stakeholders, including governments collectively, can operate within 
the paradigm of a multi-stakeholder environment and be satisfied that 
their interests are being adequately addressed. Resolving this issue is 
critical to a strong multi-stakeholder model and to ensure the long-
term political sustainability of an Internet that supports the free 
flow of information, goods, and services. NTIA's continued commitment 
to openness and transparency and the multi-stakeholder model is 
evidenced by the manner in which it is proceeding with this 
procurement.
    Given the Internet's importance to the world economy, it is 
essential that the underlying DNS of the Internet remain stable and 
secure. Consistent with the 2005 U.S. Principles on the Internet's 
Domain Name and Addressing System, the United States is committed to 
maintaining its historic role and will take no action that would 
adversely impact the effective and efficient operation of the DNS.\10\ 
In addition, with this FNOI, NTIA reiterates that it is not in 
discussions with ICANN to transition the IANA functions nor does the 
agency intend to undertake such discussions.\11\
---------------------------------------------------------------------------

    \10\ In 2005, NTIA issued a statement of U.S. Principles on the 
Internet's Domain Name and Addressing System, available at 
www.ntia.doc.gov/ntiahome/domainname/USDNSprinciples_06302005.pdf.
    \11\ In 2008, NTIA sent a letter to ICANN stressing that the 
United States Government, while open to operational efficiency 
measures that address governments' legitimate public policy and 
sovereignty concerns with respect to the management of their country 
code top-level domains, ``has no plans to transition management of 
the authoritative root zone file to ICANN.'' Letter from Meredith 
Baker, Acting Assistant Secretary for Communications and 
Information, U.S. Department of Commerce, to Peter Dengate-Thrush, 
ICANN Chairman of the Board (July 30, 2008), available at http://www.ntia.doc.gov/comments/2008/ICANN_080730.html.
---------------------------------------------------------------------------

    NTIA does not have the legal authority to enter into a cooperative 
agreement with any organization, including ICANN, for the performance 
of the IANA functions.\12\ In addition, NTIA does not view the 
previously awarded IANA functions contracts as short-term contracts. 
Typical contracts are for one year, while the previous IANA functions 
contracts had terms, once options were exercised, of five years.
---------------------------------------------------------------------------

    \12\ Cooperative agreements are a form of Federal financial 
assistance. Federal agencies are required to have specific 
legislative authority to make Federal financial assistance awards. 
NTIA does not have specific legislative authority to make Federal 
financial assistance awards in the area of Internet domain name 
services. Federal agencies, however, have inherent authority to 
procure goods and services. Thus, NTIA and previously the Defense 
Advanced Research Projects Agency have been able to obtain the 
performance of the IANA functions under contract since the 1970s.
---------------------------------------------------------------------------

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

    Commenters were divided on whether the IANA functions should be 
separated. Some commenters opposed the idea of splitting the IANA 
functions and having the functions managed by separate 
organizations.\13\ These commenters emphasized the need for keeping the 
functions together to ensure Internet stability and security, to 
capture the synergy and interdependencies between the functions, and to 
obtain the benefits of economies of scale and efficiency by operating 
the functions together.\14\ Other commenters supported separating the 
functions, citing the absence of any underlying technical or critical 
Internet security or stability reason for keeping them together.\15\ 
Other commenters opposed the current contractor's role in INT and ARPA 
TLD registry operations, noting that such registry operations are in 
conflict with ICANN's bylaws.\16\ These commenters believed a plan 
should be put in place to separate the management of INT and ARPA TLDs 
from the IANA functions contract.\17\ However, some commenters noted 
the interdependency of the ARPA TLD with the other IANA functions such 
as protocol parameters (e.g., URI.ARPA) as well as address related 
information (e.g., IN-ADDR.ARPA, IP6.ARPA).\18\ These commenters do not 
believe the ARPA TLD should be separated from the other IANA 
functions.\19\ A number of commenters stated that separation of the 
IANA functions must be approached with caution and consultation.\20\ 
Further, commenters stated that if the

[[Page 34661]]

IANA functions were to be performed by a different entity or separated, 
it would be important to clearly articulate, and build in sufficient 
time, for the community and all involved organizations to understand 
the change in order to avoid user confusion, deliver improvements to 
service efficiencies, and react appropriately.\21\
---------------------------------------------------------------------------

    \13\ See IAB Comments at 1; ccNSO Comments at 1; ISOC Comments 
at 2; SIDN Comments at 3 (April 1, 2011), available at 
http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
attachments/SIDN%20position%20NTIA%20NoI%20IANA%20March%202011.pdf; 
ICANN Comments at 8; The Number Resource Organization (NRO) Comments 
at 2 (March 31, 2011), available at http:[sol][sol]www.ntia.doc.gov/
comments/110207099-1099-01/comment.cfm?e=519C0531-4C81-4761-9FCC-
9AF8D47BC69C.
    \14\ See IAB Comments at 1; ICANN Comments at 8; ictQatar 
Comments at 1; UAE Comments at 5.
    \15\ See Internet New Zealand (InternetNZ) Comments at 3 (March 
30, 2011), available at http:[sol][sol]www.ntia.doc.gov/comments/
110207099-1099-01/attachments/NTIA%20Submission%20-
%20IANA%20NOI.pdf; Bill Manning Comments at 1 (March 11, 2011), 
available at http:[sol][sol]www.ntia.doc.gov/comments/110207099-
1099-01/comment.cfm?e=8B430831-4634-4A6B-845B-97673CD97842.
    \16\ See Bill Manning Comments at 1; Tech Freedom Comments at 8.
    \17\ See Christopher Wilkinson Comments at 2 (March 30, 2011), 
available at http:[sol][sol]www.ntia.doc.gov/comments/110207099-
1099-01/attachments/NTIA_IANA_NOI_2.pdf; Jean-Jacques Subrenat, 
Beau Brendler, and Eric Brunner-Williams Comments at 7 (March 31, 
2011), available at http:[sol][sol]www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=E17DCD8A-B324-4979-9359-
4FA67E9429D5; NetChoice Comments at 3; Tech Freedom Comments at 9.
    \18\ See Cisco Comments at 4; IAB Comments at 4; Netnod Comments 
at 2 (March 31, 2011), available at http:[sol][sol]www.ntia.doc.gov/
comments/110207099-1099-01/comment.cfm?e=7EEEB455-7C85-4B20-B7A4-
13ECE382F210.
    \19\ See Cisco Comments at 4; IAB Comments at 4; Netnod Comments 
at 2.
    \20\ See ccNSO Comments at 1; Hong Kong Internet Registration 
Corporation Ltd (HKIRC) Comments at 1 (March 31, 2011), available at 
http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
attachments/
HKIRC%20Response%20to%20NTIA%20NoI%20on%20IANA%20functions.pdf.
    \21\ See ISOC Comments at 2; Paul Kane Comments at 2 (March 30, 
2011), available at http:[sol][sol]www.ntia.doc.gov/comments/
110207099-1099-01/attachments/IANA-NoI.pdf.
---------------------------------------------------------------------------

    NTIA Response: NTIA concludes that these three core functions 
should remain bundled for now and be performed by a single entity. In 
reaching this conclusion, we give substantial weight to the fact that 
the entities that could most likely independently perform any of the 
functions, if unbundled, support keeping the functions together. NTIA 
also agrees with those commenters that stated there is an associative 
relationship between the ARPA TLD and the protocol parameter and 
Internet numbering resources. Therefore, the management of the ARPA TLD 
will continue to be bundled with the IANA functions. NTIA, however, 
sees merit in further exploring separating the management of the INT 
TLD from the IANA functions contract, and have included in the Draft 
SOW at paragraph C.2.2.1.5.2 language to provide a process for doing 
so. NTIA will conduct a public consultation next year to see how best 
to transition the INT TLD.

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

    Some commenters believe it appropriate to reference the entities 
and relevant stakeholders responsible for the development of policies 
and procedures related to the IANA functions in the IANA functions 
contract. Commenters that supported this approach also expressed 
caution that referencing other entities and stakeholders could be 
perceived as expanding the scope of the IANA functions and lead to the 
contractor asserting unnecessary authority over those stakeholders.\22\ 
Commenters noted that any reference, if included, needs to be able to 
evolve as the Internet multi-stakeholder model evolves.\23\ Some 
commenters stated that the IANA functions contractor should not be 
involved in policy development discussions and suggested that the IANA 
functions contract recognize the distinction between acting in 
accordance with versus developing policy for each discrete IANA 
function.\24\
---------------------------------------------------------------------------

    \22\ See Dmitry Burkov Comments at 1 (March 26, 2011), available 
at http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=0922CC0D-62FF-4A91-90A8-C87C8CFA9527; ISOC Comments at 
3.
    \23\ See ictQatar Comments at 2.
    \24\ See Coalition Against Domain Name Abuse (CADNA) at 2 (March 
31, 2011), available at http:[sol][sol]www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=0EF012AA-6B7D-4DAC-8E2A-
8C871A182CC7; IAB Comments at 5; InternetNZ Comments at 2; Internet 
Governance Project Comments at 1 (March 31, 2011), available at 
http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=A9CC728A-75A7-4898-AA66-70B6B3656CDD.
---------------------------------------------------------------------------

    NTIA Response: NTIA recognizes that the IANA functions contractor, 
in the performance of its duties, requires close constructive working 
relationships with all interested and affected parties if it is to 
ensure quality performance of the IANA functions. NTIA agrees with 
suggestions by commenters that there must be functional separation 
between the processing of the IANA functions and the development of 
associated policies. As such, the Draft SOW includes paragraph 
C.2.2.1.1, which requires that all staff dedicated to executing the 
IANA functions remain separate and removed from any policy development 
that occurs related to the performance of the IANA functions.

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

    Commenters provided comments on the root zone management process 
related to country code top-level domains (ccTLDs), including 
Internationalized Domain Name ccTLD (IDN ccTLDs), as well as generic 
TLDs (gTLDs). The comments were diverse, but contained a few common 
themes. One common theme related to how and who developed policies and 
procedures affecting ccTLDs, IDN ccTLDs, and gTLDs.\25\ In addition 
some commenters were of the view that the introduction of new gTLDs 
should be carried out in the interest and for the benefit of the global 
Internet community.\26\ If a conflict arose with regard to public 
policy issues arising from specific gTLD proposals, some commenters 
asserted that ICANN's Government Advisory Committee (GAC) should 
provide input.\27\ Some commenters stated that ICANN's Country Code 
Names Supporting Organization (ccNSO), ccTLD operators/managers, 
ICANN's Generic Names Supporting Organization (GNSO) and the GAC should 
develop policies and procedures related to ccTLDs, IDN ccTLDs, and 
gTLDs and not the IANA functions contractor.\28\ In fact, when 
determining matters regarding delegation and redelegation of domain 
names, some commenters recommended that no decision should be made 
without the consultation with or consent of GAC, ccNSO, and/or relevant 
ccTLD operators.\29\ Many comments focused on the lack of consistency 
in the current delegation and redelegation process and procedures.\30\ 
The NOI record reflects support for the ccNSO's ongoing development of 
a ``Framework of Interpretation'' \31\ process that would provide 
guidance to the IANA functions contractor on how to interpret the range 
of policies, guidelines, and procedures relating to the delegations and 
redelegations of ccTLDs.\32\ Another

[[Page 34662]]

theme focused on automating root zone management processes. Some 
commenters addressed the need for full automation and development of 
audit trails in the root zone management process.\33\ For some 
commenters, full automation is an automatic, secure, and authenticated 
process that allows root zone changes to be made directly by the 
Registry Managers.\34\ Commenters stated that automating the root zone 
management process must be a priority for all three root zone 
management partners.\35\ This was emphasized in particular due to the 
impending expansion of gTLDs.
---------------------------------------------------------------------------

    \25\ See ccNSO Comments at 1; Fahd A. Batayneh Comments at 1 
(April 1, 2011), available at http:[sol][sol]www.ntia.doc.gov/
comments/110207099-1099-01/comment.cfm?e=34B162CD-1B19-470F-B257-
BBA8B19991C8; InternetNZ Comments at 2; Federal Office of 
Communications (OFCOM) and SWITCH Comments at 4 (March 31, 2011), 
available at http:[sol][sol]www.ntia.doc.gov/comments/110207099-
1099-01/attachments/Response-NTIA-IANA-NoI-2011_31113_05.pdf; Tech 
Freedom Comments at 7.
    \26\ See Dmitry Burkov Comments at 1; COA Comments at 2.
    \27\ See Google Comments at 4 (March 31, 2011), available at 
http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=A3F206A1-CDE5-4F2D-BC50-E0FCF9DF384C.
    \28\ See Asia Pacific Top Level Domain Association (APTLD) 
Comments at 1 (March 31, 2011), available at 
http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=FFB3621F-CC64-4E33-92E9-0CF7920BF8DA; InternetNZ at 4; 
OFCOM and SWITCH Comments at 4.
    \29\ See Ken-Ying Tseng Lee and Li Comments at 1 (March 29, 
2011), available at http:[sol][sol]www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=D6DDA78C-3994-4492-A46B-
9486A5B10798.
    \30\ ccNSO Comments at 3; InternetNZ Comments at 3; Nominet 
Comments at 2 (March 30, 2011), available at 
http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=46E70603-6139-4106-B74E-CBDB5C66A7BE; SIDN Comments at 
3.
    \31\ For more information on the ccNSO Framework, see Charter 
FoI WG (Adopted 16 March 2011), available at 
http:[sol][sol]ccnso.icann.org/workinggroups/charter-foiwg-16mar11-
en.pdf.
    \32\ See ccNSO Comments at 2; ICANN Comments at 11; ISOC 
Comments at 3; InternetNZ Comments at 3; Nominet Comments at 2.
    \33\ ccNSO Comments at 3; InternetNZ Comments at 3; Nominet 
Comments at 2; SIDN Comments at 3.
    \34\ CENTR Comments at 8 (March 31, 2011), available at 
http:[sol][sol]www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=77DDAEE0-C79B-4E78-A706-FEC09F89DE78; Paul Kane 
Comments at 3; AFNIC Comments at 3.
    \35\ ccNSO Comments at 3; InternetNZ Comments at 3; Nominet 
Comments at 2; SIDN Comments at 3.
---------------------------------------------------------------------------

    NTIA Response: NTIA recognizes that policies, technical standards, 
and procedures related to each of the IANA functions are developed 
outside the purview of the IANA functions contract and should be 
implemented. Since these policies affect a critical part of the 
Internet infrastructure, NTIA believes that these policies must be 
clear and concise to allow the IANA functions contractor to operate in 
accordance with the policies developed by the relevant stakeholders. To 
address this concern the Draft SOW includes a new paragraph C.2.2.1.3.2 
(Responsibility to and Respect of Stakeholders) that requires the 
contractor, in consultation with all relevant stakeholders, to develop 
a process for documenting the source of the policies and procedures and 
how it has applied the relevant policies and procedures in processing 
all TLD requests.
    In addition, NTIA agrees with commenters that there has been a lack 
of clarity in delegation and redelegation policies, process, and 
procedures. NTIA fully supports the work of the ccNSO's development of 
a ``Framework of Interpretation'' process and believes this process 
will in the future provide much needed guidance to the IANA functions 
contractor when processing delegation and redelegation requests for 
ccTLDs.
    Furthermore, NTIA agrees with commenters that the inconsistencies 
in delegation and redelegation policies might not have occurred if 
there had been functional separation between execution of the IANA 
functions and the associated policy development processes. To address 
this issue, as previously noted, the Draft SOW includes a paragraph 
C.2.2.1.1 that requires that all staff dedicated to executing the IANA 
functions remain separate and removed from any policy development that 
occurs related to the performance of the IANA functions.
    NTIA also supports commenters' views that it is critical that the 
introduction of individual new gTLDs reflects community consensus among 
relevant stakeholders and is in the global public interest. As such, 
the Draft SOW includes, in paragraph C.2.2.1.3.2, a requirement that 
delegation requests for new gTLDs include documentation demonstrating 
how the string proposed reflects consensus among relevant stakeholders 
and is supportive of the global public interest.
    NTIA likewise supports commenters' views that the IANA functions 
contractor be required to document the source of relevant policies and 
procedures when processing requests for delegation and redelegation of 
a TLD in such a manner to be consistent with relevant national laws of 
the jurisdiction which the registry serves. The Draft SOW addresses 
this issue in paragraph C.2.2.1.3.2, which requires the contractor to 
act in accordance with the relevant national laws of the jurisdiction 
which the TLD registry serves.
    NTIA notes that, while not directly stated by commenters, the 
technical process for deploying TLDs in the root zone is the same for 
ccTLDs and gTLDs. NTIA agrees with commenters that automating the root 
zone management process must be a priority especially with the 
increased workload associated with the introduction of new gTLDs. In 
the third quarter of 2011, the current root zone management partners 
will launch the Root Zone Management System (RZMs). RZMs is intended to 
automate some aspects of the process that are currently performed 
manually. This should improve the overall processing time and current 
accuracy of the root zone management function. As identified and 
recommended by a number of commenters, the Draft SOW includes paragraph 
C.2.2.1.3.3 (Root Zone Automation), which requires a minimum set of 
automated functions for a root zone automation system. NTIA believes 
this modification will address commenters' concerns regarding secure 
communications as well. While the Draft SOW does not require full 
automation of the root zone management process, NTIA plans to conduct 
public consultation next year to ascertain how best to fully automate 
the root zone management process.
    As for the requirement of audit trails identified by commenters, 
the Draft SOW now includes a new paragraph C.5.2 (Root Zone Management 
Audit Data), which requires that the contractor generate a monthly 
audit report to track each root zone change request and include the 
identification of the policy under which the changes were made.

Question 4: Broad performance metrics and reporting are currently 
required under the contract. 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? \36\
---------------------------------------------------------------------------

    \36\ Commenters believed that Questions 2, 3, 4, and 5 were 
closely related. See e.g., ccNSO Comments at 4; CENTR Comments at 3.
---------------------------------------------------------------------------

    Transparency was a major theme raised in the responses to this 
question. Some comments called for complete transparency in the IANA 
functions process. Commenters suggested that relevant stakeholders 
develop performance metrics for each discrete IANA function and that 
performance results be published monthly.\37\ Some suggested that the 
performance metrics for root zone management include: the number of 
change requests, the number of requests declined due to noncompliance, 
and a report on statistics for global deployment of IPv6 and 
DNSSEC.\38\ Some commenters noted the absence of Service Level 
Agreements (SLAs), especially for the root zone management and IP 
addressing functions and suggested that SLAs be developed in 
collaboration with the communities they serve.\39\ Commenters suggested 
that SLAs could include framework parameters, service levels, and 
responsibilities relating to root zone management.\40\ Some commenters 
stated that root zone management documentation should be published in 
all six United Nations' languages.\41\ The NOI record reflects some 
commenters' concern regarding

[[Page 34663]]

the unknown operational costs of coordinating the IANA functions. Some 
commenters stated that more detailed and open financial reports for the 
IANA functions are necessary.\42\ These commenters recommended the IANA 
functions contractor be required to develop a process for tracking 
costs.\43\
---------------------------------------------------------------------------

    \37\ See ARIN Comments at 3-4 (March 31, 2011), available at 
http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=9BEFA8A5-655F-4AE5-95AA-66BED9A9F2C4; ccNSO Comments 
at 4; ISOC Comments at 4; SIDN Comments at 5.
    \38\ See Hutchinson Comments at 1 (March 31, 2011), available at 
http://www.ntia.doc.gov/comments/110207099-1099-01/attachments/NTIA%20NOI%20on%20IANA.pdf.
    \39\ See ARIN Comments at 3; ccNSO Comments at 4; CNNIC at 1; 
InternetNZ Comments at 5; Kenya Comments at 3; SIDN Comments at 5.
    \40\ See ccNSO Comments at 4; SIDN Comments at 5.
    \41\ See ALAC Comments at 7 (March 31, 2011), available at 
http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=7669299A-100A-4A45-AEC7-E236AA41E643; AFNIC Comments 
at 3 (March 31, 2011), available at http://www.ntia.doc.gov/comments/110207099-1099-01/comment.cfm?e=513BA51F-85C2-43BD-B6EB-E50F5DC724BD; CENTR Comments at 3; Kenya at 3.
    \42\ See AFNIC Comments at 3; CENTR Comments at 3; Netnod 
Comments at 3.
    \43\ See AFNIC Comments at 3; CENTR Comments at 3; Netnod 
Comments at 3.
---------------------------------------------------------------------------

    NTIA Response: NTIA agrees with commenters that there should be 
transparency and accountability in the performance of the IANA 
functions. NTIA supports commenters' views that the IANA functions 
contractor should meet certain performance standards for each discrete 
IANA function and that these performance standards and metrics should 
be developed in conjunction with the relevant stakeholders for these 
services. NTIA, however, does not support the development of specific 
SLAs with each stakeholder or groups of stakeholders. Given that the 
IANA functions are performed under contract with the U.S. Government, 
such agreements would be subject to government procurement laws and 
regulations. NTIA believes that the concerns expressed by commenters 
can be addressed without the formality of such agreements. Accordingly, 
NTIA provides language in paragraphs C.2.2.1.2, C.2.2.1.3, C.2.2.1.4 
and C.2.2.1.5 of the Draft SOW to require that the IANA functions 
contractor develop performance standards and metrics for each discrete 
IANA functions in consultation with the relevant stakeholders.
    The IANA functions contract has traditionally been performed at no 
cost to the United States Government. Under the current contract, the 
contractor may establish and collect fees from third parties to cover 
the costs of its performance of the IANA functions. The fees must be 
fair and equitable, and in the aggregate, cannot exceed the cost of 
providing the services. The Government has reserved the right to review 
the contractor's accounting data at any time fees are charged to verify 
that these conditions are being met.
    The U.S. Government cannot require a contractor to release 
information to the public that it considers to be business confidential 
and/or proprietary, which may include its costs for the provision of 
service. It can, however, ensure that any fees charged are reasonable 
and cost-based. Accordingly, it is NTIA's intention to award any future 
contract with the same requirements that all fees are fair and 
equitable, and the right to review the contractor's accounting data to 
ensure that these requirements are met.
    The NOI record reflects a recommendation that the IANA functions 
contractor be required to gather and report on statistics regarding 
global IPv6 and DNSSEC deployment. NTIA has not included this as a 
requirement in the Draft SOW because it is not clear whether there is 
consensus to include this as a new requirement of the IANA functions 
contract or rather whether this is a matter for which the community 
seeks additional information through ICANN. NTIA asks specific 
questions on this issue below as part of this FNOI to obtain 
clarification.

Question 5: Can process improvements or performance enhancements be 
made to 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.

    The NOI record demonstrates the need for transparency in the root 
zone management process.\44\ Commenters stated that the root zone 
management process should be more open and transparent and include 
reporting on all root zone management partners' activities.\45\ For 
example, commenters would like to see real time status of every root 
zone change request all the way through the process. This would include 
action taken at any given stage of the process flow for root zone 
management.\46\ Some commenters stated there should be a process for 
ccTLDs to appeal root management zone decisions made by the IANA 
functions contractor, in the event it does not follow existing and 
documented policies.\47\ They also noted the need for the IANA 
functions contractor to consistently interpret broad policy guidance 
such as RFC 1591, ICP-1 and the GAC ccTLD Principles and publish 
information that documents the root zone change request process.\48\ 
Commenters suggested that the IANA functions contractor should better 
respect national sovereignty as it relates to ccTLDs, including the 
legitimate interests of governments, the local Internet communities, 
and the primacy of national laws, which have been clearly stated by the 
GAC in its ccTLD Principles, and the 2005 U.S. Principles on the 
Internet's Domain Name and Addressing System.\49\ Some commenters also 
expressed an interest in an annual or biennial survey of the IANA 
functions customers to determine customer satisfaction.\50\ The NOI 
record reflects commenters' concern whether ICANN will implement the 
new gTLD program in the interest and for the benefit of global Internet 
users, and if there are checks and balances on root zone changes to 
ensure the security and stability of the DNS.\51\
---------------------------------------------------------------------------

    \44\ See ARIN Comments at 3-4; ccNSO Comments at 4; ISOC 
Comments at 4; SIDN Comments at 5.
    \45\ See ARIN Comments at 3-4; ccNSO Comments at 4; ISOC 
Comments at 4; SIDN Comments at 5.
    \46\ For a description of the current process flow, please see 
the diagram posted on NTIA's Web site at http://www.ntia.doc.gov/DNS/CurrentProcessFlow.pdf.
    \47\ See ccNSO Comments at 4; AFNIC Comments at 2.
    \48\ See ccNSO Comments at 5; CENTER Comments at 2; Kenya 
Comments at 2; SIDN Comments at 5; OFCOM and SWITCH Comments at 5.
    \49\ See ccNSO Comments at 5; SIDN Comments at 5; Paul Kane 
Comments at 4.
    \50\ See InternetNZ Comments at 7; ccNSO Comments at 4.
    \51\ See Dmitry Burkov Comments at 1; COA Comments at 2; 
Netchoice Comments at 4.
---------------------------------------------------------------------------

    NTIA Response: NTIA agrees with statements made by commenters that 
the root zone management process should be more transparent to the 
users of the IANA functions. As a result, paragraph C.4.2 (Root Zone 
Management Dashboard) of the draft SOW requires the IANA functions 
contractor to work with NTIA and VeriSign to collaborate in the 
development and implementation of a dashboard to track the process flow 
for root zone management. The United States fully supports the fact 
that governments have a legitimate interest in the management of their 
ccTLDs. The United States is committed to working with the 
international community to address these concerns, bearing in mind the 
fundamental need to ensure stability and security of the Internet DNS. 
As stated earlier, NTIA plans to conduct public consultation next year 
to ascertain how best to fully automate the root zone management 
process.
    NTIA supports the need for accountability with respect to root zone 
management decisions. Accordingly, as discussed above, NTIA has 
included provisions in the draft SOW at paragraph C.2.2.1.3.5 that 
requires the IANA functions contractor to establish a process that 
would allow customers to submit complaints regarding the root

[[Page 34664]]

zone management process for resolution.
    Lastly, NTIA agrees with commenters that the new gTLD program must 
benefit the global Internet users and not jeopardize the security and 
stability of the DNS. Accordingly, the draft SOW includes paragraph 
C.2.2.1.3.2 (Responsibility and Respect for Stakeholders) that provides 
checks and balances for TLD root zone management changes, to ensure the 
continued stability and security of the DNS.

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

    With respect to root zone management, some commenters recommended 
the IANA functions contractor utilize a secure communications system 
for customer communications that would include the following: better 
authentication processes for the receipt and management of change 
requests, a process for issuing confirmations, moving from open online 
forms to signed and secure mechanisms, better availability of 
information related to root zone management such as outages, and more 
notice of planned maintenance or new developments.\52\ Some commenters 
recommended that the next IANA functions contract include a requirement 
that the performance of the IANA functions undergo a security audit 
annually by external, independent, specialized auditors against 
relevant international standards such as ISO 27001.\53\ Commenters also 
expressed concern with describing in detail security considerations 
and/or enhancements in the IANA functions contract.\54\ Some commenters 
recommended that, at a minimum, that the contract employ best practices 
in information security to ensure the protection of data and security 
and stability of its operations.\55\ One commenter recommended the 
following be included in the next IANA functions contract: ``A 
requirement for regular external reviews of process and security using 
a number of methods including document audits, penetration testing and 
international standards benchmarking; the results of these reviews 
should be made public within a specified timeframe to allow for any 
corrective measures to be taken; a published disaster recovery plan for 
the operator that is regularly consulted upon; a documented emergency 
process for customers to follow if they are experiencing an emergency, 
which includes private emergency contact numbers for the operator to be 
contacted on.'' \56\
---------------------------------------------------------------------------

    \52\ See ccNSO Comments at 5; InternetNZ Comments at 6; SIDN 
Comments at 6.
    \53\ ARIN, at 5; ccNSO, at 5; SIDN, at 6.
    \54\ ISOC Comments at 5; IAB Comments at 6.
    \55\ ARIN Comments at 5; IAB Comments at 6; ISOC Comments at 6.
    \56\ See InternetNZ Comments at 5.
---------------------------------------------------------------------------

    NTIA Response: NTIA agrees with commenters that the IANA functions 
contractor needs to be able to communicate with service recipients in a 
secure and confidential manner. NTIA notes, however, that the IANA 
functions contractor needs to have some flexibility in the manner in 
which it secures communications to accommodate the needs and 
capabilities of all service recipients. Accordingly, the paragraph C.3 
(Security Requirements) requires the IANA functions contractor to 
implement a secure communications system and data storage system. NTIA 
considers the designation of a qualified Director of Security as key 
personnel and is an essential component of the Contractor's ability to 
provide secure data services. As a result, in paragraph C.3.5, NTIA 
will require the Contractor to designate a Director of Security and 
consult with NTIA on any changes in this critical position. During the 
procurement process, NTIA will also require the identification of this 
key personnel and a demonstration of their qualifications for the 
position prior to contract award.
    NTIA supports commenters' recommendations that the IANA functions 
contractor work with the relevant community of each discrete IANA 
function to develop a Contingency and Continuity of Operations Plan 
(CCOP). Therefore, the Draft SOW contains paragraph C.3.6 (Contingency 
and Continuity of Operations Plan) to include this requirement.
    NTIA also agrees with the recommendation that the performance of 
the IANA functions undergo an annual security audit by an external, 
independent specialized compliance auditor against relevant 
international standards such as ISO 27001. NTIA has included paragraph 
C.5 (Audit Requirements) in the Draft SOW to capture these audit 
concerns.

Draft Statement of Work (Draft SOW)

    Below is the Draft SOW for which NTIA seeks comment. The Draft SOW 
details the work requirements for the IANA functions and when 
finalized, NTIA will incorporate it into the procurement process for 
the IANA functions contract.

C.1 Background

    C.1.1 The U.S. Department of Commerce (DoC), National 
Telecommunications and Information Administration (NTIA) has initiated 
this agreement to maintain the continuity and stability of services 
related to certain interdependent Internet technical management 
functions, known collectively as the Internet Assigned Numbers 
Authority (IANA).
    C.1.2 Initially, these interdependent technical functions were 
performed on behalf of the Government under a contract between the 
Defense Advanced Research Projects Agency (DARPA) and the University of 
Southern California (USC), as part of a research project known as the 
Tera-node Network Technology (TNT). As the TNT project neared 
completion and the DARPA/USC contract neared expiration in 1999, the 
Government recognized the need for the continued performance of the 
IANA functions as vital to the stability and correct functioning of the 
Internet.
    C.1.3 The Government acknowledges that data submitted by applicants 
in connection with the IANA functions is confidential information. To 
the extent permitted by law, the Government shall accord any data 
submitted by applicants in connection with the IANA functions with the 
same degree of care as it uses to protect its own confidential 
information, but not less than reasonable care, to prevent the 
unauthorized use, disclosure, or publication of confidential 
information. In providing data that is subject to such a 
confidentiality obligation to the Government, the Contractor shall 
advise the Government of that obligation.
    C.1.4 The Contractor, in the performance of its duties, has a need 
to have close constructive working relationships with all interested 
and affected parties including to ensure quality performance of the 
IANA functions. The interested and affected parties include, but are 
not limited to, the Internet Engineering Task Force (IETF) and the 
Internet Architecture Board (IAB), regional registries, country code 
top-level domain (ccTLD) operators/managers, governments, and the 
Internet user community.

C.2 Contractor Requirements

    C.2.1 The Contractor must perform the required services for this 
contract as a prime Contractor, not as an agent or subcontractor. The 
Contractor shall not enter into any subcontracts for the performance of 
the services, or assign or

[[Page 34665]]

transfer any of its rights or obligations under this Contract, without 
the Government's prior written consent and any attempt to do so shall 
be void and without further effect. The Contractor must possess and 
maintain through the performance of this acquisition a physical address 
within the United States. The Government reserves the right to inspect 
the premises, systems, and processes of all security and operational 
components used for the performance of these requirements, which, in 
addition, shall all maintain physical residency within the United 
States.
    C.2.2 The Contractor shall furnish the necessary personnel, 
material, equipment, services, and facilities, to perform the following 
requirements without any cost to the Government. The Contractor shall 
conduct due diligence in hiring, including full background checks. On 
or after the effective date of this purchase order, the Contractor may 
establish and collect fees from third parties (i.e., other than the 
Government) for the functions performed under this purchase order, 
provided the fee levels are approved by the Contracting Officer before 
going into effect, which approval shall not be withheld unreasonably 
and provided the fee levels are fair and equitable and provided the 
aggregate fees charged during the term of this purchase order do not 
exceed the cost of providing the requirements of this purchase order. 
The Government will review the Contractor's accounting data at anytime 
fees are charged to verify that the above conditions are being met.
    C.2.2.1 The Contractor is required to maintain the IANA functions, 
the Internet's core infrastructure, in a stable and secure manner. In 
performance of this purchase order, the Contractor shall furnish the 
necessary personnel, material, equipment, services, and facilities 
(except as otherwise specified), to perform the following IANA function 
requirements.
    C.2.2.1.1 The Contractor shall ensure that any and all staff 
dedicated to executing the IANA functions remain separate and removed 
(not involved) from any policy development that occurs related to the 
performance of the IANA functions.
    C.2.2.1.2 Coordinate The Assignment Of Technical Protocol 
Parameters--This function involves the review and assignment of unique 
values to various parameters (e.g., operation codes, port numbers, 
object identifiers, protocol numbers) used in various Internet 
protocols. This function also includes the dissemination of the 
listings of assigned parameters through various means (including on-
line publication) and the review of technical documents for consistency 
with assigned values. Within six (6) months of award, the Contractor 
shall submit to NTIA performance standards and metrics developed in 
collaboration with relevant stakeholders for approval. Upon approval by 
the Contracting Officer's Technical Representative (COTR), the 
Contractor shall perform this task in compliance with approved 
performance standards and metrics. The performance of this function 
shall be in compliance with the performance exclusions as enumerated in 
Section C.6.
    C.2.2.1.3 Perform Administrative Functions Associated With Root 
Zone Management--This function addresses facilitation and coordination 
of the root zone of the domain name system, with 24 hour-a-day/7 days-
a-week coverage. This function includes receiving delegation and 
redelegation requests, and investigating the circumstances pertinent to 
those requests. This function also includes receiving change requests 
for and making routine updates to all top-level domains (TLDs) contact 
(including technical and administrative contacts), nameserver, and 
delegation signer (DS) resource record (RR) information as 
expeditiously as possible. Within six (6) months of award, the 
Contractor shall submit to NTIA performance standards and metrics 
developed in collaboration with relevant stakeholders for approval. 
Upon approval by the COTR, the Contractor shall perform this task in 
compliance with approved performance standards and metrics. The 
performance of this function shall be in compliance with the 
performance exclusions as enumerated in Section C.6.
    C.2.2.1.3.1 Transparency and Accountability--The Contractor shall 
process all requests for changes to the root zone and the authoritative 
root zone database, collectively referred to as ``IANA root zone 
management requests,'' promptly and efficiently. The Contractor shall, 
in collaboration with all relevant stakeholders, develop user 
documentation. The Contractor shall prominently post on its Web site 
the performance standards and metrics, user documentation, and 
associated policies.
    C.2.2.1.3.2 Responsibility and Respect for Stakeholders--The 
Contractor shall, in collaboration with all relevant stakeholders for 
this function, develop a process for documenting the source of the 
policies and procedures and how it has applied the relevant policies 
and procedures, such as RFC 1591, to process requests associated with 
TLDs. In addition, the Contractor shall act in accordance with the 
relevant national laws of the jurisdiction which the TLD registry 
serves. For delegation requests for new generic TLDS (gTLDs), the 
Contractor shall include documentation to demonstrate how the proposed 
string has received consensus support from relevant stakeholders and is 
supported by the global public interest.
    C.2.2.1.3.3 Root Zone Automation--The Contractor shall work with 
NTIA and VeriSign, Inc. (or any successor entity as designated by the 
U.S. Department of Commerce) to deploy an automated root zone 
management system within six (6) months after date of contract award. 
The automated system shall at a minimum include: secure (encrypted) 
system for customer communications; automated provisioning protocol 
allowing customers to develop systems to manage their interactions with 
the Contractor with minimal delay; an online database of change 
requests and subsequent actions whereby each customer can see a record 
of their historic requests and maintain visibility into the progress of 
their current requests; and a test system, which customers can use to 
check that their change request will meet the automated checks.
    C.2.2.1.3.4 Root Domain Name System Security Extensions (DNSSEC) 
Key Management--The Contractor shall be responsible for the management 
of the root zone Key Signing Key (KSK), including generation, 
publication, and use for signing the Root Keyset.
    C.2.2.1.3.5 Customer Service Complaint Resolution Process--The 
Contractor shall establish a process for IANA function customers to 
submit complaints for timely resolution.
    C.2.2.1.4 Allocate Internet Numbering Resources--This function 
involves overall responsibility for allocated and unallocated IPv4 and 
IPv6 address space and Autonomous System Number (ASN) space. It 
includes the responsibility to delegate of IP address blocks to 
regional registries for routine allocation, typically through 
downstream providers, to Internet end-users within the regions served 
by those registries. This function also includes reservation and direct 
allocation of space for special purposes, such as multicast addressing, 
addresses for private networks as described in RFC 1918, and globally 
specified applications. Within six (6) months of award, the Contractor 
shall submit to NTIA performance standards and metrics developed in 
collaboration with relevant stakeholders for approval. Upon approval by 
the COTR, the Contractor shall perform this task in

[[Page 34666]]

compliance with approved performance standards and metrics. The 
performance of this function shall be in compliance with the 
performance exclusions as enumerated in Section C.6.
    C.2.2.1.5 Other services--The Contractor shall perform other IANA 
functions, including the management of the INT and ARPA TLDs. The 
Contractor shall also implement modifications in performance of the 
IANA functions as needed upon mutual agreement of the parties. The 
performance of this function shall be in compliance with the 
performance exclusions as enumerated in Section C.6.
    C.2.2.1.5.1 ARPA TLD--The Contractor shall operate the ARPA TLD 
within the current registration policies for the TLD, including RFC 
3172. The Contractor shall be responsible for implementing DNSSEC in 
the ARPA TLD consistent with the requirements of the relevant 
stakeholders for this function and approved by NTIA. Within six (6) 
months of award, the Contractor shall submit to NTIA performance 
standards and metrics developed in collaboration with relevant 
stakeholders. Upon approval by the COTR, the Contractor shall perform 
this task in compliance with approved performance standards and 
metrics.
    C.2.2.1.5.2 INT TLD--The Contractor shall operate the INT TLD 
within the current registration policies for the TLD. Upon designation 
of a successor registry, if any, the Contractor shall use commercially 
reasonable efforts to cooperate with NTIA to facilitate the smooth 
transition of operation of the INT TLD. Such cooperation shall, at a 
minimum, include timely transfer to the successor registry of the then-
current top-level domain registration data.

C.3 Security Requirements

    C.3.1 Secure Systems--The Contractor shall install and operate all 
computing and communications systems in accordance with best business 
and security practices. The Contractor shall implement a secure system 
for authenticated communications between it and its customers when 
carrying out all IANA function requirements within nine (9) months 
after date of contract award. The Contractor shall document practices 
and configuration of all systems.
    C.3.2 Secure Systems Notification--Within nine (9) months after 
date of contract award, the Contractor shall implement and thereafter 
operate and maintain a secure notification system at a minimum, capable 
of notifying all relevant stakeholders of the discrete IANA functions, 
of such events as outages, planned maintenance, and new developments.
    C.3.3 Secure Data--The Contractor shall ensure the authentication, 
integrity, and reliability of the data in performing the IANA 
requirements, including the data relevant to DNS, root zone change 
request, and IP address allocation.
    C.3.4 Computer Security Plan--The Contractor shall develop and 
execute a Security Plan. The plan shall be developed and implemented 
within nine (9) months after date of contract award, and updated 
annually. The Contractor shall deliver the plan to the Government 
annually.
    C.3.5 Director of Security--The Contractor shall designate a 
Director of Security who shall be responsible for ensuring technical 
and physical security measures, such as personnel access controls. The 
Contractor shall notify and consult in advance the COTR when there are 
personnel changes in this position.
    C.3.6 Contingency and Continuity of Operations Plan (The CCOP)--The 
Contractor shall, in collaboration with relevant stakeholders, develop 
and implement a CCOP for the IANA functions within nine (9) months 
after date of contract award. The Contractor shall update and exercise 
the plan annually. The CCOP shall include details on plans for 
continuation of the IANA functions in the event of a logical or 
physical attack or emergency. The Contractor shall deliver the CCOP to 
the Government annually.

C.4 Performance Metric Requirements

    C.4.1 Monthly Performance Progress Report--The Contractor shall 
prepare and submit to the COTR a performance progress report every 
month (no later than 15 calendar days following the end of each month) 
that contains 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) during the 
previous 30-day period. The report shall include a narrative summary of 
the work performed for each of the functions with appropriate details 
and particularity. The report shall also describe major events, 
problems encountered, and any projected significant changes, if any, 
related to the performance of duties set forth in Section C.2.
    C.4.2 Root Zone Management Dashboard--The Contractor shall 
collaborate with NTIA and VeriSign, Inc., (or any successor entity as 
designated by the U.S. Department of Commerce) to develop and make 
available a dashboard to track the process flow for root zone 
management within nine (9) months after date of contract award.
    C.4.3 Performance Standards Metrics Reports--The Contractor shall 
develop and publish consistent with the developed performance standards 
and metrics reports for each discrete IANA function consistent with 
Section C.2. The Performance Standard Metric Reports will be published 
every month (no later than 15 calendar days following the end of each 
month) starting no later than nine (9) months after date of contract 
award.
    C.4.4 Performance Survey--The Contractor shall develop and conduct 
an annual performance survey consistent with the developed performance 
standards and metrics for each of the discrete IANA functions. The 
survey shall include a feedback section for each discrete IANA 
function. The Contractor shall publish the Survey Report annually on 
its Web site.
    C.4.5 Final Report--The Contractor shall prepare and submit a final 
report on the performance of the IANA functions that documents standard 
operating procedures, including a description of the techniques, 
methods, software, and tools employed in the performance of the IANA 
functions. The Contractor shall submit the report to the Contracting 
Officer and the COTR no later than 30 days after expiration of the 
purchase order.

C.5 Audit Requirements

    C.5.1 Audit Data--The Contractor shall generate and retain security 
process audit record data for one year and provide an annual audit 
report to the Contracting Officer and the COTR. All root zone 
management operations shall be included in the audit, and records on 
change requests to the root zone file and the Contractor shall retain 
these records. The Contractor shall provide specific audit record data 
to the Contracting Officer and COTR upon request.
    C.5.2 Root Zone Management Audit Data--The Contractor shall 
generate a monthly (no later than 15 calendar days following the end of 
each month) audit report based on information in the performance of 
Provision C.2.2.1.3 Perform Administrative Functions Associated With 
Root Zone Management. The audit report shall track each root zone 
change request and identify the relevant policy under which the change 
was made as well as track change rejections and identify the relevant 
policy under which the change

[[Page 34667]]

request was rejected starting no later than nine (9) months after date 
of contract award.
    C.5.3 External Auditor--The Contractor shall have an external, 
independent, specialized compliance auditor conduct an audit of the 
IANA functions security provisions annually.

C.6 Performance Exclusions

    C.6.1 This purchase order, in itself, does not authorize 
modifications, additions, or deletions to the root zone file or 
associated information. (This purchase order does not alter the root 
zone file responsibilities as set forth in Amendment 11 of the 
Cooperative Agreement NCR-9218742 between the DoC and VeriSign, Inc.)
    C.6.2 This purchase order, in itself, does not authorize the 
Contractor to make material changes in the policies and procedures 
developed by the relevant entities associated with the performance of 
the IANA functions. The Contractor shall not change or implement the 
established methods associated with the performance of the IANA 
functions without prior approval of the COTR.
    C.6.3 The performance of the functions under this contract, 
including the development of recommendations in connection with 
processing changes that constitute delegations and redelegations of 
ccTLDs, shall not be, in any manner, predicated or conditioned on the 
existence or entry into any contract, agreement or negotiation between 
the Contractor and any party requesting such changes or any other 
third-party.

Questions Related to the Draft SOW

    The public is invited to comment on any aspect of the Draft SOW 
including, but not limited to, the specific questions set forth below. 
When responding to specific questions, please cite the number(s) of the 
questions addressed, the ``section'' of the Draft SOW to which the 
question(s) correspond, and provide any references to support the 
responses submitted.
    1. Does the language in ``Provision C.1.3'' capture views on how 
the relevant stakeholders as sources of the policies and procedures 
should be referenced in the next IANA functions contract. If not, 
please propose specific language to capture commenters' views.
    2. Does the new ``Provision C.2.2.1.1'' adequately address concerns 
that the IANA functions contractor should refrain from developing 
policies related to the IANA functions? If not, please provide detailed 
comments and specific suggestions for improving the language.
    3. Does the language in ``Provisions C.2.2.1.2, C.2.2.1.3, 
C.2.2.1.4, and C.2.2.1.5'' adequately address concerns that the IANA 
functions contractor should perform these services in a manner that 
best serves the relevant stakeholders? If not, please propose detailed 
alternative language.
    4. Does the language in ``Provision C.2.2.1.3'' adequately address 
concerns related to root zone management? If not, please suggest 
detailed alternative language. Are the timeframes for implementation 
reasonable?
    5. Does the new ``Provision C.2.2.1.3.2 Responsibility and Respect 
for Stakeholders'' adequately address concerns related to the root zone 
management process in particular how the IANA functions contractor 
should document its decision making with respect to relevant national 
laws of the jurisdiction which the TLD registry serves, how the TLD 
reflects community consensus among relevant stakeholders and/or is 
supported by the global public interest. If not, please provide 
detailed suggestions for capturing concerns. Are the timeframes for 
implementation reasonable?
    6. Does the new ``Section C.3 Security Requirements'' adequately 
address concerns that the IANA functions contractor has a secure 
communications system for communicating with service recipients? If 
not, how can the language be improved? Is the timeframe for 
implementation reasonable?
    7. Does the new ``Provision C.2.2.1.3.5 Customer Service Complaint 
Resolution Process'' provide an adequate means of addressing customer 
complaints? Does the new language provide adequate guidance to the IANA 
functions contractor on how to develop a customer complaint resolution? 
If not, please provide detailed comments and suggestions for improving 
the language.
    8. Does the new ``Provision C.3.6 Contingency and Continuity of 
Operations Plan (CCOP)'' adequately address concerns regarding 
contingency planning and emergency recovery? If not, please provide 
detailed comments and suggestions for improving the language. Are the 
timeframes for implementation reasonable?
    9. Does the new ``Section C.4 Performance Standards Metric 
Requirements'' adequately address concerns regarding transparency in 
root zone management process, and performance standards and metrics? 
Should the contractor be required to gather and report on statistics 
regarding global IPv6 and DNSSEC deployment? If so, how should this 
requirement be reflected in the SOW? What statistics should be gathered 
and made public?
    10. Does the new ``Section C.5 Audit Requirements'' adequately 
address concerns regarding audits? If not, please propose alternative 
language. Are the timeframes for implementation reasonable?

    Dated: June 9, 2011.
Lawrence E. Strickling,
Assistant Secretary for Communications and Information.
[FR Doc. 2011-14762 Filed 6-13-11; 8:45 am]
BILLING CODE 3510-60-P