[ICANN-CSC] [Ext] RE: Letter from the IFRT to the CSC

Amy Creamer amy.creamer at icann.org
Fri Sep 25 04:17:07 UTC 2020


Hi Nigel,

Thank you for your question.  Here is the detailed history behind this contractual requirement and why the IFRT recommends removing it:

This provision is inherited from a requirement that existed in the previous NTIA contract (https://www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf):  "The audit report shall identify each root zone file and root zone “WHOIS” database change request and the relevant policy under which the change was made as well as identify change rejections and the relevant policy under which the change request was rejected."

In implementing this requirement, IANA Services had a discussion with NTIA and noted the lack of specific policies that govern our work to site.  The outcome agreed was that IANA Services would fulfill the requirement by adding boilerplate text that referenced policy sources at a high-level, which can be seen in the very first root audit report in September 2013: All requests were processed according to RFC 1591, ISO 3166-1, and the GAC Principles. (https://www.iana.org/performance/root-audit/201309).

In late 2015, NTIA requested a format change to the report to add a section pertaining to pending delegation and transfer activity. In that process the format changed and the revised format NTIA agreed to no longer contained that wording, and instead read: “All requests were processed according to relevant policies and procedures.” (https://www.iana.org/performance/root-audit/201512)”

Upon the IANA stewardship transition, the format was modified to remove references to NTIA and the specific provision of the IANA contract (C.5.2), and in that process the language was tightened slightly but was fundamentally unchanged:  “The following requests were implemented during the report period according to the relevant policies and procedures.” (https://www.iana.org/performance/root-audit/201610)

The reason this approach was agreed upon is because it is very difficult to directly connect the policy basis for any given change request to a specific policy. RFC 1591 is an informational document written by former IANA staff that has some concepts in it that are retrospectively deemed policy today, but the specific procedural elements in the document are clearly not in practice today. The GAC Principles similarly talks in high-level concepts. There is no formal policy that the ccNSO or GNSO has yet developed that specifically applies to the IANA functions. Therefore the aggregate operational tasks IANA implements are essentially derived from the fundamental tasks that are described in the IANA Naming Function Contract, the execution of which is largely inherited from past practices, and designed to fall within the parameters of these high-level requirements, but are not directly derived from specific policy requirements.

To give an illustration — if a TLD manager requests to change a telephone number in a WHOIS record in the root zone, it is hard to say where we would draw a line to a specific policy that governs that, other than broadly that it is consistent with existing policy and in fulfilment of the requirements of the contract. IANA is in full support of transparency, but it is hard to envision a practical way the audit report could be more specific without fundamental associated changes in the sources of our policies.


Thank you,
Amy


From: Nigel Cassimire <Nigel.Cassimire at ctu.int>
Date: Thursday, September 24, 2020 at 18:43
To: Amy Creamer <amy.creamer at icann.org>, "icann-csc at icann.org" <icann-csc at icann.org>
Cc: "ifrt-leadership at icann.org" <ifrt-leadership at icann.org>
Subject: [Ext] RE: Letter from the IFRT to the CSC

Dear Amy,

Thanks for this. I am really not clear on the merits of the proposed change.

The explanations given are “it is a legacy statement from the NTIA contract that is no longer required” and also “Since the IANA Stewardship Transition, any change request may fall under more than one policy, and the initial purpose of this requirement adds no value to the reports.”

Looking back at the audit reports though (https://www.iana.org/performance/root-audit ), up ‘til November 2015 the tabulated list of changes was headed with a statement that read in part: “All requests were processed according to RFC 1591, ISO 3166-1, and the GAC Principles” which (i) I assume identified the relevant policies in accordance with the existing bylaw and (ii) already seems to me to identify multiple applicable policies. Since December 2015 however, which I think well precedes the stewardship transition, the statement has been amended to more vaguely say: “…..according to the relevant policies and procedures”. So unless I’m looking in the wrong place, which is entirely possible, it appears that specific policies have not been identified in the monthly reports since December 2015.

Identification of the governing policy(ies) seems a simple and informative inclusion in the report to my mind. If however there is a useful operational reason for the current practice that justifies the proposed bylaw change, I’m not seeing it in the letter provided.

I long to be guided.

Regards,

Nigel Cassimire | Ag. Secretary General

[cid:image001.jpg at 01D692B8.0EA88050][ctu.int]


Caribbean
Telecommunications
Union

[cid:image002.jpg at 01D692B8.0EA88050][facebook.com] [cid:image003.jpg at 01D692B8.0EA88050] [twitter.com] [cid:image004.jpg at 01D692B8.0EA88050] [youtube.com]

4 Mary Street, St. Clair | Port of Spain | Trinidad and Tobago
Tel: (+1 868) 628-0281 ext. 235 | Fax: (+1 868) 622-6523 Website: http://ctu.int [ctu.int]<https://urldefense.com/v3/__http:/ctu.int/__;!!PtGJab4!rcr0wzPQEuSb9d_4bbvIyfWAVs2ngmZ62cgoVr5xdDL2nOZPvmA0SEq82cDureNKOEF6_0g$>







From: ICANN-CSC [mailto:icann-csc-bounces at icann.org] On Behalf Of Amy Creamer
Sent: Monday, September 21, 2020 2:13 PM
To: icann-csc at icann.org
Cc: ifrt-leadership at icann.org
Subject: [ICANN-CSC] Letter from the IFRT to the CSC

Dear CSC,

Please find attached a letter providing more detail on the IFRT’s Recommendation that will remove a line from the IANA Naming Functions Contract.

In addition, the IFRT will be hosting a webinar on 29 Sept 2020 to introduce their recommendations to the community prior to the Public Comment.  The IFRT would appreciate you sharing this announcement with your constituencies:

https://www.icann.org/news/announcement-2020-04-30-en [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/news/announcement-2020-04-30-en__;!!PtGJab4!rcr0wzPQEuSb9d_4bbvIyfWAVs2ngmZ62cgoVr5xdDL2nOZPvmA0SEq82cDureNK9Um7Zpw$>

Thank you for your time and attention to this matter.

Regards,

Amy Creamer
Sr. Project Manager
Office of the Chief Technical Officer (OCTO)
Internet Corporation for Assigned Names and Numbers (ICANN [icann.org]<https://urldefense.com/v3/__http:/www.icann.org/__;!!PtGJab4!rcr0wzPQEuSb9d_4bbvIyfWAVs2ngmZ62cgoVr5xdDL2nOZPvmA0SEq82cDureNK95ysGLI$>)

Mobile: +1 424-537-8917
Direct Line: +1 310-578-8910
Email: amy.creamer at icann.org<mailto:amy.creamer at icann.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200925/1b1f9348/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3079 bytes
Desc: image001.jpg
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200925/1b1f9348/image001-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 846 bytes
Desc: image002.jpg
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200925/1b1f9348/image002-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 869 bytes
Desc: image003.jpg
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200925/1b1f9348/image003-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 936 bytes
Desc: image004.jpg
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200925/1b1f9348/image004-0001.jpg>


More information about the ICANN-CSC mailing list