2011-14762. The Internet Assigned Numbers Authority (IANA) Functions

AGENCY:

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

ACTION:

Further Notice of Inquiry.

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 [e-mail]. 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: [phone]; e-mail: [e-mail]. Please direct media inquiries to the Office of Public Affairs, NTIA, at [phone].

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 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]

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-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 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]

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 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 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] 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 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 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 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]

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 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 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]

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 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]

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 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 compliance with approved performance standards and metrics. The performance of this function shall be in compliance with the performance exclusions as enumerated in Section C.6.

C.2.2.1.5 Other services—The Contractor shall perform other IANA functions, including the management of the INT and ARPA TLDs. The Contractor shall also implement modifications in performance of the IANA functions as needed upon mutual agreement of the parties. The performance of this function shall be in compliance with the performance exclusions as enumerated in Section C.6.

C.2.2.1.5.1 ARPA TLD—The Contractor shall operate the ARPA TLD within the current registration policies for the TLD, including RFC 3172. The Contractor shall be responsible for implementing DNSSEC in the ARPA TLD consistent with the requirements of the relevant stakeholders for this function and approved by NTIA. Within six (6) months of award, the Contractor shall submit to NTIA performance standards and metrics developed in collaboration with relevant stakeholders. Upon approval by the COTR, the Contractor shall perform this task in compliance with approved performance standards and metrics.

C.2.2.1.5.2 INT TLD—The Contractor shall operate the INT TLD within the current registration policies for the TLD. Upon designation of a successor registry, if any, the Contractor shall use commercially reasonable efforts to cooperate with NTIA to facilitate the smooth transition of operation of the INT TLD. Such cooperation shall, at a minimum, include timely transfer to the successor registry of the then-current top-level domain registration data.

C.3 Security Requirements

C.3.1 Secure Systems—The Contractor shall install and operate all computing and communications systems in accordance with best business and security practices. The Contractor shall implement a secure system for authenticated communications between it and its customers when carrying out all IANA function requirements within nine (9) months after date of contract award. The Contractor shall document practices and configuration of all systems.

C.3.2 Secure Systems Notification—Within nine (9) months after date of contract award, the Contractor shall implement and thereafter operate and maintain a secure notification system at a minimum, capable of notifying all relevant stakeholders of the discrete IANA functions, of such events as outages, planned maintenance, and new developments.

C.3.3 Secure Data—The Contractor shall ensure the authentication, integrity, and reliability of the data in performing the IANA requirements, including the data relevant to DNS, root zone change request, and IP address allocation.

C.3.4 Computer Security Plan—The Contractor shall develop and execute a Security Plan. The plan shall be developed and implemented within nine (9) months after date of contract award, and updated annually. The Contractor shall deliver the plan to the Government annually.

C.3.5 Director of Security—The Contractor shall designate a Director of Security who shall be responsible for ensuring technical and physical security measures, such as personnel access controls. The Contractor shall notify and consult in advance the COTR when there are personnel changes in this position.

C.3.6 Contingency and Continuity of Operations Plan (The CCOP)—The Contractor shall, in collaboration with relevant stakeholders, develop and implement a CCOP for the IANA functions within nine (9) months after date of contract award. The Contractor shall update and exercise the plan annually. The CCOP shall include details on plans for continuation of the IANA functions in the event of a logical or physical attack or emergency. The Contractor shall deliver the CCOP to the Government annually.

C.4 Performance Metric Requirements

C.4.1 Monthly Performance Progress Report—The Contractor shall prepare and submit to the COTR a performance progress report every month (no later than 15 calendar days following the end of each month) that contains statistical and narrative information on the performance of the IANA functions (i.e., assignment of technical protocol parameters administrative functions associated with root zone management and allocation of Internet numbering resources) during the previous 30-day period. The report shall include a narrative summary of the work performed for each of the functions with appropriate details and particularity. The report shall also describe major events, problems encountered, and any projected significant changes, if any, related to the performance of duties set forth in Section C.2.

C.4.2 Root Zone Management Dashboard—The Contractor shall collaborate with NTIA and VeriSign, Inc., (or any successor entity as designated by the U.S. Department of Commerce) to develop and make available a dashboard to track the process flow for root zone management within nine (9) months after date of contract award.

C.4.3 Performance Standards Metrics Reports—The Contractor shall develop and publish consistent with the developed performance standards and metrics reports for each discrete IANA function consistent with Section C.2. The Performance Standard Metric Reports will be published every month (no later than 15 calendar days following the end of each month) starting no later than nine (9) months after date of contract award.

C.4.4 Performance Survey—The Contractor shall develop and conduct an annual performance survey consistent with the developed performance standards and metrics for each of the discrete IANA functions. The survey shall include a feedback section for each discrete IANA function. The Contractor shall publish the Survey Report annually on its Web site.

C.4.5 Final Report—The Contractor shall prepare and submit a final report on the performance of the IANA functions that documents standard operating procedures, including a description of the techniques, methods, software, and tools employed in the performance of the IANA functions. The Contractor shall submit the report to the Contracting Officer and the COTR no later than 30 days after expiration of the purchase order.

C.5 Audit Requirements

