Re: [Gnso-epdp-team] Purpose 2
We support Brian’s proposed Purpose 2 below, and note that without it – there are many gaps, including: * Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3rd party escrow providers All the best, Margie, Mark & Steve On behalf of the BC [https://facebook.design/public/images/logo.gif] Margie Milam IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> Reply-To: "brian.kingATmarkmonitor.com" <brian.king@markmonitor.com> Date: Wednesday, March 4, 2020 at 10:12 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Purpose 2 Hi all, Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC 😊), I propose the below: Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.” (ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2) Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=> MarkMonitor Protecting companies and consumers in a digital world
I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants. I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants. Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error. Alan At 04/03/2020 05:50 PM, Margie Milam wrote: We support Brian’s proposed Purpose 2 below, and note that without it � theere are many gaps, including: * Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3rd party escrow providers All the best, Margie, Mark & Steve On behalf of the BC Margie Milam IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> Reply-To: "brian.kingATmarkmonitor.com" <brian.king@markmonitor.com> Date: Wednesday, March 4, 2020 at 10:12 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Purpose 2 Hi all, Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below: Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.” (ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2) Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=> MarkMonitor Protecting companies and consumers in a digital world _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission" This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Thursday, March 05, 2020 2:18 AM To: Margie Milam; brian.kingATmarkmonitor.com; gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Purpose 2 I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants. I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants. Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error. Alan At 04/03/2020 05:50 PM, Margie Milam wrote: We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including: * Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3rd party escrow providers All the best, Margie, Mark & Steve On behalf of the BC Margie Milam IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> Reply-To: "brian.kingATmarkmonitor.com" <brian.king@markmonitor.com> Date: Wednesday, March 4, 2020 at 10:12 AM To: "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Purpose 2 Hi all, Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below: Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2) Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=> MarkMonitor Protecting companies and consumers in a digital world _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now. Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared. Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose: ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations. The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why. Best, Volker Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission"
This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this.
Hadia
*From:*Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Alan Greenberg *Sent:* Thursday, March 05, 2020 2:18 AM *To:* Margie Milam; brian.kingATmarkmonitor.com; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Purpose 2
I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants.
I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants.
Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error.
Alan
At 04/03/2020 05:50 PM, Margie Milam wrote:
We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including:
* Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3^rd party escrow providers
All the best,
Margie, Mark & Steve On behalf of the BC
* Margie Milam *IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents.
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> *Reply-To: *"brian.kingATmarkmonitor.com" <brian.king@markmonitor.com> *Date: *Wednesday, March 4, 2020 at 10:12 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> *Subject: *[Gnso-epdp-team] Purpose 2
Hi all,
Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below:
Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 markmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=>_ _ *MarkMonitor *Protecting companies and consumers in a digital world
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Dear Volker, I agree with you that specificity is required so that we can clearly explain to the data subject how and why the data will be processed. However, the purposes speak only to the why. So all the details that you mentioned are required and could be mentioned in a separate section that is we could have a section that clearly explains what purpose 2 entails. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Volker Greimann Sent: Thursday, March 05, 2020 12:41 PM To: gnso-epdp-team@icann.org Subject: Re: [Gnso-epdp-team] Purpose 2 I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now. Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared. Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose: ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations. The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why. Best, Volker Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi: We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission" This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Thursday, March 05, 2020 2:18 AM To: Margie Milam; brian.kingATmarkmonitor.com; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Purpose 2 I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants. I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants. Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error. Alan At 04/03/2020 05:50 PM, Margie Milam wrote: We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including: * Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3rd party escrow providers All the best, Margie, Mark & Steve On behalf of the BC Margie Milam IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Reply-To: "brian.kingATmarkmonitor.com" <brian.king@markmonitor.com><mailto:brian.king@markmonitor.com> Date: Wednesday, March 4, 2020 at 10:12 AM To: "gnso-epdp-team@icann.org"<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Purpose 2 Hi all, Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below: Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2) Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=> MarkMonitor Protecting companies and consumers in a digital world _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
HI all, I truly cannot believe we are still having the same conversations Let me 1st deal with Alan's statement re "SOME 3rd party requests are in fact in support of ICANN's mission" Agreed, Alan. "Support" - not "contracted to", not "obliged to" or not anything that denotes that they are in any way an actual legal and direct part of the data processing which we have been discussing for years now. These 3rd parties maintain their own, completely separate , possibly quite aligned, purposes to us. They may share a goal, an Ideal or a mission, but they are legal strangers to this CLOSED data processing ecosystem. By continuously invoking their aligned but legally separate 'purposes' - that is conflation. For the wider questions, I think we need to be crystal clear here. I think we need to call out 3 very important things are causing a lot of misunderstandings both in the past week and indeed beyond: *1) IS SSR a purpose?:* The URS is a purpose. The UDRP is a purpose. Contacting a registrant to deal with issues with the Domain, is a purpose: but let's be clear SSR is far bigger than a mere purpose. To be especially clear, nothing the EPDP will do or say, can change that, as it is enshrined at ICANN's core. ICANN (Community, org, GNSO process) may decide to process data in a manner that they believe is reasonable for the protection of SSR. They don't need the EPDP's permission to do so. To draw a clumsy analogy, (bear with me) Think of SSR as a very large building. That building has rooms that make up the individual efforts (such as the URS, UDRP, Spec 11 (3)b etc.) These rooms are the purposes which must be described on our policy. - a visitor to the 'SSR building' may look at the building but they will have no idea of what's in there or where they are supposed to go. They consult the building directory/map ( which is the privacy policy) and they can see which rooms are in that building and more importantly what each room contains. Weird analogy aside, as an example. the processing of data for URS or UDRP - this is a tangible thing that has stated rules, processes, procedures - all of which try to outline the use of any personal data in that process. The URS and the UDRP are without a doubt a part of the SSR efforts of the community, but were I but an auspicious bystander - If I was merely told that my data will be used for the purposes of SSR ... and not told specifically about the URS / UDRP, I would be utterly clueless as how my data may be used. That is the very problem we apparently are stuck on here - SSR grounds a purpose - but it is not a purpose in it's own right. *NOTE: just seeing Hadia's email now - her suggestion to further define a purpose with further purposes - is EXACTLY the point here, and why Purpose 2 is considered far too broad to be effective. * 2) * If SSR is not stated as a 'purpose'*, *then ICANN can't process data for SSR*. *This is absolutely not true.* Policies can continue to be created that add to the efforts to protect the SSR. NOTHING stops ICANN and the community from creating any new purposes with SSR at its core. To use the building analogy again (sorry) - The Building is the Bylaws -It's already built - we can create as many rooms in that building as we can imagine, as long as they are up the Building's standards and where there will be people staying in those rooms, that they meet the GDPR building regulations (including giving all existing tenants notice of the new rooms). We should also note that where policy necessitates a change to the manner in which the CPs or ICANN handle personal data, then obviously as our privacy policies are not governed by consensus policy, but any competent data controller, would merely ensure a process of registrant notification and necessary updates to our individual privacy policies. Again this is not a block to us implementing additional data processing, just that we need to ensure that we fulfil our legal obligations to inform the data subjects appropriately about the change, impact etc.. ICANN holds a very unique and very strong position to sponsor and enforce such policy creation, not because the EPDP somehow granted a 'purpose to create purposes for SSR' - but because it is the actual mission and reason for being of ICANN as is helpfully enshrined in its bylaws and mission.. *Finally and this is as HUGE one* 3) *Nothing in the conversation relating to Purpose II, affects or is intended to affect, or in ANY WAY prevent the SSAD from occurring.* That is completely separate. SSAD is the operationalization of a process for disclosure of data to third parties. That remains completely possible *regardless of Purpose II or NOT *- we do not need to create a purpose to disclose data to 3rd parties - that's the way the law is written. Phase II is defining this process for disclosure, making a process that currently EXISTS (in reality and as permitted by law) so that it is in a more streamlined and predictable manner. Any suggestion otherwise is simply not true. Sorry about the length as per usual, but I think we need to move past certain assumptions, so that we can focus on our actual task at hand. Thank you! [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ Suite 1-31, Block D, Iveagh Court Harcourt Road Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank yo On Thu, Mar 5, 2020 at 10:41 AM Volker Greimann <vgreimann@key-systems.net> wrote:
I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now.
Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared.
Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose:
ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations.
The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why.
Best,
Volker
Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission"
This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this.
Hadia
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] *On Behalf Of *Alan Greenberg *Sent:* Thursday, March 05, 2020 2:18 AM *To:* Margie Milam; brian.kingATmarkmonitor.com; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Purpose 2
I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants.
I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants.
Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error.
Alan
At 04/03/2020 05:50 PM, Margie Milam wrote:
We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including:
- Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) - Conducting research using the contacts - Coordinating cyber-attack responses such as Conficker & other cyber attacks - Publishing Accuracy Reporting System (ARS) reports - Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract - Implementing & testing escrow deposits with 3rd party escrow providers
All the best,
Margie, Mark & Steve On behalf of the BC
* Margie Milam *IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents.
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> *Reply-To: *"brian.kingATmarkmonitor.com" <brian.king@markmonitor.com> <brian.king@markmonitor.com> *Date: *Wednesday, March 4, 2020 at 10:12 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> *Subject: *[Gnso-epdp-team] Purpose 2
Hi all,
Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below:
Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 markmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=>
*MarkMonitor *Protecting companies and consumers in a digital world
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
_______________________________________________ Gnso-epdp-team mailing listGnso-epdp-team@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
The pedant in me demands that I note "Officious" not "Auspicious" bystander ... That would have eaten me alive! :D [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ Suite 1-31, Block D, Iveagh Court Harcourt Road Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Mar 5, 2020 at 2:27 PM Alan Woods <alan@donuts.email> wrote:
HI all,
I truly cannot believe we are still having the same conversations
Let me 1st deal with Alan's statement re "SOME 3rd party requests are in fact in support of ICANN's mission"
Agreed, Alan. "Support" - not "contracted to", not "obliged to" or not anything that denotes that they are in any way an actual legal and direct part of the data processing which we have been discussing for years now. These 3rd parties maintain their own, completely separate , possibly quite aligned, purposes to us. They may share a goal, an Ideal or a mission, but they are legal strangers to this CLOSED data processing ecosystem. By continuously invoking their aligned but legally separate 'purposes' - that is conflation.
For the wider questions, I think we need to be crystal clear here. I think we need to call out 3 very important things are causing a lot of misunderstandings both in the past week and indeed beyond:
*1) IS SSR a purpose?:*
The URS is a purpose. The UDRP is a purpose. Contacting a registrant to deal with issues with the Domain, is a purpose: but let's be clear SSR is far bigger than a mere purpose. To be especially clear, nothing the EPDP will do or say, can change that, as it is enshrined at ICANN's core.
ICANN (Community, org, GNSO process) may decide to process data in a manner that they believe is reasonable for the protection of SSR. They don't need the EPDP's permission to do so.
To draw a clumsy analogy, (bear with me) Think of SSR as a very large building. That building has rooms that make up the individual efforts (such as the URS, UDRP, Spec 11 (3)b etc.) These rooms are the purposes which must be described on our policy. - a visitor to the 'SSR building' may look at the building but they will have no idea of what's in there or where they are supposed to go. They consult the building directory/map ( which is the privacy policy) and they can see which rooms are in that building and more importantly what each room contains.
Weird analogy aside, as an example. the processing of data for URS or UDRP - this is a tangible thing that has stated rules, processes, procedures - all of which try to outline the use of any personal data in that process. The URS and the UDRP are without a doubt a part of the SSR efforts of the community, but were I but an auspicious bystander - If I was merely told that my data will be used for the purposes of SSR ... and not told specifically about the URS / UDRP, I would be utterly clueless as how my data may be used. That is the very problem we apparently are stuck on here - SSR grounds a purpose - but it is not a purpose in it's own right.
*NOTE: just seeing Hadia's email now - her suggestion to further define a purpose with further purposes - is EXACTLY the point here, and why Purpose 2 is considered far too broad to be effective. *
2) * If SSR is not stated as a 'purpose'*, *then ICANN can't process data for SSR*.
*This is absolutely not true.*
Policies can continue to be created that add to the efforts to protect the SSR. NOTHING stops ICANN and the community from creating any new purposes with SSR at its core. To use the building analogy again (sorry) - The Building is the Bylaws -It's already built - we can create as many rooms in that building as we can imagine, as long as they are up the Building's standards and where there will be people staying in those rooms, that they meet the GDPR building regulations (including giving all existing tenants notice of the new rooms).
We should also note that where policy necessitates a change to the manner in which the CPs or ICANN handle personal data, then obviously as our privacy policies are not governed by consensus policy, but any competent data controller, would merely ensure a process of registrant notification and necessary updates to our individual privacy policies. Again this is not a block to us implementing additional data processing, just that we need to ensure that we fulfil our legal obligations to inform the data subjects appropriately about the change, impact etc..
ICANN holds a very unique and very strong position to sponsor and enforce such policy creation, not because the EPDP somehow granted a 'purpose to create purposes for SSR' - but because it is the actual mission and reason for being of ICANN as is helpfully enshrined in its bylaws and mission..
*Finally and this is as HUGE one*
3) *Nothing in the conversation relating to Purpose II, affects or is intended to affect, or in ANY WAY prevent the SSAD from occurring.*
That is completely separate. SSAD is the operationalization of a process for disclosure of data to third parties. That remains completely possible *regardless of Purpose II or NOT *- we do not need to create a purpose to disclose data to 3rd parties - that's the way the law is written. Phase II is defining this process for disclosure, making a process that currently EXISTS (in reality and as permitted by law) so that it is in a more streamlined and predictable manner. Any suggestion otherwise is simply not true.
Sorry about the length as per usual, but I think we need to move past certain assumptions, so that we can focus on our actual task at hand.
Thank you!
[image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ Suite 1-31, Block D, Iveagh Court Harcourt Road Dublin 2, County Dublin Ireland
<https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank yo
On Thu, Mar 5, 2020 at 10:41 AM Volker Greimann <vgreimann@key-systems.net> wrote:
I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now.
Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared.
Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose:
ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations.
The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why.
Best,
Volker
Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission"
This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this.
Hadia
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] *On Behalf Of *Alan Greenberg *Sent:* Thursday, March 05, 2020 2:18 AM *To:* Margie Milam; brian.kingATmarkmonitor.com; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Purpose 2
I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants.
I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants.
Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error.
Alan
At 04/03/2020 05:50 PM, Margie Milam wrote:
We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including:
- Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) - Conducting research using the contacts - Coordinating cyber-attack responses such as Conficker & other cyber attacks - Publishing Accuracy Reporting System (ARS) reports - Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract - Implementing & testing escrow deposits with 3rd party escrow providers
All the best,
Margie, Mark & Steve On behalf of the BC
* Margie Milam *IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents.
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> *Reply-To: *"brian.kingATmarkmonitor.com" <brian.king@markmonitor.com> <brian.king@markmonitor.com> *Date: *Wednesday, March 4, 2020 at 10:12 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> *Subject: *[Gnso-epdp-team] Purpose 2
Hi all,
Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below:
Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 markmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=>
*MarkMonitor *Protecting companies and consumers in a digital world
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
_______________________________________________ Gnso-epdp-team mailing listGnso-epdp-team@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
Essentially: Just because it is not part of the SSAD, it does not mean ICANN cannot do it. They may not be able to use SSAD for it, but there are other ways. For Example: Escrow does not rely on SSAD. That data deposit occours outside of SSAD/RDAP/Whois. If public whois never existed, escrow would still have been possible. Volker Am 05.03.2020 um 15:27 schrieb Alan Woods:
HI all,
I truly cannot believe we are still having the same conversations
Let me 1st deal with Alan's statement re "SOME 3rd party requests are in fact in support of ICANN's mission"
Agreed, Alan. "Support" - not "contracted to", not "obliged to" or not anything that denotes that they are in any way an actual legal and direct part of the data processing which we have been discussing for years now. These 3rd parties maintain their own, completely separate , possibly quite aligned, purposes to us. They may share a goal, an Ideal or a mission, but they are legal strangers to this CLOSED data processing ecosystem. By continuously invoking their aligned but legally separate 'purposes' - that is conflation.
For the wider questions, I think we need to be crystal clear here. I think we need to call out 3 very important things are causing a lot of misunderstandings both in the past week and indeed beyond:
*_/1) IS SSR a purpose?:/_*
The URS is a purpose. The UDRP is a purpose. Contacting a registrant to deal with issues with the Domain, is a purpose: but let's be clear SSR is far bigger than a mere purpose. To be especially clear, nothing the EPDP will do or say, can change that, as it is enshrined at ICANN's core.
ICANN (Community, org, GNSO process) may decide to process data in a manner that they believe is reasonable for the protection of SSR. They don't need the EPDP's permission to do so.
To draw a clumsy analogy, (bear with me) Think of SSR as a very large building. That building has rooms that make up the individual efforts (such as the URS, UDRP, Spec 11 (3)b etc.) These rooms are the purposes which must be described on our policy. - a visitor to the 'SSR building' may look at the building but they will have no idea of what's in there or where they are supposed to go. They consult the building directory/map ( which is the privacy policy) and they can see which rooms are in that building and more importantly what each room contains.
Weird analogy aside, as an example. the processing of data for URS or UDRP - this is a tangible thing that has stated rules, processes, procedures - all of which try to outline the use of any personal data in that process. The URS and the UDRP are without a doubt a part of the SSR efforts of the community, but were I but an auspicious bystander - If I was merely told that my data will be used for the purposes of SSR ... and not told specifically about the URS / UDRP, I would be utterly clueless as how my data may be used. That is the very problem we apparently are stuck on here - SSR grounds a purpose - but it is not a purpose in it's own right.
/NOTE: just seeing Hadia's email now - her suggestion to further define a purpose with further purposes - is EXACTLY the point here, and why Purpose 2 is considered far too broad to be effective. / / /
2) * If SSR is not stated as a 'purpose'*, *then ICANN can't process data for SSR*.
*_This is absolutely not true._*
Policies can continue to be created that add to the efforts to protect the SSR. NOTHING stops ICANN and the community from creating any new purposes with SSR at its core. To use the building analogy again (sorry) - The Building is the Bylaws -It's already built - we can create as many rooms in that building as we can imagine, as long as they are up the Building's standards and where there will be people staying in those rooms, that they meet the GDPR building regulations (including giving all existing tenants notice of the new rooms).
We should also note that where policy necessitates a change to the manner in which the CPs or ICANN handle personal data, then obviously as our privacy policies are not governed by consensus policy, but any competent data controller, would merely ensure a process of registrant notification and necessary updates to our individual privacy policies. Again this is not a block to us implementing additional data processing, just that we need to ensure that we fulfil our legal obligations to inform the data subjects appropriately about the change, impact etc..
ICANN holds a very unique and very strong position to sponsor and enforce such policy creation, not because the EPDP somehow granted a 'purpose to create purposes for SSR' - but because it is the actual mission and reason for being of ICANN as is helpfully enshrined in its bylaws and mission..
*Finally and this is as HUGE one*
3) *_Nothing in the conversation relating to Purpose II, affects or is intended to affect, or in ANY WAY prevent the SSAD from occurring._*
That is completely separate. SSAD is the operationalization of a process for disclosure of data to third parties. That remains completely possible *_regardless of Purpose II or NOT _*- we do not need to create a purpose to disclose data to 3rd parties - that's the way the law is written. Phase II is defining this process for disclosure, making a process that currently EXISTS (in reality and as permitted by law) so that it is in a more streamlined and predictable manner. Any suggestion otherwise is simply not true.
Sorry about the length as per usual, but I think we need to move past certain assumptions, so that we can focus on our actual task at hand.
Thank you!
Donuts Inc. <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------------------------------------------------ Suite 1-31, Block D, Iveagh Court Harcourt Road Dublin 2, County Dublin Ireland
<https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank yo
On Thu, Mar 5, 2020 at 10:41 AM Volker Greimann <vgreimann@key-systems.net <mailto:vgreimann@key-systems.net>> wrote:
I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now.
Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared.
Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose:
ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations.
The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why.
Best,
Volker
Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission"
This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this.
Hadia
*From:*Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Alan Greenberg *Sent:* Thursday, March 05, 2020 2:18 AM *To:* Margie Milam; brian.kingATmarkmonitor.com <http://brian.kingATmarkmonitor.com>; gnso-epdp-team@icann.org <mailto:gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Purpose 2
I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants.
I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants.
Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error.
Alan
At 04/03/2020 05:50 PM, Margie Milam wrote:
We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including:
* Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3^rd party escrow providers
All the best,
Margie, Mark & Steve On behalf of the BC
* Margie Milam *IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents.
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <mailto:gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> <mailto:gnso-epdp-team@icann.org> *Reply-To: *"brian.kingATmarkmonitor.com <http://brian.kingATmarkmonitor.com>" <brian.king@markmonitor.com> <mailto:brian.king@markmonitor.com> *Date: *Wednesday, March 4, 2020 at 10:12 AM *To: *"gnso-epdp-team@icann.org" <mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> <mailto:gnso-epdp-team@icann.org> *Subject: *[Gnso-epdp-team] Purpose 2
Hi all,
Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below:
Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 markmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=>_ _ *MarkMonitor *Protecting companies and consumers in a digital world
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net <http://www.key-systems.net>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Dear All, The positive thing about the emails on this topic is that we all agree the SSR of the DNS is an ICANN purpose for which the registration data could be processed. The difference in opinion comes from the fact that some of us do not find it necessary to mention the purpose and others would like the purpose to be more specific. My suggestion was not to specify purpose 2 with more purposes but to specify purpose 2 by clearly stating the processing activities that this purpose might entail. This is necessary because we shall need to inform the data subjects of how their data might be processed and for which purposes. Being clear and transparent in our report about the purposes and processing activities is better than just relying on the assumption that the readers of the report know that the disclosure of the registration data to third parties with legitimate interests and lawful bases is a right under GDPR. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Volker Greimann Sent: Thursday, March 05, 2020 5:49 PM To: Alan Woods Cc: GNSO EPDP Subject: Re: [Gnso-epdp-team] Purpose 2 Essentially: Just because it is not part of the SSAD, it does not mean ICANN cannot do it. They may not be able to use SSAD for it, but there are other ways. For Example: Escrow does not rely on SSAD. That data deposit occours outside of SSAD/RDAP/Whois. If public whois never existed, escrow would still have been possible. Volker Am 05.03.2020 um 15:27 schrieb Alan Woods: HI all, I truly cannot believe we are still having the same conversations Let me 1st deal with Alan's statement re "SOME 3rd party requests are in fact in support of ICANN's mission" Agreed, Alan. "Support" - not "contracted to", not "obliged to" or not anything that denotes that they are in any way an actual legal and direct part of the data processing which we have been discussing for years now. These 3rd parties maintain their own, completely separate , possibly quite aligned, purposes to us. They may share a goal, an Ideal or a mission, but they are legal strangers to this CLOSED data processing ecosystem. By continuously invoking their aligned but legally separate 'purposes' - that is conflation. For the wider questions, I think we need to be crystal clear here. I think we need to call out 3 very important things are causing a lot of misunderstandings both in the past week and indeed beyond: 1) IS SSR a purpose?: The URS is a purpose. The UDRP is a purpose. Contacting a registrant to deal with issues with the Domain, is a purpose: but let's be clear SSR is far bigger than a mere purpose. To be especially clear, nothing the EPDP will do or say, can change that, as it is enshrined at ICANN's core. ICANN (Community, org, GNSO process) may decide to process data in a manner that they believe is reasonable for the protection of SSR. They don't need the EPDP's permission to do so. To draw a clumsy analogy, (bear with me) Think of SSR as a very large building. That building has rooms that make up the individual efforts (such as the URS, UDRP, Spec 11 (3)b etc.) These rooms are the purposes which must be described on our policy. - a visitor to the 'SSR building' may look at the building but they will have no idea of what's in there or where they are supposed to go. They consult the building directory/map ( which is the privacy policy) and they can see which rooms are in that building and more importantly what each room contains. Weird analogy aside, as an example. the processing of data for URS or UDRP - this is a tangible thing that has stated rules, processes, procedures - all of which try to outline the use of any personal data in that process. The URS and the UDRP are without a doubt a part of the SSR efforts of the community, but were I but an auspicious bystander - If I was merely told that my data will be used for the purposes of SSR ... and not told specifically about the URS / UDRP, I would be utterly clueless as how my data may be used. That is the very problem we apparently are stuck on here - SSR grounds a purpose - but it is not a purpose in it's own right. NOTE: just seeing Hadia's email now - her suggestion to further define a purpose with further purposes - is EXACTLY the point here, and why Purpose 2 is considered far too broad to be effective. 2) If SSR is not stated as a 'purpose', then ICANN can't process data for SSR. This is absolutely not true. Policies can continue to be created that add to the efforts to protect the SSR. NOTHING stops ICANN and the community from creating any new purposes with SSR at its core. To use the building analogy again (sorry) - The Building is the Bylaws -It's already built - we can create as many rooms in that building as we can imagine, as long as they are up the Building's standards and where there will be people staying in those rooms, that they meet the GDPR building regulations (including giving all existing tenants notice of the new rooms). We should also note that where policy necessitates a change to the manner in which the CPs or ICANN handle personal data, then obviously as our privacy policies are not governed by consensus policy, but any competent data controller, would merely ensure a process of registrant notification and necessary updates to our individual privacy policies. Again this is not a block to us implementing additional data processing, just that we need to ensure that we fulfil our legal obligations to inform the data subjects appropriately about the change, impact etc.. ICANN holds a very unique and very strong position to sponsor and enforce such policy creation, not because the EPDP somehow granted a 'purpose to create purposes for SSR' - but because it is the actual mission and reason for being of ICANN as is helpfully enshrined in its bylaws and mission.. Finally and this is as HUGE one 3) Nothing in the conversation relating to Purpose II, affects or is intended to affect, or in ANY WAY prevent the SSAD from occurring. That is completely separate. SSAD is the operationalization of a process for disclosure of data to third parties. That remains completely possible regardless of Purpose II or NOT - we do not need to create a purpose to disclose data to 3rd parties - that's the way the law is written. Phase II is defining this process for disclosure, making a process that currently EXISTS (in reality and as permitted by law) so that it is in a more streamlined and predictable manner. Any suggestion otherwise is simply not true. Sorry about the length as per usual, but I think we need to move past certain assumptions, so that we can focus on our actual task at hand. Thank you! [Donuts Inc.]<http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ Suite 1-31, Block D, Iveagh Court Harcourt Road Dublin 2, County Dublin Ireland [http://storage.googleapis.com/signaturesatori/icons/facebook.png]<https://www.facebook.com/donutstlds> [http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc> [http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank yo On Thu, Mar 5, 2020 at 10:41 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now. Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared. Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose: ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations. The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why. Best, Volker Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi: We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission" This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Thursday, March 05, 2020 2:18 AM To: Margie Milam; brian.kingATmarkmonitor.com<http://brian.kingATmarkmonitor.com>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Purpose 2 I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants. I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants. Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error. Alan At 04/03/2020 05:50 PM, Margie Milam wrote: We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including: * Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3rd party escrow providers All the best, Margie, Mark & Steve On behalf of the BC Margie Milam IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Reply-To: "brian.kingATmarkmonitor.com<http://brian.kingATmarkmonitor.com>" <brian.king@markmonitor.com><mailto:brian.king@markmonitor.com> Date: Wednesday, March 4, 2020 at 10:12 AM To: "gnso-epdp-team@icann.org"<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Purpose 2 Hi all, Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below: Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2) Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=> MarkMonitor Protecting companies and consumers in a digital world _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Hi all, The IPC reiterates the importance of this purpose, in whatever form it might ultimately take. With thanks to several of you for your helpful perspective, I propose the language below to replace Purpose 2, hopefully reflecting the guidance received from EPDP colleagues from various parts of the community. “Enabling ICANN, in its role as data controller, to enforce policies related to the “maintenance of and access to accurate and up-to-date information concerning registered names and name servers,” including the Registration Data Policy and *Placeholder Name for Phase 2 Policy (if not also Registration Data Policy)*. (ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)” Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> On Behalf Of Hadia Abdelsalam Mokhtar EL miniawi Sent: Tuesday, March 10, 2020 9:50 AM To: Volker Greimann <vgreimann@key-systems.net>; Alan Woods <alan@donuts.email> Cc: GNSO EPDP <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Purpose 2 Dear All, The positive thing about the emails on this topic is that we all agree the SSR of the DNS is an ICANN purpose for which the registration data could be processed. The difference in opinion comes from the fact that some of us do not find it necessary to mention the purpose and others would like the purpose to be more specific. My suggestion was not to specify purpose 2 with more purposes but to specify purpose 2 by clearly stating the processing activities that this purpose might entail. This is necessary because we shall need to inform the data subjects of how their data might be processed and for which purposes. Being clear and transparent in our report about the purposes and processing activities is better than just relying on the assumption that the readers of the report know that the disclosure of the registration data to third parties with legitimate interests and lawful bases is a right under GDPR. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Volker Greimann Sent: Thursday, March 05, 2020 5:49 PM To: Alan Woods Cc: GNSO EPDP Subject: Re: [Gnso-epdp-team] Purpose 2 Essentially: Just because it is not part of the SSAD, it does not mean ICANN cannot do it. They may not be able to use SSAD for it, but there are other ways. For Example: Escrow does not rely on SSAD. That data deposit occours outside of SSAD/RDAP/Whois. If public whois never existed, escrow would still have been possible. Volker Am 05.03.2020 um 15:27 schrieb Alan Woods: HI all, I truly cannot believe we are still having the same conversations Let me 1st deal with Alan's statement re "SOME 3rd party requests are in fact in support of ICANN's mission" Agreed, Alan. "Support" - not "contracted to", not "obliged to" or not anything that denotes that they are in any way an actual legal and direct part of the data processing which we have been discussing for years now. These 3rd parties maintain their own, completely separate , possibly quite aligned, purposes to us. They may share a goal, an Ideal or a mission, but they are legal strangers to this CLOSED data processing ecosystem. By continuously invoking their aligned but legally separate 'purposes' - that is conflation. For the wider questions, I think we need to be crystal clear here. I think we need to call out 3 very important things are causing a lot of misunderstandings both in the past week and indeed beyond: 1) IS SSR a purpose?: The URS is a purpose. The UDRP is a purpose. Contacting a registrant to deal with issues with the Domain, is a purpose: but let's be clear SSR is far bigger than a mere purpose. To be especially clear, nothing the EPDP will do or say, can change that, as it is enshrined at ICANN's core. ICANN (Community, org, GNSO process) may decide to process data in a manner that they believe is reasonable for the protection of SSR. They don't need the EPDP's permission to do so. To draw a clumsy analogy, (bear with me) Think of SSR as a very large building. That building has rooms that make up the individual efforts (such as the URS, UDRP, Spec 11 (3)b etc.) These rooms are the purposes which must be described on our policy. - a visitor to the 'SSR building' may look at the building but they will have no idea of what's in there or where they are supposed to go. They consult the building directory/map ( which is the privacy policy) and they can see which rooms are in that building and more importantly what each room contains. Weird analogy aside, as an example. the processing of data for URS or UDRP - this is a tangible thing that has stated rules, processes, procedures - all of which try to outline the use of any personal data in that process. The URS and the UDRP are without a doubt a part of the SSR efforts of the community, but were I but an auspicious bystander - If I was merely told that my data will be used for the purposes of SSR ... and not told specifically about the URS / UDRP, I would be utterly clueless as how my data may be used. That is the very problem we apparently are stuck on here - SSR grounds a purpose - but it is not a purpose in it's own right. NOTE: just seeing Hadia's email now - her suggestion to further define a purpose with further purposes - is EXACTLY the point here, and why Purpose 2 is considered far too broad to be effective. 2) If SSR is not stated as a 'purpose', then ICANN can't process data for SSR. This is absolutely not true. Policies can continue to be created that add to the efforts to protect the SSR. NOTHING stops ICANN and the community from creating any new purposes with SSR at its core. To use the building analogy again (sorry) - The Building is the Bylaws -It's already built - we can create as many rooms in that building as we can imagine, as long as they are up the Building's standards and where there will be people staying in those rooms, that they meet the GDPR building regulations (including giving all existing tenants notice of the new rooms). We should also note that where policy necessitates a change to the manner in which the CPs or ICANN handle personal data, then obviously as our privacy policies are not governed by consensus policy, but any competent data controller, would merely ensure a process of registrant notification and necessary updates to our individual privacy policies. Again this is not a block to us implementing additional data processing, just that we need to ensure that we fulfil our legal obligations to inform the data subjects appropriately about the change, impact etc.. ICANN holds a very unique and very strong position to sponsor and enforce such policy creation, not because the EPDP somehow granted a 'purpose to create purposes for SSR' - but because it is the actual mission and reason for being of ICANN as is helpfully enshrined in its bylaws and mission.. Finally and this is as HUGE one 3) Nothing in the conversation relating to Purpose II, affects or is intended to affect, or in ANY WAY prevent the SSAD from occurring. That is completely separate. SSAD is the operationalization of a process for disclosure of data to third parties. That remains completely possible regardless of Purpose II or NOT - we do not need to create a purpose to disclose data to 3rd parties - that's the way the law is written. Phase II is defining this process for disclosure, making a process that currently EXISTS (in reality and as permitted by law) so that it is in a more streamlined and predictable manner. Any suggestion otherwise is simply not true. Sorry about the length as per usual, but I think we need to move past certain assumptions, so that we can focus on our actual task at hand. Thank you! [Image removed by sender. Donuts Inc.]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=7mINsuiW2IIxt8JwAPtkTH0WvTigF5a2mUjYF8PYHGI&e=> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ Suite 1-31, Block D, Iveagh Court Harcourt Road Dublin 2, County Dublin Ireland [Image removed by sender.]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=-l1IMqW_DKhwYRH5OqyxHFipdxqIpENIcAm34tmIG58&e=> [Image removed by sender.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=ms_iCWKvT2eUYgKL1ARrmpVgeHTeKdgASIhUx6nsUP4&e=> [Image removed by sender.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=XvDGUW_wi--04yRDbhjRho4NXA6fGh2sSPuBn693EmQ&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank yo On Thu, Mar 5, 2020 at 10:41 AM Volker Greimann <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> wrote: I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now. Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared. Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose: ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations. The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why. Best, Volker Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi: We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission" This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this. Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Thursday, March 05, 2020 2:18 AM To: Margie Milam; brian.kingATmarkmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__brian.kingATmarkmonitor.com&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KRnVvjEJ4MvLUWmbq5B_tdtmgBLnTMgwzLCi6dLG398&e=>; gnso-epdp-team@icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Purpose 2 I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants. I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants. Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error. Alan At 04/03/2020 05:50 PM, Margie Milam wrote: We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including: * Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) * Conducting research using the contacts * Coordinating cyber-attack responses such as Conficker & other cyber attacks * Publishing Accuracy Reporting System (ARS) reports * Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract * Implementing & testing escrow deposits with 3rd party escrow providers All the best, Margie, Mark & Steve On behalf of the BC Margie Milam IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents. From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org><mailto:gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Reply-To: "brian.kingATmarkmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__brian.kingATmarkmonitor.com&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KRnVvjEJ4MvLUWmbq5B_tdtmgBLnTMgwzLCi6dLG398&e=>" <brian.king@markmonitor.com><mailto:brian.king@markmonitor.com> Date: Wednesday, March 4, 2020 at 10:12 AM To: "gnso-epdp-team@icann.org"<mailto:gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Purpose 2 Hi all, Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below: Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2) Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=> MarkMonitor Protecting companies and consumers in a digital world _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=zXDsE0OQuf5oq7EswaAiX2SBv0cGqplLa96MV5iQJGQ&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=tzn-3EbBrn8oS9aYflNYbt2PCRSB4fw9fsQVp0BrcqQ&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=jXvZf4EvOiE0cyJETZrkk-bmGjOrJMuPw45pvNgkN0w&e=>). 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. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=zXDsE0OQuf5oq7EswaAiX2SBv0cGqplLa96MV5iQJGQ&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=tzn-3EbBrn8oS9aYflNYbt2PCRSB4fw9fsQVp0BrcqQ&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=jXvZf4EvOiE0cyJETZrkk-bmGjOrJMuPw45pvNgkN0w&e=>). 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. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KqXYzSPrn59i7rcf2tvSFtWY5xEYv3NjmLqSXutgyYg&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=zXDsE0OQuf5oq7EswaAiX2SBv0cGqplLa96MV5iQJGQ&e=> _______________________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=tzn-3EbBrn8oS9aYflNYbt2PCRSB4fw9fsQVp0BrcqQ&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=jXvZf4EvOiE0cyJETZrkk-bmGjOrJMuPw45pvNgkN0w&e=>). 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. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KqXYzSPrn59i7rcf2tvSFtWY5xEYv3NjmLqSXutgyYg&e=> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
How about: “Enabling ICANN, in its role as data controller, to enforce its policies and contracts related to the operation and maintenance of the SSAD.”Plus anything ICANN ORG feels necessary to add. Let ICANN ORG define its own purpose. that way, it will be a true reflection of its purpose, not an aspirational image that may or may not reflect the views of various SGs of what that purpose should be. -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH* T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. On Tue, Mar 10, 2020 at 2:56 PM King, Brian <Brian.King@markmonitor.com> wrote:
Hi all,
The IPC reiterates the importance of this purpose, in whatever form it might ultimately take. With thanks to several of you for your helpful perspective, I propose the language below to replace Purpose 2, hopefully reflecting the guidance received from EPDP colleagues from various parts of the community.
“Enabling ICANN, in its role as data controller, to enforce policies related to the “maintenance of and access to accurate and up-to-date information concerning registered names and name servers,” including the Registration Data Policy and **Placeholder Name for Phase 2 Policy (if not also Registration Data Policy)**. (ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)”
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 * markmonitor.com <http://www.markmonitor.com>*
*MarkMonitor *Protecting companies and consumers in a digital world
*From:* Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> *On Behalf Of *Hadia Abdelsalam Mokhtar EL miniawi *Sent:* Tuesday, March 10, 2020 9:50 AM *To:* Volker Greimann <vgreimann@key-systems.net>; Alan Woods <alan@donuts.email> *Cc:* GNSO EPDP <gnso-epdp-team@icann.org> *Subject:* Re: [Gnso-epdp-team] Purpose 2
Dear All,
The positive thing about the emails on this topic is that we all agree the SSR of the DNS is an ICANN purpose for which the registration data could be processed. The difference in opinion comes from the fact that some of us do not find it necessary to mention the purpose and others would like the purpose to be more specific. My suggestion was not to specify purpose 2 with more purposes but to specify purpose 2 by clearly stating the processing activities that this purpose might entail. This is necessary because we shall need to inform the data subjects of how their data might be processed and for which purposes. Being clear and transparent in our report about the purposes and processing activities is better than just relying on the assumption that the readers of the report know that the disclosure of the registration data to third parties with legitimate interests and lawful bases is a right under GDPR.
Hadia
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On Behalf Of *Volker Greimann *Sent:* Thursday, March 05, 2020 5:49 PM *To:* Alan Woods *Cc:* GNSO EPDP *Subject:* Re: [Gnso-epdp-team] Purpose 2
Essentially:
Just because it is not part of the SSAD, it does not mean ICANN cannot do it. They may not be able to use SSAD for it, but there are other ways.
For Example: Escrow does not rely on SSAD. That data deposit occours outside of SSAD/RDAP/Whois. If public whois never existed, escrow would still have been possible.
Volker
Am 05.03.2020 um 15:27 schrieb Alan Woods:
HI all,
I truly cannot believe we are still having the same conversations
Let me 1st deal with Alan's statement re "SOME 3rd party requests are in fact in support of ICANN's mission"
Agreed, Alan. "Support" - not "contracted to", not "obliged to" or not anything that denotes that they are in any way an actual legal and direct part of the data processing which we have been discussing for years now. These 3rd parties maintain their own, completely separate , possibly quite aligned, purposes to us. They may share a goal, an Ideal or a mission, but they are legal strangers to this CLOSED data processing ecosystem. By continuously invoking their aligned but legally separate 'purposes' - that is conflation.
For the wider questions, I think we need to be crystal clear here. I think we need to call out 3 very important things are causing a lot of misunderstandings both in the past week and indeed beyond:
*1) IS SSR a purpose?:*
The URS is a purpose. The UDRP is a purpose. Contacting a registrant to deal with issues with the Domain, is a purpose: but let's be clear SSR is far bigger than a mere purpose. To be especially clear, nothing the EPDP will do or say, can change that, as it is enshrined at ICANN's core.
ICANN (Community, org, GNSO process) may decide to process data in a manner that they believe is reasonable for the protection of SSR. They don't need the EPDP's permission to do so.
To draw a clumsy analogy, (bear with me) Think of SSR as a very large building. That building has rooms that make up the individual efforts (such as the URS, UDRP, Spec 11 (3)b etc.) These rooms are the purposes which must be described on our policy. - a visitor to the 'SSR building' may look at the building but they will have no idea of what's in there or where they are supposed to go. They consult the building directory/map ( which is the privacy policy) and they can see which rooms are in that building and more importantly what each room contains.
Weird analogy aside, as an example. the processing of data for URS or UDRP - this is a tangible thing that has stated rules, processes, procedures - all of which try to outline the use of any personal data in that process. The URS and the UDRP are without a doubt a part of the SSR efforts of the community, but were I but an auspicious bystander - If I was merely told that my data will be used for the purposes of SSR ... and not told specifically about the URS / UDRP, I would be utterly clueless as how my data may be used. That is the very problem we apparently are stuck on here - SSR grounds a purpose - but it is not a purpose in it's own right.
*NOTE: just seeing Hadia's email now - her suggestion to further define a purpose with further purposes - is EXACTLY the point here, and why Purpose 2 is considered far too broad to be effective. *
2) * If SSR is not stated as a 'purpose'*, *then ICANN can't process data for SSR*.
*This is absolutely not true.*
Policies can continue to be created that add to the efforts to protect the SSR. NOTHING stops ICANN and the community from creating any new purposes with SSR at its core. To use the building analogy again (sorry) - The Building is the Bylaws -It's already built - we can create as many rooms in that building as we can imagine, as long as they are up the Building's standards and where there will be people staying in those rooms, that they meet the GDPR building regulations (including giving all existing tenants notice of the new rooms).
We should also note that where policy necessitates a change to the manner in which the CPs or ICANN handle personal data, then obviously as our privacy policies are not governed by consensus policy, but any competent data controller, would merely ensure a process of registrant notification and necessary updates to our individual privacy policies. Again this is not a block to us implementing additional data processing, just that we need to ensure that we fulfil our legal obligations to inform the data subjects appropriately about the change, impact etc..
ICANN holds a very unique and very strong position to sponsor and enforce such policy creation, not because the EPDP somehow granted a 'purpose to create purposes for SSR' - but because it is the actual mission and reason for being of ICANN as is helpfully enshrined in its bylaws and mission..
*Finally and this is as HUGE one*
3) *Nothing in the conversation relating to Purpose II, affects or is intended to affect, or in ANY WAY prevent the SSAD from occurring.*
That is completely separate. SSAD is the operationalization of a process for disclosure of data to third parties. That remains completely possible *regardless of Purpose II or NOT *- we do not need to create a purpose to disclose data to 3rd parties - that's the way the law is written. Phase II is defining this process for disclosure, making a process that currently EXISTS (in reality and as permitted by law) so that it is in a more streamlined and predictable manner. Any suggestion otherwise is simply not true.
Sorry about the length as per usual, but I think we need to move past certain assumptions, so that we can focus on our actual task at hand.
Thank you!
[image: Image removed by sender. Donuts Inc.] <https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=7mINsuiW2IIxt8JwAPtkTH0WvTigF5a2mUjYF8PYHGI&e=>
*Alan Woods*
Senior Compliance & Policy Manager, Donuts Inc. ------------------------------
Suite 1-31,
Block D, Iveagh Court
Harcourt Road
Dublin 2, County Dublin Ireland
[image: Image removed by sender.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=-l1IMqW_DKhwYRH5OqyxHFipdxqIpENIcAm34tmIG58&e=> [image: Image removed by sender.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=ms_iCWKvT2eUYgKL1ARrmpVgeHTeKdgASIhUx6nsUP4&e=> [image: Image removed by sender.] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=XvDGUW_wi--04yRDbhjRho4NXA6fGh2sSPuBn693EmQ&e=>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank yo
On Thu, Mar 5, 2020 at 10:41 AM Volker Greimann <vgreimann@key-systems.net> wrote:
I fully agree with your first sentence. For this reason, specificity of the actual purposes is required instead of the blanket statement proposed up to now.
Ultimately, any ICANN purpose must be specifically defined by the questions of what is collected for what specific purpose for and with whom it may be shared.
Say we take escrow as a purpose, which is likely univerally agreed as a valid ICANN purpose:
ICANN will collect registration data to: protect the ownership of a data subject in his registered domain names in case of a registry or registrar failure or de-accreditation. For this purpose, the data may be shared with escrow service providers x,y,z (and potentially others) as well as other contracted parties who may be assigned to take over the management of the affected domain name registrations.
The language is not perfect, but I hope this illustrates the level of specificity I am seeking here. If ICANN has purposes (and I think we agree that it does), we need to specify these purposes by saying what, how and why.
Best,
Volker
Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
We need not forget that data subjects need to know with whom their data might be shared and for what purposes. To this end purpose 2 is important as it establishes one core purpose for processing the data related to ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in May 2019 under purposes of processing and access model, the EC say "For this reason we would recommend revising the formulation of purpose two by excluding the second part of the purpose "through enabling responses to lawful data disclosure requests" and maintaining a broader purpose " Contribute to the maintenance of the security, stability and resiliency of the Domain Name System in accordance with ICANN's mission"
This was the recommendation of the EC to us in May 2019, the question now is why don't we want to follow this recommendation? Maintaining the SSR of the internet is ICANN's core mission and is indeed a purpose for which data might be processed why don't we want to be clear about this.
Hadia
*From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org <gnso-epdp-team-bounces@icann.org>] *On Behalf Of *Alan Greenberg *Sent:* Thursday, March 05, 2020 2:18 AM *To:* Margie Milam; brian.kingATmarkmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__brian.kingATmarkmonitor.com&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KRnVvjEJ4MvLUWmbq5B_tdtmgBLnTMgwzLCi6dLG398&e=>; gnso-epdp-team@icann.org *Subject:* Re: [Gnso-epdp-team] Purpose 2
I have to agree with Margie. These are all important things and we cannot be left at some later date being told that we cannot do this because it was never mentioned to registrants.
I could live with a much more general statement, but we have been told by the CPH that they need something less vague to put in their policies to registrants.
Although I do not believe there is any merit in pursuing it, I will restate that SOME 3rd party requests are in fact in support of ICANN's mission (those that directly protect the SSR of the DNS) and I believe that the statement that we were conflating 3rd-party purposes with our own was partially in error.
Alan
At 04/03/2020 05:50 PM, Margie Milam wrote:
We support Brian’s proposed Purpose 2 below, and note that without it – theere are many gaps, including:
- Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.) - Conducting research using the contacts - Coordinating cyber-attack responses such as Conficker & other cyber attacks - Publishing Accuracy Reporting System (ARS) reports - Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract - Implementing & testing escrow deposits with 3rd party escrow providers
All the best,
Margie, Mark & Steve On behalf of the BC
* Margie Milam *IP Enforcement & DNS Policy Lead | Facebook Legal NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents.
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> *Reply-To: *"brian.kingATmarkmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__brian.kingATmarkmonitor.com&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KRnVvjEJ4MvLUWmbq5B_tdtmgBLnTMgwzLCi6dLG398&e=>" <brian.king@markmonitor.com> <brian.king@markmonitor.com> *Date: *Wednesday, March 4, 2020 at 10:12 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> <gnso-epdp-team@icann.org> *Subject: *[Gnso-epdp-team] Purpose 2
Hi all,
Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC ), I propose the below:
Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.†(ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726 markmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=>
*MarkMonitor *Protecting companies and consumers in a digital world
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=zXDsE0OQuf5oq7EswaAiX2SBv0cGqplLa96MV5iQJGQ&e=> _______________________________________________ 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=tzn-3EbBrn8oS9aYflNYbt2PCRSB4fw9fsQVp0BrcqQ&e=>) and the website Terms of Service ( https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=jXvZf4EvOiE0cyJETZrkk-bmGjOrJMuPw45pvNgkN0w&e=>). 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.
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=zXDsE0OQuf5oq7EswaAiX2SBv0cGqplLa96MV5iQJGQ&e=>
_______________________________________________
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=tzn-3EbBrn8oS9aYflNYbt2PCRSB4fw9fsQVp0BrcqQ&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=jXvZf4EvOiE0cyJETZrkk-bmGjOrJMuPw45pvNgkN0w&e=>). 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.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KqXYzSPrn59i7rcf2tvSFtWY5xEYv3NjmLqSXutgyYg&e=>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Depdp-2Dteam&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=zXDsE0OQuf5oq7EswaAiX2SBv0cGqplLa96MV5iQJGQ&e=> _______________________________________________ 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=tzn-3EbBrn8oS9aYflNYbt2PCRSB4fw9fsQVp0BrcqQ&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=jXvZf4EvOiE0cyJETZrkk-bmGjOrJMuPw45pvNgkN0w&e=>). 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.
-- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.key-2Dsystems.net&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=qXyYavrISX4mss-RzvdqfSHoskgtQACiQZdp76F4G4U&s=KqXYzSPrn59i7rcf2tvSFtWY5xEYv3NjmLqSXutgyYg&e=>
Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin
Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
We support Brian’s proposed Purpose 2 below, and note that without it – there are many gaps, including:
* Operationalizing and implementing new policies and contract provisions (RDAP, transfers, TM Clearinghouse, etc.)
Can be done with and without the actual data.
* Conducting research using the contacts
Research is broad. what does this mean? does the proposed research meet a balancing test?
* Coordinating cyber-attack responses such as Conficker & other cyber attacks
Not really something ICVANN itself does, it it?
* Publishing Accuracy Reporting System (ARS) reports
They can continue to publish these reports. Not much is going to be in them though. But as I said on the call, just because it was possible to do, it may not necessarily be ok (or strictly necessary).
* Conducting testing of new registrar/registries to ensure that the WHOIS systems work in the manner required by the contract
Does ICANN actually do that? But even if they did, they can now test RDAP responses if they work in the manner required in the temp spec and later of the SSAD.
* Implementing & testing escrow deposits with 3^rd party escrow providers
That is actually done by the escrow providers, who then just report to ICANN. It is not curently impacted but I agree that Escrow should be a purpose of ICANN.
All the best,
Margie, Mark & Steve
On behalf of the BC
**
**
*Margie Milam*
IP Enforcement & DNS Policy Lead | Facebook Legal**
NOTICE: This email (including any attachments) may contain information that is private, confidential, or protected by attorney-client or other privilege. Unless you are the intended recipient, you may not use, copy, or retransmit the email or its contents.
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org> *Reply-To: *"brian.kingATmarkmonitor.com" <brian.king@markmonitor.com> *Date: *Wednesday, March 4, 2020 at 10:12 AM *To: *"gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> *Subject: *[Gnso-epdp-team] Purpose 2
Hi all,
Following last week’s conversation about some EPDP members’ desire to have a bit more specificity in Purpose 2 (the irony of which is not lost on the IPC 😊), I propose the below:
Contributing to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission, specifically “maintenance of and access to accurate and up-to-date information concerning registered names and name servers.” (ICANN Bylaws, Annex G-1; ICANN Bylaws, Annex G-2)
*Brian J. King * Director of Internet Policy and Industry Affairs
T +1 443 761 3726_ markmonitor.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=>_
*MarkMonitor *Protecting companies and consumers in a digital world
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ 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. -- Volker A. Greimann General Counsel and Policy Manager *KEY-SYSTEMS GMBH*
T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Alexander Siffrin Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
participants (7)
-
Alan Greenberg -
Alan Woods -
Hadia Abdelsalam Mokhtar EL miniawi -
King, Brian -
Margie Milam -
Mueller, Milton L -
Volker Greimann