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

Tue Sep 29 17:33:35 UTC 2020

Hi Amy and all

After reading the most useful explanation given by Amy and after seeing the
presentation given by the IFRT in today's webinar, I don't have any
objection in removing the sentence in recommendation #4.

Best regards,
Alejandra

--

[image: Photograph]

*Alejandra Reynoso*Investigación & Desarrollo | Dominios .gt
*P:* +502 23688565
*E:* alejandra.reynoso at cctld.gt
18 Ave. 11-42 Zona 15, V.H. III.
Guatemala, Guatemala
www.gt

On Fri, Sep 25, 2020 at 9:59 AM Amy Creamer <amy.creamer at icann.org> wrote:

> Thank you Nigel,
>
>
>
> The IFRT co-chairs were cced on this email, so I will take that discussion
> up with them!
>
>
>
> Your questions and input are very valuable.
>
>
>
> Regards,
>
> Amy
>
>
>
> *From: *Nigel Cassimire <Nigel.Cassimire at ctu.int>
> *Date: *Friday, September 25, 2020 at 06:21
> *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: *RE: [Ext] RE: Letter from the IFRT to the CSC
>
>
>
> Thank you, Amy,
>
>
>
> This background helps a lot. It appears to me then that the substantive
> justification for the change is that implementation of the requirement has
> long been recognised as being operationally impracticable, even since the
> time of the NTIA contract, and the IFRT is satisfied that its continued
> inclusion in the bylaws adds no value to the reports. If correct, my
> suggestion therefore is that this point be brought out more plainly in the
> explanations given.
>
>
>
> Regards,
>
>
>
> *Nigel Cassimire | Ag. Secretary General*
>
> [ctu.int]
>
>
>
> *Caribbean *
>
> *Telecommunications *
>
> *Union *
>
> [facebook.com] [twitter.com] [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!oaopKWHGhelnqs6UdxWcRu5vSEzFd6wrC_tdhqh0KfprvjXZDnzkj4dvpfgbD3eNm0u39sA$>
>
>
>
>
>
> *From:* Amy Creamer [mailto:amy.creamer at icann.org]
> *Sent:* Friday, September 25, 2020 12:17 AM
> *To:* Nigel Cassimire <Nigel.Cassimire at ctu.int>; icann-csc at icann.org
> *Cc:* ifrt-leadership at icann.org
> *Subject:* Re: [Ext] RE: Letter from the IFRT to the CSC
>
>
>
> 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
> [ntia.doc.gov]
> <https://urldefense.com/v3/__https:/www.ntia.doc.gov/files/ntia/publications/sf_26_pg_1-2-final_award_and_sacs.pdf__;!!PtGJab4!oaopKWHGhelnqs6UdxWcRu5vSEzFd6wrC_tdhqh0KfprvjXZDnzkj4dvpfgbD3eNGHjLD8o$>):
> "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*
>
> [image: cid:image001.jpg at 01D6931A.88D3E830][ctu.int]
>
>
>
> *Caribbean *
>
> *Telecommunications *
>
> *Union *
>
> [image: cid:image002.jpg at 01D6931A.88D3E830][facebook.com] [image:
> cid:image003.jpg at 01D6931A.88D3E830][twitter.com] [image:
> cid:image004.jpg at 01D6931A.88D3E830][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
> <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
> _______________________________________________
> ICANN-CSC mailing list
> ICANN-CSC at icann.org
> https://mm.icann.org/mailman/listinfo/icann-csc
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3079 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image001-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 846 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image002-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 869 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image003-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 936 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image004-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 3664 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image005-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.jpg
Type: image/jpeg
Size: 946 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image006-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.jpg
Type: image/jpeg
Size: 938 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image007-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.jpg
Type: image/jpeg
Size: 1032 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/icann-csc/attachments/20200929/097b1f46/image008-0001.jpg>