CENTR welcomes the opportunity to submit its comments on the draft IANA Naming Function Agreement.
As we have actively been contributing since the start of the process, it is with the greatest interest that we have read the proposed draft agreement.
CENTR wants to express its support for the comments made by Paul Kane, Becky Burr and Stephen Deerhake in their letter to ICANN as posted on the CWG-stewardship mailing list dd. 16 August 2016. We have noted all of ICANN’s response dd. 18 August 2016. In particular, we welcome ICANN’s responses on the following articles:
· Section 1.1 (oo): aligning terminology with the FoI
· Section 4.10 (a): reconfirming PTI’s obligation to deliver proper reports and deliverables
· Section 5.3 (a): clarification to address confusion over the role of the Root Zone Maintainer in this agreement
· Section 6.1 (c): clarification on the transparency of the documentation process
· Section 7.1: aligning terminology with the FoI
In addition, CENTR would like to comment on the following issues.
1. The document is titled “IANA Naming Function Agreement”. This is inconsistent with the new ICANN Bylaws 16.3 that refer to the IANA Naming Function Contract. We suggest changing the terminology to match the wording in the ICANN Bylaws.
2. Section 5.3 (a) states that “Unless specifically authorized by ICANN in writing, Contractor shall not make modifications, additions or deletions to the root zone file or associated information.”
ccTLDs have in general always been strong advocates of a process where the ultimate authority over root zone changes is held by the registry manager or at the national level. For example, without a formal contract between ICANN and the registry, final decisions do not rest with ICANN and, over recent years, the ICANN Board’s role has been limited to ensuring that the IANA team has carried out due process and documented its decision correctly. This clause seems to suggest moving that authority back to ICANN and away from local decision-making. We appreciate that the intent of this clause might have been to prevent PTI from taking on the Root Zone Maintainer role and that ICANN, which has a responsibility to ensure that PTI performs its contract, will wish to exercise some oversight on the work of PTI. Hence we believe that this should be clarified to avoid the confusion the current wording creates.
The ccTLD community has been the main driver for the automation of the DNS Root Zone Management system that was deployed in 2011. Requirements for an automated DNS root zone management system should be addressed.
In general, decisions need to be based on agreed policy as codified in the ICANN Bylaws. The PTI’s role is limited to carrying out the IANA function with due process and proper documentation.
3. Section 4.6 User Instructions - Contractor shall, in collaboration with its customers, maintain user instructions, including technical requirements for the IANA Naming Function. Contractor shall post such instructions at iana.org ("IANA Website").
"Technical requirements" are referenced in Annex A, 1,d.vi:
Contractor shall maintain an automated root zone management system that, at a minimum, includes (A) a secure (encrypted) system for customer communications; (B) an automated provisioning protocol allowing customers to manage their interactions with the root zone management system; (C) 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; (D) a test system, which customers can use to meet the technical requirements for a change request; and (E) an internal interface for secure communications between the Contractor and the Root Zone Maintainer.
Section 4.6 appears to delegate the maintenance of technical requirements (which could be interpreted as the authority to define, review and change those technical requirements for a change request) to PTI. While the section also says "in collaboration with its customers", there is no obvious process to engage the community and also no explicit safeguard that those "technical requirements" do not interfere with the ultimate responsibility of the registry operator (at least for ccTLDs) as discussed elsewhere in the draft agreement. We strongly suggest that the agreement includes wording that impose the obligation on PTI to set up such a process in coordination with its customers.
4. Section 4.7 Responsibility and Respect for Stakeholders. Contractor shall apply the policies for the Root Zone Management component of the IANA Naming Function that have been defined, or after the date of this Agreement are further defined, by (a) the Generic Names Supporting Organization (“GNSO”) and the Country Code Names Supporting Organization (“ccNSO”), (b) the Framework of Interpretation of Current Policies and Guidelines Pertaining to the Delegation and Redelegation of Country-Code Top Level Domain Names, dated October 2014 (“FOI”), and (c) where applicable, the 2005 Governmental Advisory Committee Principles And Guidelines For The Delegation And Administration Of Country Code Top Level Domains (“GAC 2005 ccTLD Principles”). Contractor shall publish documentation pertaining to the implementation of these policies and principles on the IANA Website.
As RFC 1591 is the basis for delegation and redelegation of ccTLDs, we believe specific reference to this document and the Framework of Interpretation is needed. We would support a compromise text along the lines discussed in the CWG-Stewardship on 1 September:
“Art. 4.7 Responsibility and Respect for Stakeholders. Contractor shall apply the policies for the Root Zone Management component of the IANA Naming Function that have been defined, or after the date of this Agreement are further defined, by (a) the Generic Names Supporting Organization (“GNSO”) and the Country Code Names Supporting Organization (“ccNSO”), and (b) RFC 1591: /Domain Name System Structure and Delegation/ (“RFC 1591”) as interpreted by the Framework of Interpretation of Current Policies and Guidelines Pertaining to the Delegation and Redelegation of Country-Code Top Level Domain Names, dated October 2014 (“FOI”). In addition to these policies, Contractor shall, where applicable, consult the 2005 Governmental Advisory Committee Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains (“GAC 2005 ccTLD Principles”). Contractor shall publish documentation pertaining to the implementation of these policies and principles on the IANA Website.”
Our understanding is that PTI is a service provider, accordingly we assume that the current processes that deal with delegation, revocation and transfer will continue in their current format. We see the reference to the documents in the paragraph as a framework in which the PTI executes its instructions.
ICANN’s role is to ensure that PTI carries out its contract properly. It is important to ensure that the various agreements – the naming functions documents – make it clear that this is limited to checking that due process has been followed and documented and that the action in PTI is within the relevant policy framework for the registry concerned.
It should also be noted that ccTLDs that are not member of the ccNSO cannot be bound by ccNSO agreed policies and that there are also limitations to how far members of the ccNSO are bound by such policies. Any clarification to that respect in the proposal would be welcome. Reference to the ICANN Bylaws in this respect would be helpful.
5. Section 10.1 (c) states that “Any fees approved by ICANN and charged by Contractor relating to the IANA Naming Function will be based on the actual costs incurred, and value of the resources utilized, by Contractor to perform the IANA Naming Function.”
IANA Naming services have always been provided to all ccTLDs without a mandatory fee system. Some ccTLDs have signed agreements with ICANN that do include references to contributions for IANA services, but CENTR believes that these contributions always should remain voluntary. The current wording seems to suggest that ICANN could now impose mandatory fees. A reference to the required ccNSO agreement for any change to this voluntary system would clarify this issue.
PDF version of this CENTR Comment
