The Council of European National Top Level Domain Registries (CENTR) Board of Directors has submitted input to the ICANN consultation on Principles & Mechanisms and the Process to Develop a Proposal to Transition NTIA’s Stewardship of the IANA Functions.
The CENTR Board welcomes the opportunity to contribute on the initial consultation on the IANA transition and believes that the NTIA has been an exemplary guardian of the IANA function service.
CENTR has told ICANN that “the stability and security of the Internet is of paramount importance”.
Here is the CENTR input to ICANN:
CENTR BoD input to ICANN consultation on
Principles & Mechanisms and the Process to Develop a Proposal to
Introduction
Transition NTIA’s Stewardship of the IANA Functions
1. CENTR is the European country code TLD organisation. Its objectives are promoting and participating in the development of high standards and best practices among ccTLD Registries. Our members manage the Internet country code for their country with 52 full members. Together CENTR members are responsible for over 80% of all registered country code domain names worldwide.
2. We welcome the opportunity to contribute to the initial consultation on the transition of NTIA’s stewardship of the IANA functions.
3. We acknowledge the work of NTIA over the years. We believe that NTIA has been an exemplary guardian of the IANA function service.
4. In particular, we recognise that the recent progression to a contractual framework for the IANA function, with the terms of the contract informed by stakeholder input, provided a good basis for the operation of the service. Therefore, we believe we should build on this.
5. We note and strongly support the contribution of the Internet Architecture Board to this consultation. More in detail, because of the nature of the IANA functions and the different policy authorities and communities they serve, we agree that the main communities dependent on the IANA should lead the work relevant to their area of expertise. We have provided some comment below on the IANA function against the ccTLD registries. The active engagement of the ccTLD registry community in the root-zone management for country code registries is critical in the identification of key issues and the development of the required community support. It should however be noted that not all ccTLDs are part of the ICANN community. Therefore, we have proposed a mechanism to fill the possible gap in the IAB proposal.
6. We welcome the statement by Fadi Chehadé at the NETmundial meeting that the ICANN accountability review process will run in parallel with the work on the IANA stewardship and oversight transition. We warmly recommend that a reference to the ICANN accountability process is included in the process proposal.
General Comments
7. We welcome a careful approach to the development of a final proposal for transition. CENTR believes that it is very important to be clear on the process and, in particular, on how to identify the important elements that need to underpin any final proposal. Clarity is required on the necessary safeguards that have to be put in place once NTIA oversight is over.
8. As a community, we strongly believe that stability and security of the Internet is of paramount importance. Consequently, any disruption of IANA services that may be caused by the transfer process should be avoided. It is too early to talk about solutions: the approach needs to be clearly based on needs and aimed to ensure a smooth transfer. It should focus on transitioning the NTIA role.
9. The role asserted by NTIA is currently very limited, and is expressed to be merely a checking that due process is followed by the contracting party for the IANA contract. This leads to three key functions:
a. The delivery of service against contractually defined service-level standards;
b. IANA accountability to the users with decisions in line with, and based on, the agreed
policy framework; and
c. (ultimately) in the case of non-performance of the contractual obligations, to re-tendering the IANA function.
The transfer process should focus on ensuring robust mechanisms to cope with these three functions.
10. There are important and specific elements associated with ccTLD registries that are not shared by other IANA customers:
a. A very small number of ccTLD registries (two or three) have formal contracts, although
all rely on the root-zone management service administered by IANA;
b. A significant number of ccTLD registries are not members of ICANN’s ccNSO;
c. For ccTLD registries, registration policies are set locally and in conjunction with the local Internet community according and in compliance with RFC1591.
As such, the requirements of the ccTLD registry community are unique and diverse. The community is ready to facilitate an appropriate understanding of its cultural diversity to ensure a smooth transition that takes full account of the special nature of the ccTLD environment.
11. Along with other organisations that are dependent on the service provided by IANA, we rely on a reliable, policy-based, timely and efficient service. As it is a crucial service, any proposal should ensure the service continuity over the transition and beyond. Quality of service, predictability of decisions, and accountability and transparency of the IANA functions must not be compromised.
12. The framework for delegation and redelegation of ccTLD registries is currently being examined by the ccNSO and ICANN’s Government Advisory Committee through a joint ICANN Working Group (the Framework of Interpretation WG). This work is intended to help clarifying the existing policy framework.
As noted above, for ccTLD registries the policy authority will usually be national rather than
global. How this is exercised nationally is subject to proper national processes and should not be an issue in IANA decisions, and (likely to be rare) to overall considerations on global security and stability of the DNS.
Specific Comments on the Process Proposal Identified in the Consultation
13. We recognise the value of a community-based steering group for the process. However, we wish to underline the specific characteristics of the ccTLD environment and the diversity within the ccTLD community. We believe that there must be a strong representation of the ccTLD community from all the regions in the steering group.
14. The consultation paper seems to allocate the management of the process to the steering committee. We believe that it inappropriately and unfortunately mixes two roles: that of carrying out the review, and that of providing independent oversight to the process to ensure that the work is following the principles outlined by the NTIA.
15. We would like to recall our earlier comment that the different elements of the IANA function should be treated separately. This suggests that separate processes should look after the different elements of the IANA functions: an active and strong ccTLD registry involvement in the process relating to root-zone management related to ccTLD registries is critical in developing consensus-based and practical proposals.
16. While an AoC-type of review might be a useful approach to do the main work of developing an understanding of the issues and identifying likely ways forward, we believe that it would not be appropriate for ICANN or the GAC to be a gatekeeper in the selection of the steering group membership or any review team membership.
As suggested above, we think that ccTLD representation needs to be identified by the regional organisations and the ccNSO. We suggest that a total of 4 ccTLD representatives are identified by the ccTLD community: 2 via the ccNSO and 2 via the ccTLD Regional Organisations. We believe this would ensure a better balanced representation model.
17. Part of the process has to be to build up consensus on the direction forward.
18. This needs to be done during the work of the multi-stakeholder steering group and must not be left to the end when proposals are on the table. Again engagement of the regional ccTLD organisations will help to achieve this. Similarly, all stakeholder groups should be encouraged to think about the way that the requirements identified in paragraph 9 above can be implemented.