Re: [ICANN-CSC] [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_an...): "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@ctu.int> Date: Thursday, September 24, 2020 at 18:43 To: Amy Creamer <amy.creamer@icann.org>, "icann-csc@icann.org" <icann-csc@icann.org> Cc: "ifrt-leadership@icann.org" <ifrt-leadership@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@01D692B8.0EA88050][ctu.int] Caribbean Telecommunications Union [cid:image002.jpg@01D692B8.0EA88050][facebook.com] [cid:image003.jpg@01D692B8.0EA88050] [twitter.com] [cid:image004.jpg@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_4bbvIy...> From: ICANN-CSC [mailto:icann-csc-bounces@icann.org] On Behalf Of Amy Creamer Sent: Monday, September 21, 2020 2:13 PM To: icann-csc@icann.org Cc: ifrt-leadership@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-3...> 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_...>) Mobile: +1 424-537-8917 Direct Line: +1 310-578-8910 Email: amy.creamer@icann.org<mailto:amy.creamer@icann.org>
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 [cid:image001.jpg@01D6931D.25CD1420]<http://ctu.int/> Caribbean Telecommunications Union [cid:image002.jpg@01D6931D.25CD1420]<https://www.facebook.com/Caribbean-Telecommunications-Union-176163319122479/>[cid:image003.jpg@01D6931D.25CD1420]<https://twitter.com/TheCtunion>[cid:image004.jpg@01D6931D.25CD1420]<https://www.youtube.com/user/TheCtunion> 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<http://ctu.int/> From: Amy Creamer [mailto:amy.creamer@icann.org] Sent: Friday, September 25, 2020 12:17 AM To: Nigel Cassimire <Nigel.Cassimire@ctu.int>; icann-csc@icann.org Cc: ifrt-leadership@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_an...): "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@ctu.int<mailto:Nigel.Cassimire@ctu.int>> Date: Thursday, September 24, 2020 at 18:43 To: Amy Creamer <amy.creamer@icann.org<mailto:amy.creamer@icann.org>>, "icann-csc@icann.org<mailto:icann-csc@icann.org>" <icann-csc@icann.org<mailto:icann-csc@icann.org>> Cc: "ifrt-leadership@icann.org<mailto:ifrt-leadership@icann.org>" <ifrt-leadership@icann.org<mailto:ifrt-leadership@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@01D6931A.88D3E830][ctu.int] Caribbean Telecommunications Union [cid:image002.jpg@01D6931A.88D3E830][facebook.com] [cid:image003.jpg@01D6931A.88D3E830] [twitter.com] [cid:image004.jpg@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_4bbvIy...> From: ICANN-CSC [mailto:icann-csc-bounces@icann.org] On Behalf Of Amy Creamer Sent: Monday, September 21, 2020 2:13 PM To: icann-csc@icann.org<mailto:icann-csc@icann.org> Cc: ifrt-leadership@icann.org<mailto:ifrt-leadership@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-3...> 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_...>) Mobile: +1 424-537-8917 Direct Line: +1 310-578-8910 Email: amy.creamer@icann.org<mailto:amy.creamer@icann.org>
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@ctu.int> Date: Friday, September 25, 2020 at 06:21 To: Amy Creamer <amy.creamer@icann.org>, "icann-csc@icann.org" <icann-csc@icann.org> Cc: "ifrt-leadership@icann.org" <ifrt-leadership@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 [cid:image001.jpg@01D6931A.28401750][ctu.int] Caribbean Telecommunications Union [cid:image002.jpg@01D6931A.28401750][facebook.com] [cid:image003.jpg@01D6931A.28401750] [twitter.com] [cid:image004.jpg@01D6931A.28401750] [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!oaopKWHGhelnqs6UdxWcR...> From: Amy Creamer [mailto:amy.creamer@icann.org] Sent: Friday, September 25, 2020 12:17 AM To: Nigel Cassimire <Nigel.Cassimire@ctu.int>; icann-csc@icann.org Cc: ifrt-leadership@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_an... [ntia.doc.gov]<https://urldefense.com/v3/__https:/www.ntia.doc.gov/files/ntia/publications/...>): "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@ctu.int<mailto:Nigel.Cassimire@ctu.int>> Date: Thursday, September 24, 2020 at 18:43 To: Amy Creamer <amy.creamer@icann.org<mailto:amy.creamer@icann.org>>, "icann-csc@icann.org<mailto:icann-csc@icann.org>" <icann-csc@icann.org<mailto:icann-csc@icann.org>> Cc: "ifrt-leadership@icann.org<mailto:ifrt-leadership@icann.org>" <ifrt-leadership@icann.org<mailto:ifrt-leadership@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@01D6931A.88D3E830][ctu.int] Caribbean Telecommunications Union [cid:image002.jpg@01D6931A.88D3E830][facebook.com] [cid:image003.jpg@01D6931A.88D3E830] [twitter.com] [cid:image004.jpg@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_4bbvIy...> From: ICANN-CSC [mailto:icann-csc-bounces@icann.org] On Behalf Of Amy Creamer Sent: Monday, September 21, 2020 2:13 PM To: icann-csc@icann.org<mailto:icann-csc@icann.org> Cc: ifrt-leadership@icann.org<mailto:ifrt-leadership@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-3...> 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_...>) Mobile: +1 424-537-8917 Direct Line: +1 310-578-8910 Email: amy.creamer@icann.org<mailto:amy.creamer@icann.org>
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@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@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@ctu.int> *Date: *Friday, September 25, 2020 at 06:21 *To: *Amy Creamer <amy.creamer@icann.org>, "icann-csc@icann.org" < icann-csc@icann.org> *Cc: *"ifrt-leadership@icann.org" <ifrt-leadership@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!oaopKWHGhelnqs6UdxWcR...>
*From:* Amy Creamer [mailto:amy.creamer@icann.org] *Sent:* Friday, September 25, 2020 12:17 AM *To:* Nigel Cassimire <Nigel.Cassimire@ctu.int>; icann-csc@icann.org *Cc:* ifrt-leadership@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_an... [ntia.doc.gov] <https://urldefense.com/v3/__https:/www.ntia.doc.gov/files/ntia/publications/...>): "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@ctu.int> *Date: *Thursday, September 24, 2020 at 18:43 *To: *Amy Creamer <amy.creamer@icann.org>, "icann-csc@icann.org" < icann-csc@icann.org> *Cc: *"ifrt-leadership@icann.org" <ifrt-leadership@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@01D6931A.88D3E830][ctu.int]
*Caribbean *
*Telecommunications *
*Union *
[image: cid:image002.jpg@01D6931A.88D3E830][facebook.com] [image: cid:image003.jpg@01D6931A.88D3E830][twitter.com] [image: cid:image004.jpg@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_4bbvIy...>
*From:* ICANN-CSC [mailto:icann-csc-bounces@icann.org <icann-csc-bounces@icann.org>] *On Behalf Of *Amy Creamer *Sent:* Monday, September 21, 2020 2:13 PM *To:* icann-csc@icann.org *Cc:* ifrt-leadership@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-3...>
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_...> )
Mobile: +1 424-537-8917
Direct Line: +1 310-578-8910
Email: amy.creamer@icann.org _______________________________________________ ICANN-CSC mailing list ICANN-CSC@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.
Thanks for attending! Sent from my iPhone
On 29 Sep 2020, at 18:40, Alejandra Reynoso <alejandra.reynoso@cctld.gt> wrote:
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
--
Alejandra Reynoso Investigación & Desarrollo | Dominios .gt P: +502 23688565 E: alejandra.reynoso@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@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@ctu.int> Date: Friday, September 25, 2020 at 06:21 To: Amy Creamer <amy.creamer@icann.org>, "icann-csc@icann.org" <icann-csc@icann.org> Cc: "ifrt-leadership@icann.org" <ifrt-leadership@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
<image001.jpg> [ctu.int]
Caribbean
Telecommunications
Union
<image002.jpg> [facebook.com] <image003.jpg> [twitter.com] <image004.jpg> [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]
From: Amy Creamer [mailto:amy.creamer@icann.org] Sent: Friday, September 25, 2020 12:17 AM To: Nigel Cassimire <Nigel.Cassimire@ctu.int>; icann-csc@icann.org Cc: ifrt-leadership@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_an... [ntia.doc.gov]): "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@ctu.int> Date: Thursday, September 24, 2020 at 18:43 To: Amy Creamer <amy.creamer@icann.org>, "icann-csc@icann.org" <icann-csc@icann.org> Cc: "ifrt-leadership@icann.org" <ifrt-leadership@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
<image005.jpg> [ctu.int]
Caribbean
Telecommunications
Union
<image006.jpg> [facebook.com] <image007.jpg> [twitter.com] <image008.jpg> [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]
From: ICANN-CSC [mailto:icann-csc-bounces@icann.org] On Behalf Of Amy Creamer Sent: Monday, September 21, 2020 2:13 PM To: icann-csc@icann.org Cc: ifrt-leadership@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]
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])
Mobile: +1 424-537-8917
Direct Line: +1 310-578-8910
Email: amy.creamer@icann.org
_______________________________________________ ICANN-CSC mailing list ICANN-CSC@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.
ICANN-CSC mailing list ICANN-CSC@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.
Thank you Alejandra, and all the CSC members who responded! Regards, Amy From: Alejandra Reynoso <alejandra.reynoso@cctld.gt> Date: Tuesday, September 29, 2020 at 11:00 To: Amy Creamer <amy.creamer@icann.org> Cc: Nigel Cassimire <Nigel.Cassimire@ctu.int>, "icann-csc@icann.org" <icann-csc@icann.org>, "ifrt-leadership@icann.org" <ifrt-leadership@icann.org> Subject: Re: [ICANN-CSC] [Ext] RE: Letter from the IFRT to the CSC 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 removed by sender. Photograph] Alejandra Reynoso Investigación & Desarrollo | Dominios .gt P: +502 23688565 E: alejandra.reynoso@cctld.gt<mailto:alejandra.reynoso@cctld.gt> 18 Ave. 11-42 Zona 15, V.H. III. Guatemala, Guatemala www.gt [gt]<https://urldefense.com/v3/__http:/www.gt/__;!!PtGJab4!o6yTC-4ufXAOc7TmkGs8Rw...> On Fri, Sep 25, 2020 at 9:59 AM Amy Creamer <amy.creamer@icann.org<mailto:amy.creamer@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@ctu.int<mailto:Nigel.Cassimire@ctu.int>> Date: Friday, September 25, 2020 at 06:21 To: Amy Creamer <amy.creamer@icann.org<mailto:amy.creamer@icann.org>>, "icann-csc@icann.org<mailto:icann-csc@icann.org>" <icann-csc@icann.org<mailto:icann-csc@icann.org>> Cc: "ifrt-leadership@icann.org<mailto:ifrt-leadership@icann.org>" <ifrt-leadership@icann.org<mailto:ifrt-leadership@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 [cid:image001.jpg@01D69651.2ACFB0E0][ctu.int [ctu.int]<https://urldefense.com/v3/__http:/ctu.int__;!!PtGJab4!o6yTC-4ufXAOc7TmkGs8Rw...>] Caribbean Telecommunications Union [cid:image002.jpg@01D69651.2ACFB0E0][facebook.com [facebook.com]<https://urldefense.com/v3/__http:/facebook.com__;!!PtGJab4!o6yTC-4ufXAOc7Tmk...>] [cid:image003.jpg@01D69651.2ACFB0E0] [twitter.com [twitter.com]<https://urldefense.com/v3/__http:/twitter.com__;!!PtGJab4!o6yTC-4ufXAOc7TmkG...>] [cid:image004.jpg@01D69651.2ACFB0E0] [youtube.com [youtube.com]<https://urldefense.com/v3/__http:/youtube.com__;!!PtGJab4!o6yTC-4ufXAOc7TmkG...>] 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!oaopKWHGhelnqs6UdxWcR...> From: Amy Creamer [mailto:amy.creamer@icann.org<mailto:amy.creamer@icann.org>] Sent: Friday, September 25, 2020 12:17 AM To: Nigel Cassimire <Nigel.Cassimire@ctu.int<mailto:Nigel.Cassimire@ctu.int>>; icann-csc@icann.org<mailto:icann-csc@icann.org> Cc: ifrt-leadership@icann.org<mailto:ifrt-leadership@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_an... [ntia.doc.gov]<https://urldefense.com/v3/__https:/www.ntia.doc.gov/files/ntia/publications/...>): "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@ctu.int<mailto:Nigel.Cassimire@ctu.int>> Date: Thursday, September 24, 2020 at 18:43 To: Amy Creamer <amy.creamer@icann.org<mailto:amy.creamer@icann.org>>, "icann-csc@icann.org<mailto:icann-csc@icann.org>" <icann-csc@icann.org<mailto:icann-csc@icann.org>> Cc: "ifrt-leadership@icann.org<mailto:ifrt-leadership@icann.org>" <ifrt-leadership@icann.org<mailto:ifrt-leadership@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@01D6931A.88D3E830][ctu.int [ctu.int]<https://urldefense.com/v3/__http:/ctu.int__;!!PtGJab4!o6yTC-4ufXAOc7TmkGs8Rw...>] Caribbean Telecommunications Union [cid:image002.jpg@01D6931A.88D3E830][facebook.com [facebook.com]<https://urldefense.com/v3/__http:/facebook.com__;!!PtGJab4!o6yTC-4ufXAOc7Tmk...>] [cid:image003.jpg@01D6931A.88D3E830] [twitter.com [twitter.com]<https://urldefense.com/v3/__http:/twitter.com__;!!PtGJab4!o6yTC-4ufXAOc7TmkG...>] [cid:image004.jpg@01D6931A.88D3E830] [youtube.com [youtube.com]<https://urldefense.com/v3/__http:/youtube.com__;!!PtGJab4!o6yTC-4ufXAOc7TmkG...>] 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_4bbvIy...> From: ICANN-CSC [mailto:icann-csc-bounces@icann.org] On Behalf Of Amy Creamer Sent: Monday, September 21, 2020 2:13 PM To: icann-csc@icann.org<mailto:icann-csc@icann.org> Cc: ifrt-leadership@icann.org<mailto:ifrt-leadership@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-3...> 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_...>) Mobile: +1 424-537-8917 Direct Line: +1 310-578-8910 Email: amy.creamer@icann.org<mailto:amy.creamer@icann.org> _______________________________________________ ICANN-CSC mailing list ICANN-CSC@icann.org<mailto:ICANN-CSC@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 [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!PtGJab4!...>) and the website Terms of Service (https://www.icann.org/privacy/tos [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!PtGJab4!o6y...>). 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.
participants (4)
-
Alejandra Reynoso -
Amy Creamer -
James Gannon -
Nigel Cassimire