15 June 2011
Internet Assigned Numbers Authority (IANA) Functions
[Federal Register Volume 76, Number 114 (Tuesday, June 14, 2011)]
[Notices]
[Pages 34658-34667]
From the Federal Register Online via the Government Printing 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
IANAFunctionsFNOI@ntia.doc.gov. 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: vharris@ntia.doc.gov. 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
|