February 2019 - Gnso-epdp-team

Re: [Gnso-epdp-team] Recommendation on privacy/proxy data.
by Alan Greenberg Feb. 5, 2019

Feb. 5, 2019

Ayden, Why not leave it to the registrar to decide. We have heard an awful lot about potential for contracted party risk. They can make their own decision. And those who have already implemented secure anonymized e-mail do not have to scrap it and implement something completely new, as they would if we follow your suggestion. Alan At 04/02/2019 08:00 PM, Ayden Férdeline wrote: Hi Alan G., I happen to agree that this could be an implementation issue. However, we must balance the cost of implementing such a complex system and rolling it out globally against the benefits to registrants, who are ultimately those who will bare its cost. In light of this consideration, and in recognizing the harm that could arise from an improper implementation, I cannot find myself supporting this proposal. I see no benefit to the registrant of the publication of a pseudonymised email that would not otherwise be achieved by making them contactable through a web form. Kind regards, Ayden Férdeline ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 4, 2019 7:19 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: That *may* apply in some cases but certainly not all. There are European registrars that use anonymized addresses that change regularly (such as weekly, daily or oftener). There is no way to correlate them with previously published data. It also addresses the worry that the anonymized address can be used for SPAM. This is an implementation issue. Each registrar can use a technique which meets their needs and reduces their risk. Alan At 04/02/2019 06:20 PM, Ayden FÃ©rdeline wrote: I agree with Miltonâ��s interpretation. We also have case law that can help us understand the meaning of where pseudonymisation is â��reasonably likelyâ�� to lead to the ide identification of a data subject. In Breyer v Germany, the Court of Justice of the European Unionâ��s ruling mirrors much of the de debate we are having here, and it found that pseudonymized data is almost always personal data. (While this case was a judgment on the 1995 Data Protection Directive and not the GDPR, the text of Recital 26 in the GDPR and in the Directive differ very little in substance.) In light of this, and given the relative ease with which historical WHOIS records can be retrieved, I believe it is only prudent that pseudonymised email addresses are not published. Best wishes, Ayden â� â��â��â��â��â��Â��â�� Original Message â��â��â�â��â��â��â�� On Monday, February 4, 2019 1:57 PM, Mueller, Milton L <milton(a)gatech.edu> wrote: Marc: I have paraphrased this as: â��If a processor were to publish or disclose multltiple personal data, one of which was a pseudonym, and if that collection of data could be used to render the pseudonym identifiable, then the pseudonym would be considered to be personal data. However, if the processor were to publish a pseudonym, and a third party were to subsequently locate additional data, available from different processors or even from the same processor in a different context, and were then able to use these separate data to unmask the pseudonym and render it identifiable, such third party correlation ability would NOT require the processor to treat the pseudonym as personal data.â� I donâ��t find your lawyersâ�� opinion very conviy convincing, Marc. She is saying that even if itâ��s knownown for a fact that the pseudonym can be combined with other data elements that are readily accessible to anyone to identify the subject, it is not personally identifiable simply because all the data isnâ��t in one place. Th That doesnâ��t pass the giggle test. Second, the Whois DOES publish additional, multiple personal data, such as country, state, city, nameserver, domain name, etc. all of which when combined could be used to identify. Dr. Milton L Mueller Professor, School of Public Policy<http://spp.gatech.edu/> Georgia Institute of Technology Internet Governance Project http://internetgovernance.org/ /marksv From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan(a)donuts.email<mailto:alan@donuts.email>> Cc: EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data. Thanks Alan. As always I appreciate your input and views. A few thoughts and questions on your proposed solution. First, given all of the "MAYs" in your suggested update, it is not clear to me how this will be translated in the implementation phase. Specifically it is a no-op from a compliance point of view. I understand this may be the main reason for your update, but we end up with a Recommendation with little value. Second, given the general agreement that we avoid "squishy" language in our purposes and recommendations, the language you propose is unclear (to me at least). If a Registrar or Registry decides to not return P/P data or the "existing p/p pseudonymized emailâ�� does that mean no email adddress will be available in a public response? If so that seems to go against our existing Contractibility purpose (Purpose 3). (Alan G made this point I believe.) Or does this language assume that there will be a Registrar pseudonymized email that points to a P/P pseudonymized email? Both seem problematic. Third, regarding the language you point out in Recital 26 of the GDPR, its not clear to me it applies in the privacy/proxy context, where the only the psuedonymized email could be seen as personal. Perhaps this would be a good question to pose to Ruth. From what I understand if a processor were to publish or disclose multiple personal data, one of which was a pseudonym, and if that collection of data could be used to render the pseudonym identifiable, then the pseudonym would be considered to be personal data. For responses that only included P/P data this wouldn't be the case. Fourth, I appreciate your concern that it may not be possible to figure out a P/P provider and suggest we can use the language in the RAA (Section 2) to be more specific here - essentially limit it (for now) to affiliated services. e.g. â��For any Proxy S Service or Privacy Service offered by the Registrar or its Affiliates, including any of Registrar's or its Affiliates' P/P services distributed through Resellers, and used in connection with Registered Names Sponsored by the Registrar,". In the future, and once the PPIRT completes, all accredited P/P services will be flagged in RDS/WHOIS (PPSAI Recommendation 4) so this issue will be solved. Finally, I continue to believe we can find a pragmatic solution where we eliminate (or perhaps minimize) the situation where P/P data is returned in response to a "reasonable disclosure" request. It is a very inefficient use of time/cycles for both the requestor and person responsible for manually processing these requests. This was the main reason for the Temp Spec language and this new Recommendation. If we can't address this issue in this new Rec then perhaps language needs to be added to Rec 12 to address this case.... Apologies for the long email. Alex ___________ Alex Deacon Cole Valley Consulting alex(a)colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan(a)donuts.email<mailto:alan@donuts.email>> wrote: Thank you Alex for reopening this matter. >From a practicality POV the inclusion of a pseudonymised email in a publication is a disclosure of public data, as a pseudonymised email, is still an email for a data subject. It may be in a form the data subject does not recognize, but I believe a number of excellent and practical examples, such as auto-relay / auto out of office responses could easily identify the non-pseudonymised email and lead to identification of the Data Subject. I refer you recital 26 of the GDPR: "�Perrsonal data whiich have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person..." Alas the recommendation as worded, although I understand the practicality that is driving it, does not properly address data protection concerns. There is a lot of back and of forth possible on whether pseudonymisation may count as anonymization when published to a 3rd party, however in the context of Domain Names, where the domain name, and even the associated content, could be capable of linking the individual to the pseudonymised data (which is completely outside of outside of our control, but still relevant to our risk assessment), we need to tread carefully; more carefully than the ePDP has either the time or the scope to consider. To refer again to our goal : We must look to the state of the data that is in the RDDS currently, and whether the publication of individual data currently used would be data protection compliant or not. In its current state, with the myriad the uncertainties, it is not, therefore our recommendation must be not to publish. SOLUTION Allow the registrar / registry to consider (as Controller) the feasibility and the risk as it applies to them? Unless we, at this late stage, the ePDP can provide an actual means or suggestion as to implementation of how a registrar / registry can effectively figure out who is a P&P provider and thus publish those only details without an increase to risk, then our choice is plain. If the recommendation is to stand, use of MAY, and other permissive language, as opposed to a 'must' will allow each CP to assess the risk as they see it, as it all comes down to the fact that the ePDP cannot force the CPs to assume higher risk to appease some. Recommendation XX In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar (and Registry where applicable) MAY include in the public WHOIS and return in response to any query full WHOIS data, which may also include the existing privacy/proxy pseudonymized email. Kind regards, Alan Alan Woods<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> ________________________________ The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> 15-18 Earlsfort Terrace<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Dublin 2, County Dublin<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Ireland<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> 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.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex(a)colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Our review of ICANN's input on Temp Spec topics that were not covered by the Initial Report reminded me that we had at one point discussed ensuring that the current Temp Spec language on how Privacy/Proxy data should be handled (Appendix A 2.6) should added as a recommendation. Something along the lines of - <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST include in the public WHOIS and return in response to any query full WHOIS data, including the existing privacy/proxy pseudonymized email.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> First, given the time and effort needed to properly process "reasonable disclosure" requests by Registrars it seems useful to avoid a situation where non-public data is quickly found to be P/P service data. Avoiding this situation and simply including P/P data in the the initial response would make life better for all involved. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Second, there is no need to redact information that is already "redacted" (by definition) by the P/P service. Also, given P/P services list the information of a legal person (in the case of a registrar affiliated service provider) in the place of the RNH's info it seems further redaction is unnecessary. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> alex(a)colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 1

