Dear all, As you may have noted the issues identified by the ccTLD members and participants on the CWG-Stewardship have been resolved/discussion is closed to their satisfaction (see informal notes ISTC call 6 September). The only issue still pending are some suggested changes by Paul Kane with respect to the language of section 4.7. The CWG-Stewardship hopes to conclude its deliberations on this topic during its call today. The results of the discussions under auspices of the CWG-Stewardship are reflected in the update prepared by the CWG and its legal advisers, which will be submitted as part of the public comment (document included). As discussed on the Council call last week, the submission of the Council would focus on those issues identified by the ccTLD members and participants: First expressing general support for the resolutions and if and when necessary focus on those issues that needed further discussion/were not resolved. Based on current status, the Council statement could be limited to a general support statement for the update as prepared by the CWG. This should be reflected in the draft for the ccNSO Council. Pending the final discussions today by the CWG itself, please let the list know if you have any issues, suggest changes or are in support of the proposed Council statement. Please note the public comment period closes tomorrow (9 September) 23.59 UTC. Thank you and kind regards, Bart Draft ccNSO Council submission proposed IANA Functions Agreement The ccNSO Council welcomes this opportunity to comment on the proposed IANA Functions Agreement (https://www.icann.org/en/system/files/files/proposed-iana-naming-function-ag... ). This submission has been considered and endorsed by the ccNSO Council, though does not necessarily represents the consensus view of ccNSO members nor other ccTLDs or ccTLD orgnaisation, some of whom may decide to submit their own comments. The ccTLD operators will be direct customers of the naming services. As such they have a clear and specific interest in the IANA Naming Functions Agreement. The ccNSO Council is very aware of the comments made by representatives of ccTLD community on the CWG-Stewardship on the proposed Agreement (see Annex A) and fully supports these comments made, in particular comments with respect to Section 1.1 (definition of Significantly Interested Parties), and section 4.7 (reference to the Framework of Interpretation of RFC 1591 and reference to the 2005 Governmental Advisory Committee Principles and Guidelines for the Delegation and Administration of Country Code Top Level Domains). The ccNSO Council closely followed the deliberations of the CWG –Stewardship with respect to these comments and has been appraised by the ccTLD members and participants on the CWG –Stewardship on the progress made to resolve the issues with respect to the 10 August proposal. It is the understanding of the ccNSO Council that from the perspective of the ccTLD members and participants the issues have been resolved in a satisfactory manner. Further it is the understanding of the ccNSO Council that the results are fully reflected in the CWG-Stewardship mark-up version of the 10 August proposed IANA Naming Functions Agreement as submitted by the co-chairs of the CWG-Stewardship and the text proposed is supported by the ccTLD representatives on the CWG-Stewardship. Therefore, the ccNSO Council fully supports the amendments proposed by the CWG-Stewardship with respect to the issues identified by the ccTLD members and participants. The ccNSO Council trusts these suggested changes will be included in the final and effective version of the IANA Naming Function Agreement. Finally, the ccNSO Council congratulates the members and participants of the CWG-Stewardship, its legal advisers, and the ICANN Implementation team with the achieved result to date, despite the pressures from a tight timeline, and difficulty of dealing with parallel processes. On behalf of the ccNSO Council Katrina Sataki (chair) Annex A Issues Identified by ccTLD members and participants CWG-Stewardship draft IANA Naming Function Agreement (https://www.icann.org/public-comments/iana-naming-function-agreement-2016-08...) Section 1.1(oo). In the definition of “Significantly Interested Parties,” the phrase “these parties include, without limitation” should be modified to read “these parties include, but are not limited to” in order to be consistent with the phrasing used in the final FOI report. Section 4.2 requires the Contractor to perform the IANA Naming Function in the US and to demonstrate that all primary operations and systems will remain within the US. Is additional flexibility needed for remote personnel with operational responsibilities outside the US? Section 4.5 has an internal reference to Section 12.3, but that section has been deleted. Section 4.7. For the avoidance of doubt, we propose two modest changes: 1. The reference to the FOI should read: RFC 1591: Domain Name System Structure and Delegation (“RFC 1591”) as interpreted by the Framework of Interpretation of Current Policies and Guidelines Pertaining to 7 the Delegation and Redelegation of Country-Code Top Level Domain Names, dated October 2014 (“FOI”). Any subsequent references should read “RFC 1591 as interpreted by the FOI.” 2. The reference to the GAC Principles should read: “Where applicable in accordance with Section 1.3 thereof, the 2005 Governmental Advisory Committee Principles and Guidelines for the Delgation and Administration of Country Code Top Level Domains (“GAC 2005 ccTLD Principles”). Any subsequent reference to the GAC Principles should read, “where applicable in accordance with Section 1.3 thereof, the GAC 2005 ccTLD Principles.” Section 4.10(a). Is the prohibition on publication of posting of reports and other deliverables practical? As a minimum, PTI should be permitted to post ordinary, scheduled reports in pre-approved formats without ICANN review. Section 5.3(a) prohibits the Contractor from modifying the zone file or associated information without written authorization from ICANN. While that may make sense for some things (adding/deleting gTLDs, e.g.,) it can be - and in the past has been - interpreted to prevent routine changes such as the addition of a new name server by an existing TLD operator. This would obviously be very problematic Section 6.1(c) permits the PTI to redact Board minutes containing material that “is subject to a legal obligation that the Contractor maintains its confidentiality.” There have been recent examples where these kind of confidentiality provisions in ICANN’s contracts with its vendors and consultant prevented community access to information about consultant payments, etc. Is there a way to minimize these kind of redactions? Section 7.1 refers to “delegation, redelegation, and transfer of a TLD. The term “redelegation” should not be used in the context of ccTLDs. Under the FOI, the terms “Delegation,” “Revocation,” and “Transfer” are defined and used to refer to changes of this sort. Section 7.3(c) refers to “SCWG,” which is not defined. Section 8.1 has an internal reference to Section 8.2(a), which does not exist. Section 9.4 contains an internal reference to Section 14.16, which does not exist. Section 10.1(c) appears to introduce the concept of user fees for IANA Naming Function Services. How would this work, and are there adequate constraints on ICANN’s ability to approve and PTI’s ability to impose such fees? Section 12.1 Confidentiality. This provision is extremely broad, covering everything ICANN gives Contractor and all data acquired or developed by Contractor in performing the agreement. Why is this necessary and how can that be reconciled with ICANN’s obligations relating to transparency. For example, it is not even clear that members of the PTI Board, members of the IFR teams, etc. will have access to PTI information. In addition, the current draft deletes the previous Section 12.3 (Request for Information).