[CWG-Stewardship] Potential issues in Naming Function Agreement

[Trang Nguyen]

Dear Paul,

Thank you for your notes below. Please see attached ICAN’s responses to
the points raised in your notes.

Best,

Trang

-----Original Message-----
From: <cwg-stewardship-bounces at icann.org> on behalf of Paul M Kane
<Paul.Kane at icb.co.uk>
Date: Tuesday, August 16, 2016 at 1:59 PM
To: "cwg-stewardship at icann.org" <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?
>
> 
>
>*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>
>
>
>_______________________________________________
>CWG-Stewardship mailing list
>CWG-Stewardship at icann.org
>https://mm.icann.org/mailman/listinfo/cwg-stewardship

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Paul Kane Response.doc
Type: application/msword
Size: 44544 bytes
Desc: Paul Kane Response.doc
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20160818/25bcf9f6/PaulKaneResponse-0001.doc>