ICANN Compliance question in relation to EPDP Recommendation 7
by Marika Konings Feb. 4, 2019

Feb. 4, 2019

Dear EPDP Team, Please find hereby a question from ICANN Contractual Compliance in relation to recommendation #7: Hi Kurt/EPDP Team, There are multiple contractual requirements which require contracted parties to provide ICANN data and records which may include registration data (including, but not limited to 2013 RAA Sections 3.4.3, 3.15 and 3.18; and new gTLD Base RA Section 2.11 and Specification 11, Section 3b). ICANN requires such documentation to facilitate its review of compliance with other provisions in the ICANN agreements and policies. With this understanding, can the EPDP team please clarify which contractual requirements Recommendation 7 applies to and how they should be changed? Specifically, is Recommendation 7 intended to limit all contractual requirements where ICANN is currently permitted to request information and records to only permitting ICANN to request the data elements listed in Recommendation 7’s chart? Or may ICANN continue to request the information and records specified in the existing contractual requirements, with the understanding that if there is registration data included in the records requested that it may be limited by the allowing contracted party to only include registration data from the list of data elements in the chart? Thank you, ICANN Contractual Compliance Best regards, Caitlin, Berry and Marika

5 4

Re: [Gnso-epdp-team] Recommendation on privacy/proxy data.
by Alan Greenberg Feb. 4, 2019