C.5.1 Audit Data—The Contractor shall generate and retain security process audit record data for one year and provide an annual audit report to the Contracting Officer and the COTR. All root zone management operations shall be included in the audit, and records on change requests to the root zone file and the Contractor shall retain these records. The Contractor shall provide specific audit record data to the Contracting Officer and COTR upon request.

C.5.2 Root Zone Management Audit Data—The Contractor shall generate a monthly (no later than 15 calendar days following the end of each month) audit report based on information in the performance of Provision C.2.2.1.3 Perform Administrative Functions Associated With Root Zone Management. The audit report shall track each root zone change request and identify the relevant policy under which the change was made as well as track change rejections and identify the relevant policy under which the change request was rejected starting no later than nine (9) months after date of contract award.

C.5.3 External Auditor—The Contractor shall have an external, independent, specialized compliance auditor conduct an audit of the IANA functions security provisions annually.

C.6 Performance Exclusions

C.6.1 This purchase order, in itself, does not authorize modifications, additions, or deletions to the root zone file or associated information. (This purchase order does not alter the root zone file responsibilities as set forth in Amendment 11 of the Cooperative Agreement NCR-9218742 between the DoC and VeriSign, Inc.)

C.6.2 This purchase order, in itself, does not authorize the Contractor to make material changes in the policies and procedures developed by the relevant entities associated with the performance of the IANA functions. The Contractor shall not change or implement the established methods associated with the performance of the IANA functions without prior approval of the COTR.

C.6.3 The performance of the functions under this contract, including the development of recommendations in connection with processing changes that constitute delegations and redelegations of ccTLDs, shall not be, in any manner, predicated or conditioned on the existence or entry into any contract, agreement or negotiation between the Contractor and any party requesting such changes or any other third-party.

Questions Related to the Draft SOW

The public is invited to comment on any aspect of the Draft SOW including, but not limited to, the specific questions set forth below. When responding to specific questions, please cite the number(s) of the questions addressed, the “section” of the Draft SOW to which the question(s) correspond, and provide any references to support the responses submitted.

1. Does the language in “Provision C.1.3” capture views on how the relevant stakeholders as sources of the policies and procedures should be referenced in the next IANA functions contract. If not, please propose specific language to capture commenters' views.

2. Does the new “Provision C.2.2.1.1” adequately address concerns that the IANA functions contractor should refrain from developing policies related to the IANA functions? If not, please provide detailed comments and specific suggestions for improving the language.

3. Does the language in “Provisions C.2.2.1.2, C.2.2.1.3, C.2.2.1.4, and C.2.2.1.5” adequately address concerns that the IANA functions contractor should perform these services in a manner that best serves the relevant stakeholders? If not, please propose detailed alternative language.

4. Does the language in “Provision C.2.2.1.3” adequately address concerns related to root zone management? If not, please suggest detailed alternative language. Are the timeframes for implementation reasonable?

5. Does the new “Provision C.2.2.1.3.2 Responsibility and Respect for Stakeholders” adequately address concerns related to the root zone management process in particular how the IANA functions contractor should document its decision making with respect to relevant national laws of the jurisdiction which the TLD registry serves, how the TLD reflects community consensus among relevant stakeholders and/or is supported by the global public interest. If not, please provide detailed suggestions for capturing concerns. Are the timeframes for implementation reasonable?

6. Does the new “Section C.3 Security Requirements” adequately address concerns that the IANA functions contractor has a secure communications system for communicating with service recipients? If not, how can the language be improved? Is the timeframe for implementation reasonable?

7. Does the new “Provision C.2.2.1.3.5 Customer Service Complaint Resolution Process” provide an adequate means of addressing customer complaints? Does the new language provide adequate guidance to the IANA functions contractor on how to develop a customer complaint resolution? If not, please provide detailed comments and suggestions for improving the language.

8. Does the new “Provision C.3.6 Contingency and Continuity of Operations Plan (CCOP)” adequately address concerns regarding contingency planning and emergency recovery? If not, please provide detailed comments and suggestions for improving the language. Are the timeframes for implementation reasonable?

9. Does the new “Section C.4 Performance Standards Metric Requirements” adequately address concerns regarding transparency in root zone management process, and performance standards and metrics? Should the contractor be required to gather and report on statistics regarding global IPv6 and DNSSEC deployment? If so, how should this requirement be reflected in the SOW? What statistics should be gathered and made public?

10. Does the new “Section C.5 Audit Requirements” adequately address concerns regarding audits? If not, please propose alternative language. Are the timeframes for implementation reasonable?

Dated: June 9, 2011.

Lawrence E. Strickling,

Assistant Secretary for Communications and Information.

Footnotes

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/​.

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.

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.

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.

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%20March%202011.pdf;​; ICANN Comments at 8; The Number Resource Organization (NRO) Comments at 2 (March 31, 2011), available at http://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://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-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://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://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://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://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://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/​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://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://www.ntia.doc.gov/​comments/​110207099-1099-01/​comment.cfm?​e=​A9CC728A-75A7-4898-AA66-70B6B3656CDD.

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-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-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://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://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://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://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://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://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.

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=​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.

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.

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.