[CWG-Stewardship] Potential issues in Naming Function Agreement

[Paul M Kane]

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?

 

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

Best


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