Feb. 4, 2019

That *may* apply in some cases but certainly not all. There are European registrars that use anonymized addresses that change regularly (such as weekly, daily or oftener). There is no way to correlate them with previously published data. It also addresses the worry that the anonymized address can be used for SPAM. This is an implementation issue. Each registrar can use a technique which meets their needs and reduces their risk. Alan At 04/02/2019 06:20 PM, Ayden Férdeline wrote: I agree with Milton’s interpretation. We also have case law that can help us understand the meaning of where pseudonymisation is “reasonably likely” to lead to the identification of a data subject. In Breyer v Germany, the Court of Justice of the European Union’s ruling mirrors much of the debate we are having here, and it found that pseudonymized data is almost always personal data. (While this case was a judgment on the 1995 Data Protection Directive and not the GDPR, the text of Recital 26 in the GDPR and in the Directive differ very little in substance.) In light of this, and given the relative ease with which historical WHOIS records can be retrieved, I believe it is only prudent that pseudonymised email addresses are not published. Best wishes, Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, February 4, 2019 1:57 PM, Mueller, Milton L <milton(a)gatech.edu> wrote: Marc: I have paraphrased this as: “If a processor were to publish or disclose multiple personal data, one of which was a pseudonym, and if that collection of data could be used to render the pseudonym identifiable, then the pseudonym would be considered to be personal data. However, if the processor were to publish a pseudonym, and a third party were to subsequently locate additional data, available from different processors or even from the same processor in a different context, and were then able to use these separate data to unmask the pseudonym and render it identifiable, such third party correlation ability would NOT require the processor to treat the pseudonym as personal data.” I don’t find your lawyers’ opinion very convincing, Marc. She is saying that even if it’s known for a fact that the pseudonym can be combined with other data elements that are readily accessible to anyone to identify the subject, it is not personally identifiable simply because all the data isn’t in one place. That doesn’t pass the giggle test. Second, the Whois DOES publish additional, multiple personal data, such as country, state, city, nameserver, domain name, etc. all of which when combined could be used to identify. Dr. Milton L Mueller Professor, School of Public Policy<http://spp.gatech.edu/> Georgia Institute of Technology Internet Governance Project http://internetgovernance.org/ /marksv From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Alex Deacon Sent: Saturday, February 2, 2019 11:57 AM To: Alan Woods <alan(a)donuts.email<mailto:alan@donuts.email>> Cc: EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] Recommendation on privacy/proxy data. Thanks Alan. As always I appreciate your input and views. A few thoughts and questions on your proposed solution. First, given all of the "MAYs" in your suggested update, it is not clear to me how this will be translated in the implementation phase. Specifically it is a no-op from a compliance point of view. I understand this may be the main reason for your update, but we end up with a Recommendation with little value. Second, given the general agreement that we avoid "squishy" language in our purposes and recommendations, the language you propose is unclear (to me at least). If a Registrar or Registry decides to not return P/P data or the "existing p/p pseudonymized email” does that mean no email address will be available in a public response? If so that seems to go against our existing Contractibility purpose (Purpose 3). (Alan G made this point I believe.) Or does this language assume that there will be a Registrar pseudonymized email that points to a P/P pseudonymized email? Both seem problematic. Third, regarding the language you point out in Recital 26 of the GDPR, its not clear to me it applies in the privacy/proxy context, where the only the psuedonymized email could be seen as personal. Perhaps this would be a good question to pose to Ruth. From what I understand if a processor were to publish or disclose multiple personal data, one of which was a pseudonym, and if that collection of data could be used to render the pseudonym identifiable, then the pseudonym would be considered to be personal data. For responses that only included P/P data this wouldn't be the case. Fourth, I appreciate your concern that it may not be possible to figure out a P/P provider and suggest we can use the language in the RAA (Section 2) to be more specific here - essentially limit it (for now) to affiliated services. e.g. “For any Proxy Service or Privacy Service offered by the Registrar or its Affiliates, including any of Registrar's or its Affiliates' P/P services distributed through Resellers, and used in connection with Registered Names Sponsored by the Registrar,". In the future, and once the PPIRT completes, all accredited P/P services will be flagged in RDS/WHOIS (PPSAI Recommendation 4) so this issue will be solved. Finally, I continue to believe we can find a pragmatic solution where we eliminate (or perhaps minimize) the situation where P/P data is returned in response to a "reasonable disclosure" request. It is a very inefficient use of time/cycles for both the requestor and person responsible for manually processing these requests. This was the main reason for the Temp Spec language and this new Recommendation. If we can't address this issue in this new Rec then perhaps language needs to be added to Rec 12 to address this case.... Apologies for the long email. Alex ___________ Alex Deacon Cole Valley Consulting alex(a)colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan(a)donuts.email<mailto:alan@donuts.email>> wrote: Thank you Alex for reopening this matter. >From a practicality POV the inclusion of a pseudonymised email in a publication is a disclosure of public data, as a pseudonymised email, is still an email for a data subject. It may be in a form the data subject does not recognize, but I believe a number of excellent and practical examples, such as auto-relay / auto out of office responses could easily identify the non-pseudonymised email and lead to identification of the Data Subject. I refer you recital 26 of the GDPR: "�Personal data whiich have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person..." Alas the recommendation as worded, although I understand the practicality that is driving it, does not properly address data protection concerns. There is a lot of back and of forth possible on whether pseudonymisation may count as anonymization when published to a 3rd party, however in the context of Domain Names, where the domain name, and even the associated content, could be capable of linking the individual to the pseudonymised data (which is completely outside of outside of our control, but still relevant to our risk assessment), we need to tread carefully; more carefully than the ePDP has either the time or the scope to consider. To refer again to our goal : We must look to the state of the data that is in the RDDS currently, and whether the publication of individual data currently used would be data protection compliant or not. In its current state, with the myriad the uncertainties, it is not, therefore our recommendation must be not to publish. SOLUTION Allow the registrar / registry to consider (as Controller) the feasibility and the risk as it applies to them? Unless we, at this late stage, the ePDP can provide an actual means or suggestion as to implementation of how a registrar / registry can effectively figure out who is a P&P provider and thus publish those only details without an increase to risk, then our choice is plain. If the recommendation is to stand, use of MAY, and other permissive language, as opposed to a 'must' will allow each CP to assess the risk as they see it, as it all comes down to the fact that the ePDP cannot force the CPs to assume higher risk to appease some. Recommendation XX In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar (and Registry where applicable) MAY include in the public WHOIS and return in response to any query full WHOIS data, which may also include the existing privacy/proxy pseudonymized email. Kind regards, Alan Alan Woods<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Senior Compliance & Policy Manager, Donuts Inc. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> ________________________________ <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> The Victorians, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> 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.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon <alex(a)colevalleyconsulting.com> wrote:<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> All, <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Our review of ICANN's input on Temp Spec topics that were not covered by the Initial Report reminded me that we had at one point discussed ensuring that the current Temp Spec language on how Privacy/Proxy data should be handled (Appendix A 2.6) should added as a recommendation. Something along the lines of - <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Recommendation XX<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST include in the public WHOIS and return in response to any query full WHOIS data, including the existing privacy/proxy pseudonymized email.<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> There are two reasons why this is useful, IMO. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> First, given the time and effort needed to properly process "reasonable disclosure" requests by Registrars it seems useful to avoid a situation where non-public data is quickly found to be P/P service data. Avoiding this situation and simply including P/P data in the the initial response would make life better for all involved. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Second, there is no need to redact information that is already "redacted" (by definition) by the P/P service. Also, given P/P services list the information of a legal person (in the case of a registrar affiliated service provider) in the place of the RNH's info it seems further redaction is unnecessary. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Happy to discuss further on a future call. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Thanks. <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Alex<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> ___________<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Alex Deacon<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> Cole Valley Consulting<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> alex(a)colevalleyconsulting.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> +1.415.488.6009<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.dom…> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 1

