The Internet Assigned Numbers Authority (IANA) Functions, 34658-34667 [2011-14762]

Download as PDF 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 http://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 http://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 http://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 http:// 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 http://www.ntia.doc.gov/comments/ 110207099-1099-01/attachments/Cisco.pdf; ictQatar Comments at 1 (March 30, 2011), available at http:// www.ntia.doc.gov/comments/110207099-1099-01/ comment.cfm?e=D5E26B75-D14A-40C6-820F7BBD8CC07412; NetChoice Comments at 1 (March 31, 2011), available at http://www.ntia.doc.gov/ comments/110207099-1099-01/attachments/ NetChoice%20on%20IANA%20Contract.pdf; Shawn Gunnarson at 7 (March 31, 2011), available at http://www.ntia.doc.gov/comments/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 http://www.ntia.doc.gov/ comments/110207099-1099-01/attachments/ ACF31A.pdf; Internet Architecture Board (IAB) Comments at 2 (March 30, 2011), available at http://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=5EBBB0ED-CBE1-44EA9FAF-0AFC662A1534; Internet Society (ISOC) Comments at 2 (March 30, 2011), available at http:// www.ntia.doc.gov/comments/110207099-1099-01/ attachments/ISOC%20Response_ Docket%20110207099-1099-01.pdf. 6 See ICANN Comments at 3 (March 25, 2011), available at http://www.ntia.doc.gov/comments/ 110207099-1099-01/attachments/ACF2EF.pdf; European Telecommunications Network Operators (ETNO) Comments at 2 (March 31, 2011), available at http://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=0658E8D9-D4A9-4121B7D9-4E26A9587859; Minds and Machines Comments at 1 (March 31, 2011), available at http://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 http://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 http://www.ntia.doc.gov/ comments/110207099-1099-01/comment.cfm?e= 68F1E2E0-5671-4F26-9770-1701FD41BBE2; International Trade Mark Association (INTA) Comments at 3 (March 31, 2011), available at http://www.ntia.doc.gov/comments/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 http://www.ntia.doc.gov/comments/1102070991099-01/attachments/ IANA%20NOI%20Comments%20-Final.pdf; PayPal Comments at 1 (March 31, 2011), available at http:// www.ntia.doc.gov/comments/110207099-1099-01/ attachments/PayPal-NTIA-Response.pdf. 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 http://www.ntia.doc.gov/comments/1102070991099-01/comment.cfm?e=3A835CB9-68ED-4ABFA376-7A4FF0F430A6; Kenya Comments at 2 (March 31, 2011), available at http:// 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 http://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 http://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 http://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 http://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 http:// 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 http:// 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:// 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 http:// 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 http://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 http://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 http:// 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 http:// www.ntia.doc.gov/comments/110207099-1099-01/ attachments/IANA-NoI.pdf. 22 See Dmitry Burkov Comments at 1 (March 26, 2011), available at http://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 http:// 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 http:// 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 http:// 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 http:// 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 http://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 http://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 http:// 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 http://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 http://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 http://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 http://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 http://www.ntia.doc.gov/ comments/110207099-1099-01/attachments/ NTIA%20NOI%20on%20IANA.pdf. 39 See ARIN Comments at 3; ccNSO Comments at 4; CNNIC at 1; InternetNZ Comments at 5; Kenya Comments at 3; SIDN Comments at 5. 40 See ccNSO Comments at 4; SIDN Comments at 5. 41 See ALAC Comments at 7 (March 31, 2011), available at http://www.ntia.doc.gov/comments/ 110207099-1099-01/comment.cfm?e=7669299A100A-4A45-AEC7-E236AA41E643; AFNIC Comments at 3 (March 31, 2011), available at http://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 http://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: http://www.cftc.gov/ PressRoom/PressReleases/ internationalnumbers021811.html. • Conference ID: 7731946. A transcript of the public roundtable discussion will be published at http:// 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 http://www.ntia.doc.gov/ntiahome/domainname/IANAFunctionsFNOI.html.

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

SUPPLEMENTARY INFORMATION: Critical to the Internet DNS is the 
continued performance of the IANA functions. The IANA functions have 
historically included: (1) The coordination of the assignment of 
technical Internet protocol parameters; (2) the administration of 
certain responsibilities associated with Internet DNS root zone 
management; (3) the allocation of Internet numbering resources; and (4) 
other services related to the management of the ARPA and INT TLDs. 
ICANN currently performs the IANA functions, on behalf of the United 
States Government, through a contract with NTIA. The current contract 
is set to expire on September 30, 2011.\1\
---------------------------------------------------------------------------

    \1\ The current contract has an option to extend the performance 
period for an additional six months. If necessary, NTIA will 
exercise this option in order to complete the contract procurement 
process. The current contract is available on NTIA's Web site at 
http://www.ntia.doc.gov/ntiahome/domainname/iana.htm.
---------------------------------------------------------------------------

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

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

Comment Summary and Policy Discussion

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

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

General Comments

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

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

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

[[Page 34660]]

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

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

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

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

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

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

Question 1: The IANA functions have been viewed historically as a set 
of interdependent technical functions and accordingly performed 
together by a single entity. In light of technology changes and market 
developments, should the IANA functions continue to be treated as 
interdependent? For example, does the coordination of the assignment of 
technical protocol parameters need to be done by the same entity that 
administers certain responsibilities associated with root zone 
management? Please provide specific information to support why or why 
not, taking into account security and stability issues.

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

[[Page 34661]]

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

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

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

Question 2: The performance of the IANA functions often relies upon the 
policies and procedures developed by a variety of entities within the 
internet technical community such as the IETF, the RIRS and CCTLD 
operators. Should the IANA functions contract include references to 
these entities, the policies they develop and instructions that the 
contractor follow the policies? Please provide specific information as 
to why or why not. If yes, please provide language you believe 
accurately captures these relationships.

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

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

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

Question 3: Cognizant of concerns previously raised by some governments 
and CCTLD operators and the need to ensure the stability of and 
security of the DNS, are there changes that could be made to how root 
zone management requests for CCTLDS are processed? Please provide 
specific information as to why or why not. If yes, please provide 
specific suggestions.

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

[[Page 34662]]

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

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

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

Question 4: Broad performance metrics and reporting are currently 
required under the contract. Are the current metrics and reporting 
requirements sufficient? Please provide specific information as to why 
or why not. If not, what specific changes should be made? \36\
---------------------------------------------------------------------------

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

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

[[Page 34663]]

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

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

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

Question 5: Can process improvements or performance enhancements be 
made to the IANA functions contract to better reflect the needs of 
users of the IANA functions to improve the overall customer experience? 
Should mechanisms be employed to provide formalized user input and/or 
feedback, outreach and coordination with the users of the IANA 
functions? Is additional information related to the performance and 
administration of the IANA functions needed in the interest of more 
transparency? Please provide specific information as to why or why not. 
If yes, please provide specific suggestions.

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

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

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

[[Page 34664]]

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

Question 6: Should additional security considerations and/or 
enhancements be factored into requirements for the performance of the 
IANA functions? Please provide specific information as to why or why 
not. If additional security considerations should be included, please 
provide specific suggestions.

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

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

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

Draft Statement of Work (Draft SOW)

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

C.1 Background

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

C.2 Contractor Requirements

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

[[Page 34665]]

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

[[Page 34666]]

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

C.3 Security Requirements

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

C.4 Performance Metric Requirements

    C.4.1 Monthly Performance Progress Report--T