[CWG-Stewardship] Potential issues in Naming Function Agreement

Tue Aug 16 21:44:05 UTC 2016

Thanks Paul, Becky & Stephen.

Without minimizing any of the other suggested edits and comments, I comment on two of them below.

Chuck

-----Original Message-----
From: cwg-stewardship-bounces at icann.org [mailto:cwg-stewardship-bounces at icann.org] On Behalf Of Paul M Kane
Sent: Tuesday, August 16, 2016 4:59 PM
To: cwg-stewardship at icann.org
Subject: [CWG-Stewardship] Potential issues in Naming Function Agreement

I was given an action item the call before last to review the proposed Naming Agreement.  As mentioned during the call I would need the assistance of the ccTLD community as I was not up to speed on the work of the Framework of Interpretation.

I am advised that the headline concern is the need for PTI to be a service provider accepting instructions from the ccTLD Registry community and not a point of Registry control.  Registry Policy occurs in other forums, founded on applicable law, culture and operating environment of the existing ccTLD Registry Manager.

Becky Burr has been through the Naming Function Agreement, and (with a lot of help from Stephen Deerhake) identified the following issues:

*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.s

*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?
[Chuck Gomes] I think this is especially important.  In my opinion, PTI and its parent should do everything possible to minimize confidentiality provisions to include avoiding selection of contractors who demand them unreasonably.  Maybe a sentence along the following lines could be added: "To ensure maximum transparency, PTI should do everything possible to minimize confidentiality provisions in contracts with third party vendors to include avoiding doing business with those who demand such clauses unreasonably."

*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). 
[Chuck Gomes] I think it is critical that confidentially be minimized as much as possible to ensure maximum transparency.

Best

Paul
** <http://www.neustar.biz>

_______________________________________________
CWG-Stewardship mailing list
CWG-Stewardship at icann.org
https://mm.icann.org/mailman/listinfo/cwg-stewardship