Statement of the ALAC on the US National Telecommunications and Information Administration (NTIA) Notice of Inquiry (NOI)
Introduction
By the Staff of ICANN
Dr. Olivier Crépin-Leblond, Chair of the At-Large Advisory Committee (ALAC) originally composed this statement based on archived documents of the ALAC as well as wide input from the five Regional At-Large Organizations (RALOs).
A wiki workspace on the NTIA NOI, including a time-line for comments, was announced on 17 March 2011 on an At-Large Group Skype Chat during the 40th ICANN Meeting held in San Francisco. Following a call for comments on the ALAC-Announce mailing list which was posted on 18 March 2011, Dr. Crépin-Leblond drafted a first version of the ALAC Statement on the NTIA NOI which was discussed during an ALAC Executive Committee call on 24 March. Following this call and the addition of significant community input a second version was created.
On 26 and 27 March 2011, further calls for comments were posted on the ALAC-Working list. Following the incorporation of these comments, a third version (the present document) was created.
On 28 March 2011, Dr. Crépin-Leblond requested the At-Large Staff to begin a three day ALAC vote on this statement.
The original version of this document is the English text available at www.atlarge.icann.org/correspondence. Where a difference of interpretation exists or is perceived to exist between a non‐English edition of this document and the original text, the original shall prevail.
Page 1 of 8
[End of Introduction]
Statement of the ALAC on the US National Telecommunications and Information Administration Notice of Inquiry
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,shouldtheIANAfunctionscontinuetobetreatedasinterdependent? Forexample,doesthe 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.
Historically, the IANA functions have included (but not been limited to):
1. 2. 3. 4.
The coordination of the assignment of technical Internet protocol parameters; the administration of certain responsibilities associated with Internet DNS root zone management; the allocation of Internet numbering resources; and other services related to the management of the .ARPA and .INT top-level domains.
The IANA makes technical decisions concerning root servers, determines qualifications for applicants to manage country code TLDs, assigns unique protocol parameters, and manages the IP address space, including delegating blocks of addresses to registries around the world.
The responsibilities encompassed within the IANA functions require cooperation and coordination with a variety of technical groups and stakeholder communities. For example, protocol parameters are developed through and overseen by groups such as the Internet Engineering Task Force (IETF) and the Internet Architecture Board (IAB), policies and procedures associated with Internet DNS root zone management are developed by a variety of actors (e.g., the Internet technical community, ccTLD operators, and governments) and continue to evolve, and policies and procedures related to Internet numbering resources are developed within the RIRs.
Since February 2000, The Internet Corporation for Assigned Names and Numbers (ICANN) performs the IANA functions, on behalf of the U.S. Government, through a contract with NTIA.
ICANN should continue performing these functions for the following reasons: Experience, maturity and know-how
The ICANN, as a single entity, has so far led the IANA functions with all the seriousness possible and has respected the contract with the US Government to the letter.
Page 2 of 8
Security and Stability
The IANA functions led by ICANN have proved its independence from Governments lobbies, thereby confirming the security, stability and success of the Internet. We fear that these functions led by any other entity might fragment or otherwise "break" the Internet.
Independence has brought development.
The Internet has grown rapidly and serves millions of users; one of the reasons of its success is that ICANN has so far undertaken the IANA functions in all independence. This has prevented any one entity or government from "capturing” the Internet
Central Administration and Co-ordination.
The administration of DNS names and numeric addresses is a notable exception to the principle of distributed management because the current technology requires some central administration and coordination functions. ICANN performs this function well.
Internet Self Regulation and ICANN’s Collaborative Model.
ICANN plays an important role in the self-regulation characteristic of the Internet, and in coordinating certain aspects of the collaborative Internet model. ICANN is an essential organization that helps manage and administer various functions of the Internet’s development and management including the IANA functions.
A separation of the tasks described above would only risk triggering a compartmentalization of those functions into silos, with incoherent collaboration brought forth by those silos. Most of these functions have a heavy element of cross-synchronization of tasks and this would be lost if the functions were separated into different organizations.
As a result, the logic that tasks under the IANA function are interdependent remains compelling. We cannot find a rationale for separation of the tasks that would inure to better management, more sure-footed coordination or greater stability and availability of internet resources.
At this point in time, there is no advantage to have the functions separated. There may be reasonable argument to separate them in the future but leaving them interdependent while following the multi- stakeholder model.
Page 3 of 8
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 challenge is to internationalize the management of the domain name system in furtherance of the greater global public interest. Membership in the named technical communities is drawn from every area and region of the globe. It would be useful to note that the Internet is THE enabler of the work processes and acculturation of these communities of practice. To the extent that the IANA functions are central to the stability, availability and continued expansion of a global interoperable Internet and to the extent that we embrace the Internet as a critical global public infrastructure and public goods, a thoughtful recognition of these communities to names and numbers administration would inure to greater opportunities for internationalization. Contractual references and obligations to the output of these and like communities whose work significantly impact continued stability, availability and internationalization of the domain name system, is a good move, but only under specific conditions.
Any contract would make references to the different entities but should not summon to follow the different policies developed by the entities in question. The IANA functions contract should ONLY include references to the entities such as the IETF, the RIRs and ccTLD operators but NOT policies that these entities should develop, neither the instructions that the contractor should follow these policies.
Further, given the operational culture and open policy-making framework that are definitive attributes of these communities, this action will add a quotient of transparency to the functional administration of IANA.
The success of the Internet lies in the fact that it is characterized by a minimum of regulation or by self- regulation. The public in general should never have the impression that the US Government is trying to influence the policies of the entities through the IANA functions. Most of all, if any contractual arrangements were drawn up, they should not become an over-bearing burden.
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 consistence with the ALAC comments on Question 1, ICANN should ensure the stability and security of the DNS, particularly in the management of root zone. If IANA functions continue to be performed by ICANN, they should be viewed in the framework of the Affirmation of Commitments (AoC) that persistently pursue the
Page 4 of 8
goals of internationalization, accountability and transparency. Currently the approval process by the DoC of the US Government in respect of requests of change of root zone records is hardly consistent with the above- mentioned goals. It may be suggested that the DoC’s approval process be eliminated including but not limited to ccTLD request of change process.
It is important that root zone administration not only acknowledge the existence of a larger pool of stakeholders but develop effective mechanisms to engage them in the policy development and implementation process. With regard to re-delegation and while there is a policy statement that recognizes a "local internet community", we have not seen from our experience much in the way of engaging a broader cross-section of this "local internet community". The public interest is underserved if the relevant IANA functionary does not improve its apprehension of the constituents of the "local internet community" and develop - or cause to be developed - an effective mechanism to engage this community in re-delegation matters.
At present, the process of ccTLD re-delegation is a very opaque one. We believe that it deserves special treatment due to its international nature and because it is often likely to affect local communities, sometimes in a potentially very negative way.
Some of our members’ wishes are that in the interest of increased accountability, the process should be made more transparent, as follows:
Full details of a request to IANA for ccTLD re-delegation should be published, so as to show details of the authority asking for the re-delegation request.
The re-delegation request should have the support of the local community. We suggest that there should be a public comment period associated with the re-delegation request, so as to obtain information about local support.
An element of accountability to the local community should be asked from the requestor; simply being a government entity does not show enough accountability. We suggest that one element of such accountability be shown through the Governmental Advisory Committee (GAC).
That said, we fully support the Final Report of the Delegation, Re-delegation and Retirement Working Group of the ccNSO (http://ccnso.icann.org/workinggroups/final-report-drd-wg-17feb11-en.pdf) which recommends: “...as a first step, the ccNSO Council undertakes the development of a "Framework of Interpretation" for the delegation and re-delegation of ccTLDs. This framework should provide a clear guide to IANA and the ICANN Board on interpretations of the current policies, guidelines and procedures relating to the delegation and re- delegation of ccTLDs.
Page 5 of 8
The results of the use of such a Framework of Interpretation should be formally monitored and evaluated by the ccNSO Council after a pre-determined period. If the results of this evaluation indicate that the Framework of Interpretation failed to provide logical and predictable outcomes in ICANN decision making, the ccNSO Council should then launch PDPs on the delegation and re-delegation of ccTLDs.”
Furthermore, while ICANN is yet to fully realize its potential as a bottom-up multi-stakeholder policy development organization, we envisage a time when its role in the process for root zone management as defined in (http://www.ntia.doc.gov/DNS/CurrentProcessFlow.pdf) might be expanded to encompass the role of the Administrator, in addition to its current role as the IANA Functions Operator, provided that ICANN has established a process for the role of the Administrator that is accountable, transparent and serves the global public interest.
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?
The current metrics provide a good starting point. Improved, more detailed and easily comprehensible reporting would assist in facilitating stakeholder awareness and understanding of the performance of the IANA function, leading to greater stakeholder confidence, as well as improved mechanisms to perform comparative evaluation.
Our suggestions would include:
1. The development of a set of further performance metrics aspired from the AoC, with a periodic review process of the IANA function. The audit mechanism should be made as public as possible.
2. The development of a set of automatic performance tools under the banner “e-IANA” which will collect and collate regular performance reports and statistics from the Root Zone. This is related to our response to Question 5.
3. The development of an up to date database containing all information regarding disaster management
The resulting performance metrics should include detailed documentation explaining the root zone management function in the official UN languages, and be widely publicized.
Page 6 of 8
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.
Strictly speaking, improvements to the IANA function would be limiting their scope if set into a contract.
We therefore suggest an out of contract continuous self-appraisal process with mid-point review of improvements using the robust multi-stakeholder review process used in ICANN Reviews. This multi- stakeholder model can be utilized, to provide a framework to analyze the issues requiring improvement and create an environment for making consistent and predictable decision, as illustrated in the Final Report of the Delegation, Re-delegation and Retirement Working Group of the ccNSO. (http://ccnso.icann.org/workinggroups/final-report-drd-wg-17feb11-en.pdf)
This improvement process is directly related to our answer in Question 3, whereby the transparency of the IANA Functions Operator in the processing of the delegation and re-delegation of ccTLDs should be improved as the decisions taken by IANA directly affect the local Internet community stakeholders governed by the ccTLD.
To this effect, an “e-IANA” function should be enabled to automate many of the tasks currently performed by IANA and to compartmentalize those functions.
In particular, automated processes should be in place for: adding a new gTLD entry updating of contact details etc.
An increase in transparency would mean that every time an updated ROOT zone is published, a “change-log” is published simultaneously, which incorporates comments on the change request, as well as links to supporting documentation. This will have the potential to increase the visibility of the process and will show the requestor and the process itself.
As a result, any attempts at performing amendments to the ROOT without valid details being entered will result in a red flag situation allowing Root operators to take remedial action.
As a reminder, translation of these documents and reports in the official UN languages is of paramount importance in the face of the ongoing internationalization of IANA’s functions.
Page 7 of 8
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.
Our suggestion in our response to Question 5, for a change-log to be public, will likely enhance overall security through stability and increased transparency.
The eIANA interface will provide more security. But it shouldn’t affect efficient direct interaction with real staff in case of emergency.
In the light of recent natural disasters affecting parts of the world, many of our members have Disaster Recovery in mind.
The IANA function needs to develop in-built contingency and fallback planning. An audit must be made clear of how information is stored, where it’s stored, and how it is verifiable. We suggest the establishing of emergency infrastructure Satellite phone number hotlines and an audit as to who has, who has not, who does and who does not in an emergency situation hitherto unseen.