Recommendation on privacy/proxy data.
by Alex Deacon Feb. 4, 2019

Feb. 4, 2019

All, Our review of ICANN's input on Temp Spec topics that were not covered by the Initial Report reminded me that we had at one point discussed ensuring that the current Temp Spec language on how Privacy/Proxy data should be handled (Appendix A 2.6) should added as a recommendation. Something along the lines of - Recommendation XX In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST include in the public WHOIS and return in response to any query full WHOIS data, including the existing privacy/proxy pseudonymized email. There are two reasons why this is useful, IMO. First, given the time and effort needed to properly process "reasonable disclosure" requests by Registrars it seems useful to avoid a situation where non-public data is quickly found to be P/P service data. Avoiding this situation and simply including P/P data in the the initial response would make life better for all involved. Second, there is no need to redact information that is already "redacted" (by definition) by the P/P service. Also, given P/P services list the information of a legal person (in the case of a registrar affiliated service provider) in the place of the RNH's info it seems further redaction is unnecessary. Happy to discuss further on a future call. Thanks. Alex ___________ *Alex Deacon* Cole Valley Consulting alex(a)colevalleyconsulting.com +1.415.488.6009

10 15

Re: [Gnso-epdp-team] [Ext] Re: For your review - latest version of EPDP Team Final Report
by Marika Konings Feb. 4, 2019

