The Internet Assigned Numbers Authority (IANA) Functions, 34658-34667 [2011-14762]
Download as PDF
<![CDATA[
34658
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
srobinson on DSK4SPTVN1PROD with NOTICES
azimuth surveys [WAZ]), and ocean
bottom surveys [OBS], and (2) high
resolution surveys.
Deep Seismic Surveys
For 2D seismic surveys, a single
streamer is towed behind the survey
vessel, together with a single source or
airgun array. Seismic vessels generally
follow a systematic pattern during a
survey, typically a simple grid pattern
for 2D work with lines no closer than
half a kilometer (km). A 2D survey may
take many months depending on the
size of the geographic area.
A 3D survey uses multiple streamers
and an airgun array(s), to collect a very
large number of 2D slices, with
minimum line separations of only 25 to
30 meters (m) (82 to 98.4 feet [ft]). A 3D
survey may take many months to
complete (e.g., 3 to 18) and involves a
precise definition of the survey area and
transects, including multiple passes to
cover a given survey area. For seismic
surveys, 3D methods represent a
substantial improvement in resolution
and useful information relative to 2D
methods. Most areas in the GOM
previously surveyed using 2D have
been, or will be surveyed using 3D.
A typical 3D survey might employ a
dual array of 18 airguns per array. The
streamer array might consist of six to
eight parallel cables, each 3 to 12 km
(1.9 to 7.5 miles [mi]) long, and spaced
25 to 100 m (82 to 328.1 ft) apart. An
eight streamer array used for deep water
surveys is typically 700 m (2,296.6 ft)
wide. A series of 3D surveys collected
over time (commonly referred to as fourdimensional [4D] seismic surveying) is
used for reservoir monitoring and
management (i.e., the movement of oil,
gas, and water in reservoirs can be
observed over time).
WAZ acquisition configurations
involve multiple vessels operating
concurrently in a variety of source
vessel to acquisition vessel geometries.
Several source vessels (usually two to
four) are used in coordination with
single or dual receiver vessels either in
a parallel or rectangular arrangement
with a typical 1,200 m (3,937 ft) vessel
spacing to maximize the azimuthal
quality of data acquired. It is not
uncommon to have sources also
deployed from the receiver vessels in
addition to source-only vessels. This
improves the signal-to-noise ratio and
helps to better define the salt and subsalt structures in the deep waters of the
GOM. Coiled (spiral) surveys are a
further refinement of the WAZ
acquisition of sub-salt data. These
surveys can consist of a single source/
receiver arrangement or a multi-vessel
operation with multi-sources where the
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
vessels navigate in a coiled or spiral
pattern over the area of acquisition.
Deep seismic surveys (2D, 3D, or
WAZ) are typically deeper penetrating
than high resolution surveys and may
also be done on leased blocks for more
accurate identification of potential
reservoirs in ‘‘known’’ fields. This
technology can be used in developed
areas to identify bypassed hydrocarbonbearing zones in currently producing
formations and new productive
horizons near or below currently
producing formations. It can also be
used in developed areas for reservoir
monitoring and field management.
OBS surveys were originally designed
to enable seismic surveys in congested
areas, such as producing fields, with
many platforms and production
facilities. Autonomous nodes or cables
are deployed and retrieved by either
vessels or remotely operated vehicles
(ROVs). Nodes are becoming more
commonly used in the GOM. OBS
surveys have been found to be useful for
obtaining multi-component (i.e., seismic
pressure, vertical, and the two
horizontal motions of the water bottom,
or seafloor) information.
OBS surveys require the use of
multiple vessels (i.e., usually two
vessels for cable or node layout/pickup,
one vessel for recording, one vessel for
shooting, and two utility vessels). These
vessels are generally smaller than those
used in streamer operations, and the
utility vessels can be very small.
Operations are conducted ‘‘around the
clock’’ and begin by dropping the cables
off the back of the layout vessel or by
deployment of nodal receivers by ROVs.
Cable length or the numbers of nodes
depend upon the survey demands; it is
typically 4.2 km (2.6 mi), but can be up
to 12 km. However, depending on
spacing and survey size, hundreds of
nodes can be deployed and re-deployed
over the span of the survey. Groups of
seismic detectors, usually hydrophones
and vertical motion geophones, are
attached to the cable in intervals of 25
to 50 m (82 to 164 ft) or autonomous
nodes are spaced similarly. Multiple
cables/nodes are laid parallel to each
other using this layout method with a 50
m interval between cables/nodes.
Typically dual airgun arrays are used on
a single source vessel. When a cable/
node is no longer needed to record
seismic data, it is picked up by the cable
pickup vessel/ROV and is moved over
to the next position where it is needed.
A particular cable/node can be on the
seafloor anywhere from two hours to
several days, depending upon operation
conditions. Normally a cable will be left
in place about 24 hr. However, nodes
may remain in place until the survey is
PO 00000
Frm 00020
Fmt 4703
Sfmt 4703
completed or recovered and then redeployed by an ROV.
High Resolution Surveys
High resolution site surveys are
conducted to investigate the shallow
sub-surface for geohazards and soil
conditions, as well as to identify
potential benthic biological
communities (or habitats) and
archaeological resources in support of
review and mitigation measures for OCS
exploration and development plans. A
typical operation consists of a vessel
towing an airgun (about 25 m behind
the vessel) and a 600 m (1,968.5 ft)
streamer cable with a tail buoy (about
700 m behind the vessel). Typical
surveys cover one lease block, which is
4.8 km (3 mi) on a side. Including line
turns, the time to survey one block is
about 2 days; however, streamer and
airgun deployment and other operations
may add to the total survey time.
Additional information on seismic
surveys for purposes of G&G exploration
on the OCS in the GOM is contained in
the application, which is available upon
request (see ADDRESSES).
Information Solicited
Interested persons may submit
information, suggestions, and comments
related to BOEMRE’s request (see
ADDRESSES). All information,
suggestions, and comments related to
BOEMRE’s request and NMFS’s
potential development and
implementation of regulations
governing the incidental taking of
marine mammals by the oil and gas
industry’s seismic surveys will be
considered by NMFS in developing, the
most effective regulations governing the
issuance of Letters of Authorization.
Dated: June 8, 2011.
Helen M. Golde,
Deputy Director, Office of Protected
Resources, National Marine Fisheries Service.
[FR Doc. 2011–14742 Filed 6–13–11; 8:45 am]
BILLING CODE 3510–22–P
DEPARTMENT OF COMMERCE
National Telecommunications and
Information Administration
[Docket No. 110207099–1319–02]
[RIN 0660–XA23]
The Internet Assigned Numbers
Authority (IANA) Functions
National Telecommunications
and Information Administration, U.S.
Department of Commerce.
ACTION: Further Notice of Inquiry.
AGENCY:
E:\FR\FM\14JNN1.SGM
14JNN1
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
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 https://www.ntia.doc.
gov/ntiahome/domainname/IANA
FunctionsFNOI.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)
srobinson on DSK4SPTVN1PROD with NOTICES
SUMMARY:
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
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.
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.
General Comments
Some commenters stated that the
IANA functions are performed for the
benefit of the global Internet community
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
https://www.ntia.doc.gov/ntiahome/domainname/
iana.htm.
2 Notice of Inquiry, Request for Comments on the
Internet Assigned Numbers Authority (IANA)
Functions, 76 FR 10569 (Feb. 25, 2011), available
at https://www.ntia.doc.gov/frnotices/2011/
fr_ianafunctionsnoi_02252011.pdf.
3 The comments in their entirety are available for
review on the NTIA’s Web site at https://
www.ntia.doc.gov/comments/110207099-1099-01/.
PO 00000
Frm 00021
Fmt 4703
Sfmt 4703
34659
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 multistakeholder, private sector-led technical
coordination of the DNS.5
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 multi4 See e.g., Cisco Comments at 2 (March 28, 2011),
available at https://www.ntia.doc.gov/comments/
110207099-1099-01/attachments/Cisco.pdf; ictQatar
Comments at 1 (March 30, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=D5E26B75-D14A-40C6-820F7BBD8CC07412; NetChoice Comments at 1 (March
31, 2011), available at https://www.ntia.doc.gov/
comments/110207099-1099-01/attachments/
NetChoice%20on%20IANA%20Contract.pdf;
Shawn Gunnarson at 7 (March 31, 2011), available
at https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=050ECD10-F12C-47E3AE78-793AFE1F67E0.
5 See e.g., Country Code Names Supporting
Organization (ccNSO) Comments at 2 (March 29,
2011), available at https://www.ntia.doc.gov/
comments/110207099-1099-01/attachments/
ACF31A.pdf; Internet Architecture Board (IAB)
Comments at 2 (March 30, 2011), available at
https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=5EBBB0ED-CBE1-44EA9FAF-0AFC662A1534; Internet Society (ISOC)
Comments at 2 (March 30, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
attachments/ISOC%20Response_
Docket%20110207099-1099-01.pdf.
6 See ICANN Comments at 3 (March 25, 2011),
available at https://www.ntia.doc.gov/comments/
110207099-1099-01/attachments/ACF2EF.pdf;
European Telecommunications Network Operators
(ETNO) Comments at 2 (March 31, 2011), available
at https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=0658E8D9-D4A9-4121B7D9-4E26A9587859; Minds and Machines
Comments at 1 (March 31, 2011), available at
https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=994F7CBE-F46D-45B882E1-BABCAE6046A2.
7 See Canadian Internet Registration Authority
(CIRA) Comments at 1 (March 31, 2011), available
at https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=68F1E2E0-5671-4F269770-1701FD41BBE2, Coalition for Online
Accountability (COA) Comments at 2 (March 31,
2011), available at https://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
https://www.ntia.doc.gov/comments/1102070991099-01/attachments/Comments%20of%20the%20
International%20Trademark%20
Association%20%28INTA%29.pdf; Tech Freedom
Comments at 2 (April 1, 2011), available at
https://www.ntia.doc.gov/comments/1102070991099-01/attachments/
IANA%20NOI%20Comments%20-Final.pdf; PayPal
Comments at 1 (March 31, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
attachments/PayPal-NTIA-Response.pdf.
E:\FR\FM\14JNN1.SGM
14JNN1
34660
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
srobinson on DSK4SPTVN1PROD with NOTICES
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
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 multistakeholder 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 multistakeholder environment and be
satisfied that their interests are being
adequately addressed. Resolving this
issue is critical to a strong multistakeholder 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,
8 See China Internet Network Information Center
(CNNIC) Comments at 2 (March 31, 2011), available
at https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=3A835CB9-68ED-4ABFA376-7A4FF0F430A6; Kenya Comments at 2
(March 31, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
attachments/
Kenya%20comments%20on%20Notice%20
of%20Inquiry%20by%20NTIA%20on%20IANA
%20Contract%20v4.pdf; United Arab Emirates
(UAE) Comments at 3 (March 31, 2011), available
at https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=9342F887-C549-4A01AB56-D50F1C7460DF.
9 See e.g., Internet Governance Capacity Building
(IGCBP) 2011 Comments at 1 (March 31, 2011),
available at https://www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=AB73A9F54283-4783-9E10-D547EE1D9179.
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.
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
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.
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
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
https://www.ntia.doc.gov/comments/2008/
ICANN_080730.html.
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.
13 See IAB Comments at 1; ccNSO Comments at
1; ISOC Comments at 2; SIDN Comments at 3 (April
1, 2011), available at https://www.ntia.doc.gov/
comments/110207099-1099-01/attachments/
SIDN%20position%20NTIA%20NoI%20IANA%20
March%202011.pdf; ICANN Comments at 8; The
Number Resource Organization (NRO) Comments at
PO 00000
Frm 00022
Fmt 4703
Sfmt 4703
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
2 (March 31, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=519C0531-4C81-4761-9FCC9AF8D47BC69C.
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 https://
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 https://
www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=8B430831-4634-4A6B-845B97673CD97842.
16 See Bill Manning Comments at 1; Tech
Freedom Comments at 8.
17 See Christopher Wilkinson Comments at 2
(March 30, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
attachments/NTIA_IANA_NOI_2.pdf; Jean-Jacques
Subrenat, Beau Brendler, and Eric BrunnerWilliams Comments at 7 (March 31, 2011), available
at https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=E17DCD8A-B324-49799359-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 https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=7EEEB455-7C85-4B20B7A4-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 https://
www.ntia.doc.gov/comments/110207099-1099-01/
attachments/HKIRC%20Response%20to
%20NTIA%20NoI
%20on%20IANA%20functions.pdf.
E:\FR\FM\14JNN1.SGM
14JNN1
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
srobinson on DSK4SPTVN1PROD with NOTICES
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
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
21 See ISOC Comments at 2; Paul Kane Comments
at 2 (March 30, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
attachments/IANA-NoI.pdf.
22 See Dmitry Burkov Comments at 1 (March 26,
2011), available at https://www.ntia.doc.gov/
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
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
comments/110207099-1099-01/
comment.cfm?e=0922CC0D-62FF-4A91-90A8C87C8CFA9527; 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 https://
www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=0EF012AA-6B7D-4DAC-8E2A8C871A182CC7; IAB Comments at 5; InternetNZ
Comments at 2; Internet Governance Project
Comments at 1 (March 31, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=A9CC728A-75A7-4898-AA6670B6B3656CDD.
25 See ccNSO Comments at 1; Fahd A. Batayneh
Comments at 1 (April 1, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=34B162CD-1B19-470F-B257-
PO 00000
Frm 00023
Fmt 4703
Sfmt 4703
34661
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
BBA8B19991C8; InternetNZ Comments at 2; Federal
Office of Communications (OFCOM) and SWITCH
Comments at 4 (March 31, 2011), available at https://
www.ntia.doc.gov/comments/110207099-1099-01/
attachments/Response-NTIA-IANA-NoI2011_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 https://www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=A3F206A1CDE5-4F2D-BC50-E0FCF9DF384C.
28 See Asia Pacific Top Level Domain Association
(APTLD) Comments at 1 (March 31, 2011), available
at https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=FFB3621F-CC64-4E3392E9-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 https://
www.ntia.doc.gov/comments/110207099-1099-01/
comment.cfm?e=D6DDA78C-3994-4492-A46B9486A5B10798.
30 ccNSO Comments at 3; InternetNZ Comments
at 3; Nominet Comments at 2 (March 30, 2011),
available at https://www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=46E706036139-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 https://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.
E:\FR\FM\14JNN1.SGM
14JNN1
34662
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
srobinson on DSK4SPTVN1PROD with NOTICES
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.
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
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 https://www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=77DDAEE0C79B-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.
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
PO 00000
Frm 00024
Fmt 4703
Sfmt 4703
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
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
36 Commenters believed that Questions 2, 3, 4,
and 5 were closely related. See e.g., ccNSO
Comments at 4; CENTR Comments at 3.
37 See ARIN Comments at 3–4 (March 31, 2011),
available at https://www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=9BEFA8A5655F-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 https://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 https://www.ntia.doc.gov/comments/
110207099-1099-01/comment.cfm?e=7669299A100A-4A45-AEC7-E236AA41E643; AFNIC
Comments at 3 (March 31, 2011), available at
https://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=513BA51F-85C2-43BDB6EB-E50F5DC724BD; CENTR Comments at 3;
Kenya at 3.
E:\FR\FM\14JNN1.SGM
14JNN1
srobinson on DSK4SPTVN1PROD with NOTICES
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
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
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
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.
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
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 https://www.ntia.doc.gov/DNS/
CurrentProcessFlow.pdf.
47 See ccNSO Comments at 4; AFNIC Comments
at 2.
PO 00000
Frm 00025
Fmt 4703
Sfmt 4703
34663
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
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
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.
E:\FR\FM\14JNN1.SGM
14JNN1
34664
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
srobinson on DSK4SPTVN1PROD with NOTICES
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
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.
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
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.
NTIA will incorporate it into the
procurement process for the IANA
functions contract.
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,
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
56 See
PO 00000
InternetNZ Comments at 5.
Frm 00026
Fmt 4703
Sfmt 4703
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.
E:\FR\FM\14JNN1.SGM
14JNN1
srobinson on DSK4SPTVN1PROD with NOTICES
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
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
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
PO 00000
Frm 00027
Fmt 4703
Sfmt 4703
34665
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 endusers 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
E:\FR\FM\14JNN1.SGM
14JNN1
34666
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
srobinson on DSK4SPTVN1PROD with NOTICES
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
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
PO 00000
Frm 00028
Fmt 4703
Sfmt 4703
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
E:\FR\FM\14JNN1.SGM
14JNN1
Federal Register / Vol. 76, No. 114 / Tuesday, June 14, 2011 / Notices
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.
srobinson on DSK4SPTVN1PROD with NOTICES
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
VerDate Mar<15>2010
16:27 Jun 13, 2011
Jkt 223001
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
PO 00000
Frm 00029
Fmt 4703
Sfmt 4703
34667
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
COMMODITY FUTURES TRADING
COMMISSION
SECURITIES AND EXCHANGE
COMMISSION
[Release No. 34–64638; File Nos. 4–633 and
S7–39–10]
Joint Public Roundtable on Proposed
Dealer and Major Participant
Definitions of Title VII of the DoddFrank Wall Street Reform and
Consumer Protection Act
Commodity Futures Trading
Commission (‘‘CFTC’’) and Securities
and Exchange Commission (‘‘SEC’’)
(each, an ‘‘Agency,’’ and collectively,
the ‘‘Agencies’’).
ACTION: Notice of roundtable discussion;
request for comment.
AGENCIES:
On Thursday, June 16, 2011,
commencing at 9 a.m. and ending at
3:45 p.m., staff of the Agencies will hold
a public roundtable meeting at which
invited participants will discuss various
issues related to the proposed
definitions of the terms ‘‘swap dealer,’’
‘‘security-based swap dealer,’’ ‘‘major
swap participant,’’ and ‘‘major securitybased swap participant’’ under Title VII
of the Dodd-Frank Wall Street Reform
and Consumer Protection Act (the
‘‘Act’’). See 75 FR 80174 (Dec. 21, 2010).
The discussion will be open to the
public with seating on a first-come, firstserved basis. Members of the public may
also listen to the meeting by telephone.
Call-in participants should be prepared
to provide their first name, last name
and affiliation. The information for the
conference call is set forth below.
• U.S. Toll-Free: (866) 844–9416.
• International Toll: information on
international dialing can be found at the
following link: https://www.cftc.gov/
PressRoom/PressReleases/
internationalnumbers021811.html.
• Conference ID: 7731946.
A transcript of the public roundtable
discussion will be published at https://
www.cftc.gov/PressRoom/Events/2011/
index.htm. The roundtable discussion
will take place in the Conference Center
at the CFTC’s headquarters, Three
SUMMARY:
E:\FR\FM\14JNN1.SGM
14JNN1
]]>Agencies
[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 https://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
https://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 https://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 https://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
https://www.ntia.doc.gov/comments/110207099-1099-01/attachments/Cisco.pdf; ictQatar Comments at 1 (March 30, 2011), available at
https://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 https://www.ntia.doc.gov/comments/110207099-1099-01/attachments/NetChoice%20on%20IANA%20Contract.pdf; Shawn Gunnarson at 7 (March
31, 2011), available at https://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 https://www.ntia.doc.gov/comments/110207099-1099-01/attachments/ACF31A.pdf;
Internet Architecture Board (IAB) Comments at 2 (March 30, 2011),
available at https://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 https://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
https://www.ntia.doc.gov/comments/110207099-1099-01/attachments/
ACF2EF.pdf; European Telecommunications Network Operators (ETNO)
Comments at 2 (March 31, 2011), available at https://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 https://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 https://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 https://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 https://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
https://www.ntia.doc.gov/comments/110207099-1099-01/attachments/IANA%20NOI%20Comments%20-Final.pdf; PayPal Comments at 1 (March 31,
2011), available at https://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 https://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 https://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 https://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 https://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 https://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
https://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
https://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
https://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 https://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 https://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--T
