Fiona M. Alexander Associate Administrator Office of International Affairs National Telecommunications and Information Administration U.S. Department of Commerce 1401 Constitution Avenue, N.W. Room 4701 Washington, DC 20230 IANAFunctions@ntia.doc.gov American Registry for Internet Numbers response to Department of Commerce National Telecommunications and Information Administration [Docket No. 110207099?1099?01] RIN 0660?XA23 Request for Comments on the Internet Assigned Numbers Authority (IANA) Functions Dear Ms. Alexander, The American Registry for Internet Numbers (ARIN) welcomes the opportunity to comment on the Internet Assigned Numbers Authority functions through the Notice of Inquiry process. We offer the following comments towards enhancing the performance of the IANA functions. ARIN, the Regional Internet Registry (RIR) serving United States, Canada, and parts of the Caribbean, was established in 1997. We provide services related to the technical coordination and management of Internet number resources in our respective region. This includes, but is not limited to, facilitating the development of Internet number resource policy for our region, implementing number resource policies, and actively representing the interests of number resource users in the global Internet community. It is from this perspective and experience that we offer our comments. It is no surprise that NTIA would undertake a comprehensive review of the IANA functions, given the IANA functions are an essential piece of the overall foundation of the Internet. No one would disagree that the Internet has grown and evolved significantly since the first IANA functions contract in 2000. With this success comes a more diverse global community of stakeholders with new concerns and expectations. In order to continue to build confidence in the Internet, it is critical that the IANA functions be managed in a way that is open, transparent and globally accountable. This comprehensive review is just one step in the eventual internationalization of oversight of the IANA functions. 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. Due to the interconnected nature of the Internet?s infrastructure services, the various technical tasks covered by the IANA functions contract benefit from being performed by a single entity. While individual technical tasks (such as root zone changes, DNS protocol changes, and routing infrastructure changes) may theoretically be performed independently, the potential consequences of conflicting changes suggest that joint coordination of changes to these critical functions would minimize risk. While joint coordination does not require joint delivery by a single entity, the NTIA should not separate performance of these functions. The synergies achieved through joint performance of technical functions may also include tasks not covered by the IANA functions contract. In any subsequent IANA agreement, the NTIA should clearly state that the IANA contractor may perform additional related tasks at the request of other parties on behalf of the Internet community (e.g. performance of IN-ADDR.ARPA zone maintenance, or RPKI publication of digitally-signed number resource information.) Additionally, the NTIA should expressly provide assurances that any such activities will not be construed to be under scope of the NTIA IANA agreement as long as they do not specifically conflict with existing IANA contract tasks. More generally, the scope of the NTIA IANA functions agreement and tasks contained therein should not be expanded by NTIA under any condition. Additionally, given the ongoing evolution of the USG oversight in this area, we believe that a cooperative agreement for IANA functions would be a more appropriate structure than the present contracting approach. While we appreciate the historical role of the US Government in providing oversight of these important functions, it is crucial that the Internet community work to enhance multi-stakeholder international mechanisms for the development of the policies used to guide the administration of these technical tasks. In particular, the ICANN model (a privately-led, not-for-profit and community-driven organization) appears most suitable to ensure an effective Internet governance scheme accountable to all its multiple stakeholders (public, private, and civil society). The Internet technical community is quite capable of directly working in partnership with ICANN so as to provide oversight of the policy development organizations as well as the provision of the related technical functions. 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. The IANA functions contract should explicitly note, by name, the organizations that are served by IANA. For example, ?IANA should perform number resource management according to the global policies that are collectively developed by the Regional Internet Registries (AfriNIC, APNIC, ARIN, LACNIC, RIPE NCC)? or ?IANA should perform technical parameter management according to the technical standard guidance provided by the IETF.? Furthermore, the IANA functions contract should require that the future contractor of IANA functions enter into agreements with these IANA-served organizations regarding appropriate service management interfaces, including service levels and escalation processes. 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. In order to instill confidence in the management of the DNS and ensure the success of the ICANN model, all requests should be performed in as open and transparent a method as possible. 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? It is difficult to judge the effectiveness of these metrics and reporting requirements, as it does not appear that these reports are generally available. In order to ensure the metrics are sufficient, constituencies affected by the performance of the IANA functions (e.g. DNS TLD Registries, Regional Internet Registries, IETF) should review the current metrics for possible modification. The performance results, to the greatest extent possible, should be shared publicly. It is understood that there may be sensitive information from time to time that should not be made public, and we support redacting such information. However, we ask that the performance reports be made public and readily available for all tasks covered by the contract. 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. While we are generally very satisfied with current performance of the IANA functions, we believe there may be room for improvement. Polling each organization that directly interacts with the IANA functions (e.g. DNS Registries, Regional Internet Registries, IETF) annually would allow them to comment on their experience. The feedback received, including any contractor response to that feedback, should generally be made publicly available, subject to the editing of sensitive information. 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. Given the wide variety of potential risks, we encourage any organization associated with the performance of the IANA function to continue to take all reasonable steps necessary to ensure all data is protected via appropriate security measures per best common practices. The constantly changing cyber security landscape makes it impractical to embed specific requirements in a multiple-year contract. Any contractor should arrange for periodic review of each IANA function area by a qualified organization (which should include security expertise external to the organization). The purpose of the review would be to identify any security risks resulting from an organization?s performance and to make appropriate recommendations to correct. The organization performing the IANA functions should report to NTIA and IANA-served organizations on the risks and recommendations as well as the follow-up actions that will be undertaken. Sincerely, John Curran President and CEO American Registry for Internet Numbers