Feb. 4, 2019

Alan, this our mistake – we had understood your proposal to relate to the data element workbooks not the purpose statement itself, and as such this update was going to be included in the data element workbooks. In your message you state: Add to rationale: “To allow ICANN to carry out accuracy audits of registration contact data, ICANN may request from Registry Operators and Registrars the minimum data for randomly selected registrations. Under F-PA2 replace "ICANN org compliance" with "ICANN org" (2 places) Under F-PA4 replace "ICANN Compliance" with "ICANN org" and add to Lawful Basis "May go beyond the life of registration in order to complete accuracy audit and compliance processing, not to exceed one year." Data element table will need to include any contact information still in use post EPDP. Can you please clarify what you mean with ‘add to the rationale’ if it is not the explanation that is provided in the data element workbooks? Best regards, Caitlin, Berry and Marika From: Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Monday, February 4, 2019 at 16:33 To: Marika Konings <marika.konings(a)icann.org>, 'EPDP' <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] For your review - latest version of EPDP Team Final Report I note that the language I proposed on the integration of the ARS into Purpose 6 is not included. When will we discuss this? Alan At 01/02/2019 06:10 PM, Marika Konings wrote: Dear EPDP Team, Please find attached for your review the latest version of the Final Report. In relation to section 5, EPDP Team Responses to Charter Questions & Recommendations, please note that those sections highlighted in green are considered finalized for inclusion in the Final Report, sections in blue are still under review / consideration (but these do include the latest language, unless indicated differently). For substantive issues or concerns, please flag these on the mailing list by Monday 4 March COB so that these can be included in the meeting agendas for next week. If you want to reference specific parts of the report, please use the line numbering of the attached pdf version. For any minor edits / updates, please use the google doc: https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnL… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> . On the wiki (see https://community.icann.org/x/VZwWBg) we have also posted a Word and clean version for those of you that prefer that format. As you review the Final Report, we want to remind you of Kurtâ€™s message that also seem to apply here: â€œstudy the balancing that went into this and be ready to accept wording in cases where it does not match your own choiceâ€. As a reminder, revisions to the data elements workbooks to ensure alignment with EPDP recommendations are being undertaken by a small team which is expected to share the results of its work shortly. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporration for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. Content-Type: application/pdf; name="EPDP Team Draft Final Report - REDLINE - version 1 February 2019.pdf" Content-Description: EPDP Team Draft Final Report - REDLINE - version 1 February 2019.pdf Content-Disposition: attachment; filename="EPDP Team Draft Final Report - REDLINE - version 1 February" 2019.pdf"; size=2997294; creation-date="Fri, 01 Feb 2019 23:10:12 GMT"; modification-date="Fri, 01 Feb 2019 23:10:13 GMT" Content-ID: <B9D117065EEB9B4695A1EFA5CBD4C29B(a)pexch112.icann.org> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 2

Re: [Gnso-epdp-team] FW: Response from ICANN Compliance re. registrations under the 2009 RAA
by Alan Greenberg Feb. 4, 2019

Feb. 4, 2019

Another alternative is to say that the Admin contacts are not to be collected for new, changed or transferred registrations (which are all subject to the 2013 RAA requirement for Registrant contact data) and that the fields will be eliminated once all registrars confirm that all of the registrations under their sponsorship have Registrant contact information. Alan At 04/02/2019 05:14 PM, Alan Greenberg wrote: I do not believe that we can eliminate the Admin contact information (as currently recommended) without a concrete idea of how many registrations might be left without contact information and just a note that implementation should investigate the potential impact. If that investigation (if it is even possible given the data that ICANN possesses) we to show that there are a substantive number of such registrations, what could they do? We know that registrars have resisted the requirement to take corrective action on registration (which is why the validation/verification requirements in the 2013 RAA only apply when there are changes). If we eliminate Admin fields, we must provide for ensuring that all registrations have contact information within a relatively short period of time. The easy fix given the timeline is to not eliminate the Admin fields. Alan At 04/02/2019 08:19 AM, Marika Konings wrote: Dear Alan G., all, In relation to the question regarding the 2009 RAA you formulated a while back, note that ICANN Org had already provided a response: Alan Greenberg’s Question: The EPDP is requesting that ICANN Org confirm that all registrars are now operating under the 2013 RAA. The EPDP is requesting that ICANN Org provide its interpretation of the requirement under the RAA Data retention Specification 1.1 whether registrars, as part of their adoption of the 2013 RAA, are required to ensure that Registrant contact email and telephone fields are completed, or whether the phrase "shall maintain that information" (which was validly allowed to be blank at registration time) allows them to preserve any empty Registrant contact fields. If the former, is Contractual Compliance taking any action to ensure that registrars fulfill this obligation? ICANN org Compliance Response: Registrars are not required to collect additional contact information for 2009 Registrar Accreditation Agreement (RAA) registrations. However, registrars may be required to update existing contact information for 2009 RAA registrations when there is a triggering event under the 2013 RAA that may require them to do so (e.g., the domain name is an inbound transfer, the registrant changes, there is information to suggest the current contact information is incorrect). This response is also posted here: https://community.icann.org/x/ahppBQ. Please let us know if this does not sufficiently address your question. In order to ensure this issue is not overlooked during the implementation phase, would it be helpful to add a sentence along the following lines in the implementation part of the report: “As part of the implementation, consideration needs to be given to the potential impact of these policy recommendations on legacy registrations that without additional mitigation could end up with no contact information if the administrative contact is the only information currently available (this could be the case for a limited number of registrations that are still under the 2009 Registrar Accreditation Agreement)”? Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support � GNSO, Internet Corporation for Assigned Namees and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 2

FW: Response from ICANN Compliance re. registrations under the 2009 RAA
by Marika Konings Feb. 4, 2019

Feb. 4, 2019

Dear Alan G., all, In relation to the question regarding the 2009 RAA you formulated a while back, note that ICANN Org had already provided a response: Alan Greenberg’s Question: The EPDP is requesting that ICANN Org confirm that all registrars are now operating under the 2013 RAA. The EPDP is requesting that ICANN Org provide its interpretation of the requirement under the RAA Data retention Specification 1.1 whether registrars, as part of their adoption of the 2013 RAA, are required to ensure that Registrant contact email and telephone fields are completed, or whether the phrase "shall maintain that information" (which was validly allowed to be blank at registration time) allows them to preserve any empty Registrant contact fields. If the former, is Contractual Compliance taking any action to ensure that registrars fulfill this obligation? ICANN org Compliance Response: Registrars are not required to collect additional contact information for 2009 Registrar Accreditation Agreement (RAA) registrations. However, registrars may be required to update existing contact information for 2009 RAA registrations when there is a triggering event under the 2013 RAA that may require them to do so (e.g., the domain name is an inbound transfer, the registrant changes, there is information to suggest the current contact information is incorrect). This response is also posted here: https://community.icann.org/x/ahppBQ. Please let us know if this does not sufficiently address your question. In order to ensure this issue is not overlooked during the implementation phase, would it be helpful to add a sentence along the following lines in the implementation part of the report: “As part of the implementation, consideration needs to be given to the potential impact of these policy recommendations on legacy registrations that without additional mitigation could end up with no contact information if the administrative contact is the only information currently available (this could be the case for a limited number of registrations that are still under the 2009 Registrar Accreditation Agreement)”? Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

2 1

Proposed agenda - EPDP Team Meeting #42
by Marika Konings Feb. 4, 2019

Feb. 4, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 5 February at 14.00 UTC. Please take note of the following action items in relation to the agenda: * Registry and Registrar EPDP Team Members to review implementation bridge options with respective stakeholder groups and come forward with a proposal for the next EPDP Team meeting on Tuesday, 5 February * EPDP Team to review additional ICANN org questions and indicate on the email list if any of these need to be addressed in the Final Report * Groups to flag any issues or concerns that require further discussion following review of the draft Final Report by Monday 4 February COB Best regards, Caitlin, Berry and Marika ================== EPDP Meeting #42 Agenda Tuesday, 5 February 2019 1. Roll Call & SOI Updates (5 minutes) 1. Welcome and Updates from EPDP Team Chair (5 minutes) * Reminder: process for Final Report input & Consensus Call * Review of outstanding action items * Other updates, if applicable 1. Implementation Transition Period (30 minutes) * Per last week’s action item: “Registry and Registrar EPDP Team Members to review implementation bridge options with respective stakeholder groups and come forward with a proposal for the next EPDP Team meeting on Tuesday, 5 February” * CPs to present proposal * Discuss proposal * Confirmation of agreement reached or next steps to come to agreement 1. Data Elements Workbooks Small Team Update * Update on status of work * Questions / clarifications * Expected next steps 1. Items flagged for further discussion * Privacy / Proxy registrations – see mailing list proposal and discussion * Reasonable access * Other topics to be added, as needed 1. ICANN Org Questions * Per last week’s action item, EPDP Team to review additional ICANN org questions and indicate on the email list if any of these need to be addressed in the Final Report * Consider topics flagged * Discuss proposed approach (‘what happens if these topics are not addressed / covered in the Final Report?’) * Confirmation of agreement reached or next steps to come to agreement 1. Wrap and confirm next meeting to be scheduled for Wednesday, 6 February 2019 at 14.00 UTC (5 minutes) * Confirm action items * Confirm questions for ICANN Org, if any Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

**Reminder** Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 05 February 2019 at 14:00 UTC for 3 hours
by Julie Bisland Feb. 4, 2019

Feb. 4, 2019

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/RJ0WBg Thank you. Kind Regards, Andrea

1 0

Notes and action items from EPDP Team Meeting #41
by Caitlin Tubergen Feb. 2, 2019

Feb. 2, 2019

Dear EPDP Team, Below, please find the notes and action items from the last EPDP meeting on Thursday, 31 January 2019. Best regards, Marika, Berry, and Caitlin --- EPDP Team Meeting #41 31 January 2019 Action Item #1: EPDP Leadership to propose updated language for Rec. 11 (data retention) based on the discussion from today’s meeting. Action Item #2: Registry and Registrar EPDP Team Members to review implementation bridge options with respective stakeholder groups and come forward with a proposal for the next EPDP Team meeting on Tuesday, 5 February. Action Item #3: EPDP Team to review additional ICANN org questions and indicate on the email list if any of these need to be addressed in the Final Report Notes 1. Roll Call & SOI Updates (5 minutes) 2. Welcome and Updates from EPDP Team Chair (5 minutes) Today's meeting will mark the end of public comment review Between today and tomorrow, the Leadership Team will review proposed edits to the draft recommendations and come back with proposed language for inclusion in Final Report. The Support Team will send an updated draft of the Final Report to the EPDP Team tomorrow, Friday, 1 Feb. Following receipt of the proposed language, EPDP Team Members should flag any issues they believe warrant further discussion. There will be meetings on Tuesday, Wednesday, and Thursday of next week. In terms of getting the Final Report out - we plan to distribute the next draft tomorrow, Friday, 1 Feb. Leadership will also send out the consensus call paperwork early next week. There is a status of review document on the wiki page. The next step is for leadership to look at comments received and propose a path forward. Support Team is planning to update the Final Report based on suggested edits as well as agreed-upon text. EPDP Team Feedback: The recommendations should be voted as a package - they should not be voted on in isolation. Crystal clear recommendations are a good goal, but in the process of consensus building, this may be impossible. There needs to be sufficient time to review a final draft so that everyone can see what the report says. a. Reminder: process for email discussions and upcoming deadlines b. Review of outstanding action items c. Other updates, if applicable 3. Continue review of public comments on Initial Report and/or revised recommendations a. Recommendation 11 – Data retention (20 minutes) i. Review small team updates and input provided (see PCRT at https://community.icann.org/x/U4cWBg and small team recommendations). ii. Review input provided (RySG, RrSG, GAC) (5 minutes) Confirmation of agreement reached or next steps to come to agreement (5 minutes) Edits came from Ry/Rr public comments Paragraph 1: One year retention period linked to the TDRP was originally recommended - if it is being retained for purposes of the TDRP, any data retained could only be used for the TDRP. Paragraph 2: The EPDP Team did identify the TDRP as a means to justify the retention period. Registrars, if they use retained data for something under the TDRP, it would be under their own controllership. Paragraph 3: in the absence of having text in the actual recommendation - it should not be construed to mean that contracted parties cannot set their own retention periods for their own purposes. The current waiver procedure must be maintained. Consider a fast track for waivers accepted, that parties within the same jx would be subject to the same waiver without having to apply separately. Waiver procedures do not need to be applied to this recommendation. We may need a general disclaimer that notes that local laws have precedence. It seems that public comments from non-CPH have not been factored into the text of the updated recommendation. Should additional time be considered - public comments note 3 - 6 years. The language here is too restrictive - there may be other uses beyond the Transfer Policy. To make a case to retain the data past one year - does the benefit of investigating something that happened on a name that's not under the registrant's control outweigh the risk to the data subject? Saying data might be necessary at some point in the future is not a good enough reason to retain it The Team could consider remaining open to requests to change the retention period based on certain requirements. Retention periods under one year are highly problematic for investigations. How proportional is it to save data and for how long. The argument has been made to retain data longer. A balance is important here - what worked in the past may not work going forward, and we need to recognize new limitations and adjust accordingly. The EPDP Team, as soon as practicable, recommends ICANN to undertake a review of all active process and procedures - including other lawful needs. Not comfortable with ICANN conducting a study to determine retention for other needs. It’s likely this study would be biased. It's not just about the retention period but also who would have access to the data - this would be part of the study. We need to remember what we are doing here - do any public comments received warrant a change to the language. At this point, there does not appear to be comments that warrant change to the language. With respect to longer retention periods - no one would come up with a robust rationale as to why we need a longer period - therefore, we should keep what we have. Action Item: EPDP Leadership to propose updated language for Rec. 11 based on today's conversation. 4. Implementation Transition Period (30 minutes) The GNSO Council Leadership has requested the team further discuss next steps regarding implementation transition period and notes it may be helpful to include a recommendation in the Final Report. This item was discussed in Toronto, and the Team discussed the bridging of a policy that will be adopted in the interim. The gap is the time b/w when the Temp Spec expires and the new policy goes into effect. The CPH have mixed feelings - could there be a compliance framework MOU with ICANN org, i.e., as long as CPH as doing their best efforts to comply with the new policy. Others are asking for something more formal. The Council Leadership is requesting a recommendation to come from the community, rather than ICANN org. There is not a consensus position within the RySG among the possible avenues forward. It may be more productive to defer this topic until next Tuesday. A framework should have input beyond the contracted parties. However, it would be problematic if there was zero enforcement of the Temp Spec. The general sentiment re: this gap is that the decision should rest with the EPDP Team. Would this compliance framework be enforceable? To the question of timing - if the Team is planning to issue a recommendation of a compliance framework, that could be considered in parallel with finalization of the Final Report. The risk of having something more formal - this could be challenged by a given contracted party as an extension of the Temp Spec - and this may open the door to challenging the Temp Spec was implemented as an SSR emergency. Important to get some guidance from ICANN org on their preferred path forward. Need to think through timelines - this should be fleshed out with some degree of specificity by Tuesday. We need to think about providing a solution in a timely manner. Contracted parties should get support around a model and begin fleshing it out. Action item: CPH to Put formal question in front of stakeholder group and come forward with a proposal for Tuesday's meeting. 5. ICANN Org Questions There are six questions posed by ICANN within this table. Read the first three questions in five minutes. a. ICANN Org Liaisons to introduce questions for discussion 1. RDAP and SLAs – what recommendations and/or guidance needs to be included in the Final Report, or is this to be addressed during implementation? This work comes from a spreadsheet emailed to the EPDP Team. The spreadsheet sought to identify changes from the Temp Spec and also areas where the Initial Report was silent. Is there a good reason why the language was not included in the Initial Report? What will happen to RDAP is the EPDP TEam is silent on this? If there are additional items that need to be discussed, please flag them so we can add to the agendas next week. Question: if the Team is silent, is this to be confirmed as policy, or not? If the Temp Spec does not confirm, requirements from RA/RAA would control. If the Team did not confirm the Temp Spec to be approved as policy, it would not be retained as policy. The difference b/w the Temp Spec and what the EPDP Team is doing is the the EPDP Team is creating a new policy, while the Temp Spec is part of the contracts until May 25. There is no need to include any of these items in the Team's Phase 1 report. RDAP has not been implemented, and this is not necessary for GDPR compliance. What problem would be solved by putting this language in the Final Report? There should be an RDAP mention in the policy, otherwise there is no obligation. The Team's work to make its processes GDPR compliant - we will not include in Phase 1 of its work. The Support Team can consider adding proposed language in the Final Report. Action Item: EPDP Team to review additional ICANN org questions and indicate on the list if any of these need to be addressed in the Final Report On notices to RNH - this is changing specific requirements in the RAA - adds elements that conform to GDPR requirements. Consent provision - language has restrictions on consent based on GDPR Bulk registrations - Temp Spec requires only thin data 2. RDDS Search Capabilities - should the requirements in the Temp Spec be confirmed by the EPDP Team in the Final Report or is this to be further considered in phase 2? 3. Bulk data registration access to ICANN – should the requirements in the Temp Spec be confirmed by the EPDP Team in the Final Report? 4. Process for amendments to Registry – Registrar agreements – should the process in the Temp Spec be confirmed as a policy recommendation, or is this to be addressed during implementation? 5. Does the ‘consent’ provision in the Temporary Specification require confirmation in the Final Report or is this to be addressed during implementation as consent is already defined in the GDPR? 6. Notices to Registered Name Holders Regarding Data Processing - is this required to be addressed in the Final Report or is this part of implementation or in direct consultation with registrars? b. Confirmation of agreement reached or next steps to come to agreement 6. Wrap and confirm next meeting to be scheduled for Tuesday, 5 February 2019 at 14.00 UTC (5 minutes) Confirm action items Confirm questions for ICANN Org, if any

1 0