February 2019 - Gnso-epdp-team

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Tuesday, 05 February 2019
by Andrea Glandon Feb. 6, 2019

Feb. 6, 2019

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 05 February 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/RJ0WBg MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-05feb19… AC Recording: https://participate.icann.org/p4qi1phmdti/<https://participate.icann.org/p4qi1phmdti/?OWASP_CSRFTOKEN=66e09d14dfc66b1f…> <https://participate.icann.org/p9kwfdng74f/?OWASP_CSRFTOKEN=1e3c883343392133…>** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

2 1

Re: [Gnso-epdp-team] Comments on Final Report & Additional Topics- Part 2
by Margie Milam Feb. 6, 2019

Feb. 6, 2019

Hi- Per our discussion today- here are a few additional topics/issues related to the Draft Final Report: * Rec 10 -Log Files – Discussion on whether it can contain PII since it isn’t going to be published or be part of the WHOIS – perhaps the log files details can be discussed in Phase 2? Discussion is needed on the “operational difficulties” mentioned in Rec 10. * Joint Controller Agreement (1204) – the background in this section prior to Rec 13 should be rewritten to eliminate the references to “joint controller” wherever possible and simply reference “controller”…. All the best, Margie From: Margie Milam <margiemilam(a)fb.com> Date: Monday, February 4, 2019 at 6:02 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Comments on Final Report & Additional Topics- Part 1 Hi- Per Marika’s request, here are some language clarifications for your consideration, as well as additional topic submitted on behalf of the BC, and developed in collaboration with the IPC. New Text is in yellow highlight. _________ Rec 1 Purpose 1(b): Subject to the Registry and Registry Terms Conditions and Policies, and ICANN Consensus Policies – please ADD: { and relevant registry agreements and registrar accreditation agreements] Purpose 2: Footnote 6 needs to be moved to be linked to Purpose 2, not Rec 2. Research purpose: The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate research ADD: [ and threat response] carried out by ICANN’s Office of the Chief Technology Officer (OCTO). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org and the expression 426for the need of such data by ICANN Footnote 7/8 should not be a footnote but moved up to the body of the report. These footnotes are substantive recommendations and commitments that should not be buried in a footnote. Rec 7: Replace “ICANN Compliance”with ”ICANN Organization” to be consistent with other recommendations. Delete the quote in Footnote 12 on page 24, since this is inconsistent with Purpose 5. Additional Topics: INFORMATION TO BE PROVIDED TO THE REGISTRANT: Page 16- where there is the quote from the EDPB: It should therefore be made clear, as part of the registration process, that the registrant is free to (1) designate the same person as the registrant (or its representative) as the administrative or technical contact; or (2) provide contact information which does not directly identify the administrative or technical contact person concerned (e.g. admin(a)company.com<mailto:admin@company.com>). For the avoidance of doubt, the EDPB recommends explicitly clarifying this within future updates of the Temporary Specification”. We believe it is important to follow the EDPB’s advice and propose including a recommendation regarding informed consent, in light of the legal advice received, as follows: The EPDP recommends that as part of the registration process, the Registrar shall offer the registered name holder the option to (1) designate the same person as the registrant or its representative as the technical contact; or (2) provide contact information which does not directly identify the technical contact person, but instead uses a generic or role-based email (e.g.admin(a)company.com<mailto:admin@company.com>). OPTIONAL TECH CONTACT DISCUSSION: We do not support making the Tech Contact optional at the registrar level or registry level and believe that more discussion is needed. For example, we have not discussed what happens to existing Tech contacts in the legacy registrations. Shouldn’t there be a similar transitional process to what has been developed for the ORGANIZATION field? In any event, this obligation must be requieeed for the registries since they should receive the tech contact data for those registrants who have provided consent. RECOMMENTATION REGARDING CONSENT Page 19 – Line 549 please delete “as soon as commercially reasonable”. Instead, this recommendation should track the dates for implementation under the transition plan that James and the registrars proposed in Toronto. Rec 4: THICK WHOIS: we do not support the deletion of THICK WHOIS as a consensus policy, and believe that this goes beyond the scope of this EPDP. Rec 8: GLOBAL REDACTION vs. OPTIONAL AT THE REGISTRAR--- We do not agree with global application of the REDACTION, and believe that this recommendation goes well beyond the Temp Spec, which at a minimum allows the registrars/registries to CHOOSE a different application, especially because of differing legal regimes. Our policy needs to be flexible enough to account for laws beyond GDRP, such as the possible US legislation related to WHOIS. Similarly, we do not believe that the redaction should apply to legal persons. We recall James suggesting that we could consider an approach similar to the approach taken for the ORGANIZATION Field, and thus we would like to further explore it in Phase 2. Footnote 15 is a recommendation that should be moved into the body of the Final Report & not be buried in a footnote. Also- it needs to exclude registrations with privacy/proxy services and those for which the registrant has provided consent. PAGE 27: REDACTION OF CITY– we don’t agree with the redaction of CITY and are awaiting legal advice from Ruth on the issue. As a result, it is premature to make a recommendation that it be redacted now. This should be a Phase 2 discussion REC 9: Instead of a “via a process that can be determined by each registrar” we should have concrete steps that can be enforced by ICANN. Could the registrars identify some reasonable steps for this process? ADD: After the implementation phase-in period, the ORG FIELD will no longer be REDACTED by either the registry or registrar. We are still working through the remainder of the Final Report, and will follow up this email with additional comments. All the best, Margie

1 0

Suggested Edits to EPDP Final Report re: Controller, Processor, Joint Controller
by Trang Nguyen Feb. 6, 2019

Feb. 6, 2019

Dear EPDP Team, As changes have been made to Recommendation 13, attached are some suggested edits to the introductory text above Recommendation 13 to align it with the changes. Best, Dan and Trang ICANN Org Liaisons

1 0

Re: [Gnso-epdp-team] [Ext] Re: EPDP Recommendation 11 - email list discussion
by Trang Nguyen Feb. 5, 2019

Feb. 5, 2019

Dear All, Regarding the revised text for recommendation #11 that Alan Woods circulated, the text seems to imply that retained data is only used for enforcement of the TRDP. ICANN org would like to make the EPDP Team aware of other reasons retained data are used, which are reflected in the Description of 2013 RAA Data Retention Specification - Data Elements, Legitimate Purposes for Collection/Retention and Recipients of Data < https://www.icann.org/en/system/files/files/raa-data-retention-elements-10a…>. Best, Dan & Trang ICANN Org Liaisons From: Alan Woods <alan(a)donuts.email> Date: Thursday, January 24, 2019 at 8:50 AM To: Theo Geurts <gtheo(a)xs4all.nl> Cc: Trang Nguyen <trang.nguyen(a)icann.org>, EPDP <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] EPDP Recommendation 11 - email list discussion And of course I meant recommendation 11 not 7 .... sigh! Theo, Completely agree, but I am also thinking of those requirements that may be beyond the GDPR's reach. So I don't think the necessity of a "Waiver" situation is a reality that will go away anytime soon. Alan [Image removed by sender. Donuts Inc.][donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ…> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [Image removed by sender.][facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donut…> [Image removed by sender.] [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&…> [Image removed by sender.] [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_compa…> 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, Jan 24, 2019 at 1:22 PM Theo Geurts <gtheo(a)xs4all.nl<mailto:gtheo@xs4all.nl>> wrote: Thanks Alan, Regarding waivers, I think we need to figure out what their actual use is? Back in the day, the 95/46 directive was implemented differently across Europe, as such a bit messy. But this is no longer the case, the data retention directive has been invalidated and the GDPR has replaced the 95/46 directive. Best, Theo Geurts CIPP/E On 24-1-2019 13:50, Alan Woods wrote: Hey all, To perhaps make my last email a bit more 'actionable' I wish to put a suggestion as to the potential wording of an updated recommendation. NOTE: it's not an easy task, as the point is that we have not yet been armed with adequate data to create a wholly considered retention period that will allow for ICANN to insist upon a retention period, for certain data elements, for a justifiable and reasonable period of time. therefore the recommendation is a bit "hedging our bets" somehow: To be clear, due to speed with which we are moving, this is tabled as to kick off the discussion/drafting. I have not run this by even my teammates in the RYSG and I am under no illusions that this is the 'final' text - merely a suggested path. Recommendation 7 1) The EPDP team recommends that ICANN, as soon as is practicable, undertakes a review of all its active process and procedures so as to identify and document the instances in which personal data is requested from a registrar, outside of the normal retention period of the 'life of the registration'. Identified retention periods, for specific data elements should be then documented and be relied upon to establish, the required relevant and specific, minimum data retention expectations for registrars. this seems to imply that retained data is only used for ICANN compliance purpose, but there may be other purposes for which retained data may be used, such as in cases of law enforcement action, etc. retained pursuant to board’s adopted policy (registrar accreditation policy ) as set forth in document used before to justify data retention. 2) In the interim, the ePDP has recognized that the Transfer Dispute Resolution Policy (“TDRP”) has been identified as one such process. The ePDP team therefore recommends that ICANN should direct registrars to retain only those data elements as deemed necessary for the purposes of the TDRP, for a period of one year following the life of the registration. This retention is grounded on the stated policy stipulation within the TDRP, that claims under the policy may only be raised for a period of 12 months after the alleged breach (FN: see TDRP section 2.2) of the Transfer Policy (FN: see Section 1.15 of TDRP). 3) The ePDP recognizes that Contracted Parties may have needs or requirements for longer retention periods in line with local law or other requirements. The ePDP recommends that nothing in this recommendation, or in separate ICANN mandated policy, should prohibited contracted parties from setting their own limitation periods beyond that which is expected in ICANN policy. Similarly, should local law prevent retention for the period of one year, the ePDP recommends that there are waiver procedures in place that can address such situations. NOTE: the waiver procedure is a pet peeve of mine. It make no legal sense to me that should a single registry / registrar can prove that a law local or otherwise is incompatible with a retention period, that ICANN then continues, having actual notice of an incompatibility, enforces that retention period against every other contracted party who may be similarly subject to that law, until that party makes a separate and full application for a waiver. I appreciate that ICANN cannot possibly assess jurisdiction of applicability of laws for individual CPs, however the process should not be obtuse as to ignore it;s own precedent. I don't know if it is in our power to do so, however perhaps we should also recommend that any successful waiver application process should provide a reasonable period of time whereby other CPs may 'join' themselves to a waiver upon presentation of sufficient proof of being subject to a particular law or requirement that grounded the original application [a fast track waiver process so to speak]. [Image removed by sender. Donuts Inc.][donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ…> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [Image removed by sender.][facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donut…> [Image removed by sender.] [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&…> [Image removed by sender.] [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_compa…> 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 Wed, Jan 23, 2019 at 2:53 PM Theo Geurts <gtheo(a)xs4all.nl<mailto:gtheo@xs4all.nl>> wrote: Thanks, Alan, From my point of view, your observations are all accurate including the registrar ones. And yes you cannot pick a random number for retention. There is a purpose, you balance it, and then you get your period for retention. Your purpose and how you balanced it are part of your documentation to meet the requirement of Art 5.2. Though usually, you cover this process through Art 35. Theo On 23-1-2019 15:38, Alan Woods wrote: Dear all, (noted these are my own musings and my registry colleagues may have additional / different thoughts and comments) 1) Retention period of 1 year Can we be clear that where data is retained for 1 year, and such an extra retention period is stated as being for use under the TDRP, than retained data may ONLY be used for that purpose (See the RYSG comment). Based upon this recommendation, should a Registrar use the retained data for any other purpose, the will be doing so under their own controllership stem (Hence why the clarification in the NOTE is exceptionally important.) To be even clearer, ICANN would NOT be able to use the retained data for any other purpose other than the TDRP under the current recommendation. This is the core of what the EDPB have repeatedly told ICANN, you can't just arbitrarily pick a retention period, the retention period just be reasoned and the use of that data must be grounded to that reason. The EDPB will be equally as upset about setting a retention period based on one process,then using data for something wholly unrelated to that process. Should we persist I see the issue is as follows: ICANN (Compliance or otherwise) does not hold the data themselves, and this data will be requested from the registrar. This disclosure request will state the reason as X purpose; unless the stated purpose is for in furtherance of the TDRP, a registrar should (read MUST) decline to disclose, as the disclosure is incompatible with the stated reason for retention (i.e. the TDRP) Only ICANN, have the knowledge of why they require retention for specific processes and procedures. They must provide the base policy reason as to why they require, in the contract, a retention period. The TDRP is a good single example, but it is one single example and ICANN, should then need it for any other reason, must tell the ePDP what, why and for how long the data is necessary. 2) Retention of additional data elements I would believe the minimal data elements must be retained, and only then related to the specific purpose for the retention. I do not agree with Trang's assessment of the necessity for billing contacts and in particular the interpretation of "requires a registrar to receive a reasonable assurance of payment prior to activating a domain registration." In this instance the proof of assurance should not, considering data protection, rise to the actual provision of actual billing data but would more functionally refer to, in a normal business sense, assurances that the registrar remains solvent and this does not rise to an ICANN expectation that the registrant ultimately pays (that's the registrar's business) ! Re the other elements noted - I would quickly note the following: * Billing contacts - I defer to my registrar colleagues friends here but ICANN does not ever bill registrants. Should a registrar fail and registrations are transferred, then the gaining registrar will need to establish contact again and discern should the registrant wish to continue the relationship with the Registrar. I would opine that this is achieved via registrant contact and a private contract between registrar and registrant. Frankly it has nothing to do with ICANN and is none of their data processing business. * (RAA 3.4.1.5) the name, postal address, e-mail address, and voice telephone number provided by the customer of any privacy service or licensee of any proxy registration service, in each case, offered or made available by Registrar or its Affiliates in connection with each registration. * Full Contact Information for Privacy Proxy Registrations For both the above, again I defer to my registrar colleagues, but again, this data is currently completely remote from ICANN's sphere of influence. The registrant makes a private contract with a P&P provider. Such a contract will have stipulations in the event of a failure of the P&P provider. Use of such providers is at the risk of the registrant, and ICANN cannot interfere here. IF a P&P gets sunk, the registrant will need to deal with their choice and claim relief under their contract etc. - it may be messy but ICANN cannot claim to have a right to this underlying data, as their influence extends to only the data of the registrant (which in this instance will be presented as the P&P holder). ICANN may claim further power via appropriate policy development perhaps but regardless, surely this is a matter for the PPSAI. * Full Contact Information for Registrants who have Consented to Full Display - This is a matter for an assessment of what data is needed for the reason basing the retention. i.e. what data is need currently for performance of the TDRP - nothing else. Again ICANN should identify and justify the data elements necessary for this. The ePDP cannot be expected to do this for ICANN. * (Data Retention Specification 1.1.7.) Types of domain name services purchased for use in connection with the Registration * (Data Retention Specification 1.1.8.) To the extent collected by Registrar, "card on file," current period third party transaction number, or other recurring payment data. * (Data Retention Specification 1.2.1) Information regarding the means and source of payment reasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third party payment processor; * (Data Retention Specification 1.2.2) Log files, billing records and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar operates, other records containing communications source and destination information, including, depending on the method of transmission and without limitation: (1) Source IP address, HTTP headers, (2) the telephone, text, or fax number; and (3) email address, Skype handle, or instant messaging identifier, associated with communications between Registrar and the registrant about the Registration; and * (Data Retention Specification 1.2.3 ) Log files and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar operates, other records associated with the Registration containing dates, times, and time zones of communications and sessions, including initial registration. I'm minded to wholly defer this particular ... issue... to our registrar colleagues. But to the Casual observer none of this data is in ICANN's remit to retain. This is all part of the private contract with the registrant and registrar and ICANN has no legal claim, basis or expectation to this data. If ICANN believes that they have a right to this data, then it is for them to assert it and justify why they need to mandate something as the harvesting and retention to data wholly unrelated to the registration of a domain name. Let us provide a simple example If a registrant doesn't pay the registrar for a domain (declined card or other), ICANN will still likely get paid because that is the contract they have with the CPs; the registry will still get paid as that is the contract with the registrar. Neither registry or registrar may, nor should go after the registrant for such a payment, as we have no right to do so as that is not the intended legal nature of our relationship. Therefore why would ICANN have a right to the information regarding cards on file or client communications? * (RAA 3.4.2.1) the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry Operator(s); * (RAA 3.4.2.2) all written communications constituting registration applications, confirmations, modifications, or terminations and related correspondence with Registered Name Holders, including registration contracts; * (RAA 3.4.2.3) records of the accounts of all Registered Name Holders with Registrar. These are all data that ICANN could possibly mandate. But that being said, this all seems aimed at litigation. These are elements that a Registrar, in its sole controllership as a business, would be crazy not to retain for the purposes of litigation impending or actual etc. Regardless, in truth I can't see how ICANN would EVER have such data disclosed to them unless by court order or equivalent where there is a dispute between Rr and ICANN. I think we need to be clear as to necessity here and IMHO, a lot of these elements are simply overreach. Kind regards, Alan [Image removed by sender. Donuts Inc.][donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ…> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [Image removed by sender.][facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donut…> [Image removed by sender.] [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&…> [Image removed by sender.] [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_compa…> 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 Tue, Jan 22, 2019 at 11:43 PM Trang Nguyen <trang.nguyen(a)icann.org<mailto:trang.nguyen@icann.org>> wrote: Dear All, Regarding data retention, ICANN org has previously identified a question and some areas that we wanted to flag for the EPDP Team, which we sent to the mailing list on 22 December 2018 (https://mm.icann.org/pipermail/gnso-epdp-team/2018-December/001125.html) We are flagging them here again for the EPDP Team’s consideration/discussion as you work to finalize the recommendation. The question/flags are: 1. There are several data elements that are currently required to be retained, but are not addressed in the Initial Report. Should the retention obligation for these data elements remain or be discontinued? 2. If billing and payment-related data is no longer required to be collected, retained, and (with respect to billing contact data) escrowed, this could impact continuity of service to registrants and availability of this data in the event of a payment dispute or related investigation. ICANN org also notes that the ICANN Registrar Accreditation Policy <https://www.icann.org/resources/pages/policy-statement-2012-02-25-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…>> requires a registrar to receive a reasonable assurance of payment prior to activating a domain registration. Data elements currently required to be collected, but are not addressed in the Initial Report include: * Billing/Other Contact ID (where available) * Billing/Other Contact Name (where available) * Billing/Other Contact Street (where available) * Billing/Other Contact City (where available) * Billing/Other Contact State/Province (where available) * Billing/Other Contact Postal Code (where available) * Billing/Other Contact Country (where available) * Billing/Other Contact Email (where available) * Billing/Other Contact Phone (where available) * Billing/Other Contact Fax (where available) * (RAA 3.4.1.5) the name, postal address, e-mail address, and voice telephone number provided by the customer of any privacy service or licensee of any proxy registration service, in each case, offered or made available by Registrar or its Affiliates in connection with each registration. * Full Contact Information for Privacy Proxy Registrations * Full Contact Information for Registrants who have Consented to Full Display * (Data Retention Specification 1.1.7.) Types of domain name services purchased for use in connection with the Registration * (Data Retention Specification 1.1.8.) To the extent collected by Registrar, "card on file," current period third party transaction number, or other recurring payment data. * (Data Retention Specification 1.2.1) Information regarding the means and source of payment reasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third party payment processor; * (Data Retention Specification 1.2.2) Log files, billing records and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar operates, other records containing communications source and destination information, including, depending on the method of transmission and without limitation: (1) Source IP address, HTTP headers, (2) the telephone, text, or fax number; and (3) email address, Skype handle, or instant messaging identifier, associated with communications between Registrar and the registrant about the Registration; and * (Data Retention Specification 1.2.3 ) Log files and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar operates, other records associated with the Registration containing dates, times, and time zones of communications and sessions, including initial registration. * (RAA 3.4.2.1) the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry Operator(s); * (RAA 3.4.2.2) all written communications constituting registration applications, confirmations, modifications, or terminations and related correspondence with Registered Name Holders, including registration contracts; * (RAA 3.4.2.3) records of the accounts of all Registered Name Holders with Registrar. Best, Dan and Trang ICANN Org Liaisons From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Kurt Pritz <kurt(a)kjpritz.com<mailto:kurt@kjpritz.com>> Date: Tuesday, January 22, 2019 at 1:20 PM To: EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [Gnso-epdp-team] EPDP Recommendation 11 - email list discussion Hi Everyone: There were several items (Recommendations) that we agreed to discuss via email with the idea that we could close on them without taking time for discussion in a meeting. This email concerns Recommendation 11, addressing the data retention period. The current recommendation states: The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for a period of one year following the life of the registration. This retention period conforms to the specific statute of limitations within the Transfer Dispute Resolution Policy (“TDRP”). Small Team Discussion (1) The small team noted that “statute of limitation” as used in the Recommendation was probably an inappropriate use of a legal term of art and should be replaced with more appropriate language. This point is addressed in the proposed updated Recommendation below. (2) Some on the small team advocated for a longer retention period, suggesting that a longer retention period could be anchored in existing ICANN policy requirements or other outside requirements. (The current retention period is anchored is the Transfer DRP as the “tall pole” among all the other purposes for processing registration data.) The updated language below, proposed by small team B, clarifies that the proposed data retention period is for ICANN related requirements and different retention periods may apply as a result of local requirements or circumstances. Proposed updated language recommendation 11 – data retention The EPDP Team recommends that: Registrars are required to retain the herein-specified data elements for ICANN-related requirements for a period of one year following the life of registration. This minimum retention period is consistent the requirements of the Transfer Dispute Resolution Procedure, which has the longest retention requirement of any of the enumerated Purposes for Processing Registration Data. Note, Contracted Parties may have needs or requirements for longer retention periods in line with local law or other requirements. This is not prohibited by this language. Similarly, should local law prevent retention for the period of one year, there are waiver procedures in place that can address such situations. Actions Those supporting a retention greater than one year generally should submit rationale for such a retention period including related ICANN policy requirements to which this could be anchored. These submissions will be discussed via email. Submit comments for support for the amended Recommendation or requesting edits to the recommendation with rationale. Deadline: Friday, 24 January, additional email discussion might follow depending on responses. Thank you and best regards, Kurt _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

3 3

Proposed Agenda - EPDP Team Meeting #43
by Marika Konings Feb. 5, 2019

Feb. 5, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for tomorrow (Wednesday 6 February) at 14.00 UTC. Best regards, Caitlin, Berry and Marika ----------------------- EPDP Meeting #43 Agenda Wednesday, 6 February 2019 1. Roll Call & SOI Updates (5 minutes) 1. Welcome and Updates from EPDP Team Chair (5 minutes) * Review of outstanding action items * Other updates, if applicable 1. Recommendation #5 – Transmission of Registration data from Registrar to Registry (30 minutes) * RySG to present updated language proposal * Discuss proposal * Confirmation of agreement reached or next steps to come to agreement 1. ICANN Org Questions (30 minutes) * 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. Recommendation #12 – Reasonable Access (30 minutes) * Review revised proposal * Discuss revised proposal * Confirmation of agreement reached or next steps to come to agreement 1. Review of additional topics raised (if time allows) 1. Wrap and confirm next meeting to be scheduled for Thursday, 7 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

Notes and action items EPDP Team Meeting #42
by Marika Konings Feb. 5, 2019

Feb. 5, 2019

Dear EPDP Team, Please find below the notes and action items of today’s EPDP Team meetings. You are encouraged to take particular note of the different action items. For your information, attached you will find the proposed updated timeline that was shared during the meeting. Best regards, Caitlin, Berry and Marika =============== EPDP Team Meeting #42 Tuesday, 5 February 2019 Notes and Action Items High-level Notes/Actions: Action item #1: Extension of deadline for the EPDP Team to flag issues for further consideration following the review of the latest version of the Final Report: Tuesday 5 February COB. Action item #2: CPs to share within max. 24-48 hours the proposed approach in relation to implementation bridge options Action item #3: Leadership team to consider adding paragraph to Final Report in relation to the overarching requirements of GDPR compliance in relation to personal information and the definition of personal data as information that could lead to the discovery of personal data. Action item #4: Kristina Rosette to provide suggested edits to the reasonable access recommendation to ensure consistency in terminology and provide necessary clarifications to facilitate implementation work Action item #5: Staff to make note in the Final Report that ARS is considered covered as part of purpose 5 (ICANN Compliance) and related updates that have been made in the purpose 5 data elements workbooks. Action item #6: EPDP Team to review additional ICANN Org questions and indicate as soon as possible on the email list and suggest if any of these need to be addressed in the Final Report. Questions for ICANN Org from the EPDP Team: None Notes & Action items These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ . Proposed Agenda: 1. Roll Call & SOI Updates * Attendance will be taken from Adobe Connect * Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. * Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) a) Reminder: process for Final Report input & Consensus Call * See https://community.icann.org/x/VZwWBg * See email sent by Keith Drazek, GNSO Chair, concerning some limited flexibility in the timeline to make the report as complete as possible and provide some quiet time for people to review the final report. * See updated timeline shared during the meeting which factors in the additional time that is available per the letter from Goran Marby. (see also attached) * This provides for a 5-day quiet period to allow EPDP Team members to flag any issues that were overlooked, are inconsistent or in error and review consensus designations (note, this is not an opportunity to reopen previously closed issues or question previously reached agreements). * Appreciate all the input provided on the mailing list. Hope to be able to close of some of these discussions on the mailing list, although some may require further consideration. * Consensus call - purposes alone is not sufficient to look at for consensus as there are other recommendations that are linked to it. It does look like there is agreement on those other recommendations linked to purposes, so that may address some of the concerns. Note that this is an iterative process and as such, conditions can be attached to it, and there will be an opportunity at the end to see the whole package and flag any issues / concerns at that stage. * Objective of additional meeting is to finalize outstanding issues. * Reminder, please send any substantive issues that require further consideration to the mailing list. Any minor edits / updates should be added to the google doc: https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnL…. Action item #1: Extension of deadline for the EPDP Team to flag issues for further consideration following the review of the latest version of the Final Report: Tuesday 5 February COB. b) Review of outstanding action items c) Other updates, if applicable 3. 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” a) CPs to present proposal b) Discuss proposal c) Confirmation of agreement reached or next steps to come to agreement * Some additional conversations have taken place. Circle back to some of the proposals that have been flagged previously. What would be enforced by compliance at the moment of the expiration of the Temporary Specification. Still have not achieved 100% sign off from CPs - hope to present something back to the group shortly. Will need some time for the group to be able to consider this proposal before the quiet period starts. * Letter from Goran - two extra weeks are conditional on Final Report including policy recommendations on the bridging mechanism. Action item #2: CPs to share within max. 24-48 hours the proposed approach in relation to implementation bridge options 4. Data Elements Workbooks Small Team Update a) Update on status of work b) Questions / clarifications c) Expected next steps * See latest version here: https://community.icann.org/display/EOTSFGRD/e.+Data+Elements+Workbooks * DE small team is deep diving into the data elements workbooks to ensure that these are consistent with the EPDP Team recommendations and are accurate. * Updates to the overall data matrix may also be necessary (see latest consolidated data elements table here: https://community.icann.org/download/attachments/96207076/Data%20Elements%2… * Minimum data set is to be viewed per purpose. * In the introduction section of Annex D, small team created definitions for each of the primary processing activities. You will also find a new legend that attempts to more precisely define Required vs. Optional, etc. as this specificity is needed to be precise. * See also split between 1A and 1B, per the input that has been provided previously by RySG. Certain registries may not need certain data elements, while others do. * Next small team is meeting later today. Aim is to conclude Purposes 4 - 6 plus some additional to-dos. Aim is to have finalized workbooks to the plenary by Thursday. * To follow this work, please see relevant wiki page: https://community.icann.org/x/5AC8BQ. Note that call recordings and notes are also available and distributed to the EPDP Team. 5. Items flagged for further discussion a) Privacy / Proxy registrations – see mailing list proposal and discussion * Two variations of the recommendation have been shared on the mailing list * P/P registration is not personal information, so should be published? * Original intent of Temp Spec was pragmatic one - to avoid a situation whereby P/P information was behind the gate and that any reasonable access request would just result in the disclosure of P/P information which would mean another request would need to be made which would cause significant delays. * Pseudonymized email could be considered personal information, but not any of the other information in relation to the P/P service. * Need to clear about the risk profile we are creating for registrar - pseudonymized data is not anonymous, still risk associated with it. * Is this already settled by PPSAI? Not necessarily for this group to address. * There are already reasonable disclosure procedures available to reveal this information. * Is concern only about the email address? If so, should recommendation include MUST include the public WHOIS and return in response to query full WHOIS data, apart from the pseudonymized email for which it would be MAY? * Need to be careful to not restrain market innovation and different ways in which businesses are running their businesses. How to at least get non-personal data shared? Require that the services identify themselves and provide a mechanism for legitimate and lawful requests for underlying data. 2013 RAA already requires this. * Not asking for change in the nature of P/P services or registrant data, just the data associated with the P/P or an indication it is a P/P registration. * May need to consider the difference between P/P services. * Possible compromise language: Registrars must publish the non-personal data associated with P/P registration? * Is email communication already addressed in recommendation #10? Is there some obligation on the registrar to provide conduit? * Consider restricting it to affiliated p/p services. * Proposed updated language (no objections noted): In the case of a domain name registration where an "affiliated" privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar (and Registry where applicable) MUST include in the public RDDS and return in response to any query full non-personal RDDS data of the privacy/proxy service, which MAY also include the existing privacy/proxy pseudonymized email. *include footnote with reference to definition of "affiliated" as per the RAA. Action item #3: Leadership team to consider adding paragraph to Final Report in relation to the overarching requirements of GDPR compliance in relation to personal information and the definition of personal data as information that could lead to the discovery of personal data. b) Reasonable access * See latest version shared during the meeting which reflects original language plus edits suggested by Alex Deacon on the mailing list * Wonder if this would work from an implementation perspective: "a timeline for processing and responding to the disclosure requests in alignment with the Art. 12 GDPR timeframe for providing information to the data subject." * How does this link to purposes? Should a purpose need to be identified in the request? Consider adding a reference in second bullet under Reasonable Disclosure Requests to purposes. * Art. 12. 3 The controller shall provide information on action taken on a request under Articles 15 to 22 to the data subject without undue delay and in any event within one month of receipt of the request. That period may be extended by two further months where necessary, taking into account the complexity and number of the requests. In CPs experience, 30 days is an acceptable base timeframe. Sometimes we need longer in which case we would communicate with the requestor, which is also in line with the Art.12 requirement. * Also need to review intro paragraph – are these recommendations still in line with what the temp spec originally recommended? Action item #4: Kristina Rosette to provide suggested edits to the reasonable access recommendation to ensure consistency in terminology and provide necessary clarifications to facilitate implementation work c) Additional Purposes * See latest version circulated by Ayden to the mailing list * Aims to address the input received to date on this topic * Cannot speculate on future uses and give a blanket permission – need to do proper analysis and ensure GDPR compliance * Clarify in report that updates made to workbooks to clarify that ARS is dealt with in Compliance purpose * Explanatory language aims to explain the context of the recommendation. * See also proposed edit by the BC to add ‘threat response’ to the recommendation so that it would read: “The EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate research ADD: [ and threat response] carried out by ICANN’s Office of the Chief Technology Officer…… Thread response is different work – should it be made more general? Instead of referring to research, maybe refer to ‘facilitate the mission carried out by OCTO’? See https://www.icann.org/octo. Make change to refer to carrying out mission of OCTO (see https://www.icann.org/octo) * This would be an ICANN purpose – ICANN need to deal with this if it would to establish this purpose as it is a controller. * No objections noted to the language as modified by Ayden, with a reference to the OCTO mission (as noted above) Action item #5: Staff to make note in the Final Report that ARS is considered covered as part of purpose 5 (ICANN Compliance) and related updates that have been made in the purpose 5 data elements workbooks. 6. 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 a) Consider topics flagged b) Discuss proposed approach (‘what happens if these topics are not addressed / covered in the Final Report?’) c) Confirmation of agreement reached or next steps to come to agreement Action item #6: EPDP Team to review additional ICANN Org questions and indicate as soon as possible on the email list and suggest if any of these need to be addressed in the Final Report. 7. Wrap and confirm next meeting to be scheduled for Wednesday, 6 February 2019 at 14.00 UTC (5 minutes) a) Confirm action items b) Confirm questions for ICANN Org, if any * Tomorrow's meeting may be shorter due to conflicts that some groups may have. This meeting is in addition to Thursday's meeting. * Additional meeting scheduled for Monday 11 February, instead of Tuesday's meeting to allow any finetuning of the report before submission to the GNSO Council (deadline for submission of motions and documents for the Council meeting is Monday 11 February) 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

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Wednesday, 06 February 2019 at 14:00 UTC for 1.5 hours
by Andrea Glandon Feb. 5, 2019

Feb. 5, 2019

**Additional call for this week on Wednesday** 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/gYA2Bg Thank you. Kind Regards, Andrea

1 0

Recommendation 5 - Questions and Proposed Edits (Joint RySG-RrSG)
by Rosette, Kristina Feb. 5, 2019

Feb. 5, 2019

Dear EPDP Team Members, The Registries and Registrars have several questions and concerns regarding the proposed text and edits to Recommendation 5. Both the genesis of the edits and language of Recommendation 5 are unclear. As it stands the language and intent of the Recommendation are ambiguous and could have unintended impacts on the interpretation and application of Purposes 1a and 1b, which are foundational to the EPDP’s outcomes. Overall, the questions are- 1) what is the desired outcome of this Recommendation, 2) how does the Recommendation text reflect the Proposed Report language, 3) is this Recommendation redundant of Recommendation 22? Attached are a redline of our proposed changes. Specifically, the RySG and RrSG note that: ● It’s unclear where the extensive redline of Proposed Final Report language in the “Charter Question c) Transfer of data from registrar to registry” originated. Are they sourced from comments to the Initial Report? ● The Report Language also appears to be much broader and somewhat at odds with the actual text of the Recommendation at the end of the document. ● The EPDP is currently defining the minimum data set. The impacts of that data set on existing policies will be determined during the implementation phase per the group’s existing Recommendation 22 requiring review and update of existing policies and processes. Singling out and recommending direct amendment of the Thick WHOIS policy is redundant as a separate recommendation (though again, the Recommendation language is far more targeted than the “Proposed Final Report Language”). Why we would treat analysis and review of the Thick WHOIS policy differently than other policy review under Recommendation 22 is unclear. We recommend removing references to the Thick WHOIS policy from the language accompanying Recommendation 5. ● This text, “The recent discussion also highlighted that some registries wish to not receive data for which they have no GDPR-compliant purpose for processing.” highlights an issue we believe to be separate from the concept of a minimum data set. If the goal of this EPDP is to establish GDPR compliant purposes for processing and we find that our work is not able to resolve possible differences in application due to existing policies or practices that are outside of the EPDP remit, we clearly flag those issues for follow up in previously mentioned Recommendation to review existing policies and practices. The apparent “out” created by this language, allowing ROs to choose not to receive the full minimum data set was originally discussed as an option for those ROs that will encounter issues with their jurisdictional requirements, not as a way to deal with the “thick/thin” issue or policy. ● Finally, if the language in Recommendation 5 remains broad and could have unintended impacts on Purpose 1a/b. Currently, 1a/b define the roles, responsibilities, and data elements associated with the core function of effecting a domain name registration and establishing the rights of the registrant in that name. It also identifies the Controller/Processor role of the RO. If Purpose 1a/b defines the transfer of the defined minimum data set as a requirement, a choice made by the RO under Rec 5 could change the role of that RO. This creates an inconsistent application of the Recommendations and Purposes of the EPDP. As the EPDP is meant to establish a minimum baseline for CPs Recommendation 5 as written could impact that. Please let us know if you have any questions. Kristina Rosette Senior Corporate Counsel, IP - Domains rosettek(a)amazon.com<mailto:rosettek@amazon.com> | 703.407.1354

1 0

Proposed Revised "Registration Data" Definition
by Rosette, Kristina Feb. 5, 2019

Feb. 5, 2019

All, With apologies for the delay, I'm following up on a point I previously raised, namely, revising the definition of "registration data". The Temp Spec contains this definition: "Registration Data" means data collected from a natural and legal person in connection with a domain name registration." The "in connection with" language is so broad and vague that it could be interpreted to data that registrars and registries would not consider to be registration data such as billing data, account creation data, and the like. RySG proposes to revise the definition to reference the relevant data elements: "Registration Data" means the data elements identified in Annex [X], collected from a natural and legal person in connection with a domain name registration." (Annex [X] would then identify the relevant data elements, as carried over from the whatever becomes the final version of Recommendation 4). Additional text is in bold and italics. RrSG supports this proposed revised definition. Happy to answer any questions. Many thanks. K Kristina Rosette Senior Corporate Counsel, IP - Domains rosettek(a)amazon.com<mailto:rosettek@amazon.com> | 703.407.1354

1 0

Fwd: [council] Letter from Marby Re: Timing of the Final Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data.
by Rafik Dammak Feb. 5, 2019

Feb. 5, 2019

hi all, please find attached a letter from Goran sent to GNSO council. Best, Rafik ---------- Forwarded message --------- From: Drazek, Keith via council <council(a)gnso.icann.org> Date: mar. 5 févr. 2019 à 23:00 Subject: [council] Letter from Marby Re: Timing of the Final Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data. To: council(a)gnso.icann.org <council(a)gnso.icann.org> Cc: gnso-secs(a)icann.org <gnso-secs(a)icann.org>, kurt(a)kjpritz.com < kurt(a)kjpritz.com> Hi all, Last Tuesday, the GNSO Council Leadership and EPDP Leadership held a joint call to discuss timing and progress of the EPDP WG and planning for Council consideration and our vote on the Final Report. Following that call, I requested feedback from ICANN on the timing required for public comment and Board consideration, with an eye toward finding some extra time for the WG if needed. Attached is the response from Goran, which provides the potential for an additional 2 weeks for the EPDP to finalize its work, assess levels of consensus, and ensure the SG/Cs and other groups can consider a stable document before the Final Report is delivered to the Council for action. I have communicated this to Kurt (copied here) and I believe he will discuss this with the EPDP WG during today’s plenary call. If all goes according to plan, the GNSO Council will have two opportunities to vote – first, during our 21 February regular meeting, or during a 4 March special meeting, if needed. Please let me know if you have any questions. Thanks and regards, Keith Begin forwarded message: *From:* Goran Marby <goran.marby(a)icann.org> *Date:* February 4, 2019 at 10:54:31 AM EST *To:* "kdrazek(a)verisign.com" <kdrazek(a)verisign.com> *Cc:* Cassia Oliveira <cassia.oliveira(a)icann.org> *Subject:* *[EXTERNAL] Letter from Marby Re: Timing of the Final Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data.* Cassia Oliveira on behalf of Goran Marby Dear Mr. Drazek, Attached please find letter from Mr. Marby Re: Timing of the Final Report of the Expedited Policy Development Process (EPDP) on the Temporary Specification for gTLD Registration Data. Thank you. Sincerely, Göran Marby President & CEO ICANN +1(310) 578 8690 Cássia Oliveira Sr. Manager, Office of the President & CEO cassia.oliveira(a)icann.org +1(310) 578 8656 _______________________________________________ council mailing list council(a)gnso.icann.org https://mm.icann.org/mailman/listinfo/council

1 0

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. 5, 2019

Feb. 5, 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. 5, 2019

Feb. 5, 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. 5, 2019

Feb. 5, 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. 5, 2019

Feb. 5, 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. 5, 2019

Feb. 5, 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

Responses to legal questions
by Kurt Pritz Feb. 1, 2019

Feb. 1, 2019

Dear EPDP Team: I am writing to notify you that outside legal counsel has responded to three questions from the EPDP Legal Team. The Legal Team has reviewed the responses. Rather than include a Legal Team opinion regarding the effect of the responses on our discussion, the Team decided to simply provide the answers (in summary form and in formal memo) that Bird&Bird provided to us. Below, please find the: EPDP Team questions posed to Bird&Bird, and Informal summary of the answers provided by Bird& Bird. The full legal memoranda can be found on the wiki page. <https://community.icann.org/display/EOTSFGRD/Meetings+Legal+Committee+Frame…> (https://community.icann.org/display/EOTSFGRD/Meetings+Legal+Committee+Frame…) Please respond with questions you might have to this list. Best regards, Kurt Legal vs. Natural Q: The EPDP Team discussed Charter Question h3, namely, should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status? In determining the answer to this question, the EPDP Team sought the guidance of external legal counsel, inquiring specifically, “If a registrar permits a registrant, at the time of domain name registration, to self-identify as a natural or legal person, does a registrant’s incorrect self-identification that results in the public display of personal data create liability under GDPR? If so, please advise, for each possible participant in the domain name registration process listed below, if that participant incurs liability.” External legal counsel provided the following summary answer. A: “We conclude that the relevant parties could be subject to liability if a registrant wrongly self-identifies as a legal person (and not a natural person) and the registrant's data is disclosed in reliance on this self-identification. To reduce the risks, we propose several solutions, such as focus group testing of the registration process to minimise the risk of errors and technical tools (if feasible) to verify the information provided. We also recommend providing clear notice to data subjects of the consequences for them of the designation as either a legal or a natural person as well as a way for data subjects to easily correct a mistaken classification. One way to do this effectively would be to send a follow-up email after registration to the listed contacts – this could also help with the notice issue addressed in question 1 [Technical Contact]. Technical Contact Q: The EPDP Team also took note of a related footnote [from the EDPB] which states, “[if contact details for persons other than the RNH are provided] it should be ensured that the individual concerned is informed”. The EPDP Team discussed whether this note implies that it is sufficient for the Registered Name Holder (RNH) to inform the individual it has designated as the technical contact, or whether the registrar may have the additional legal obligations to obtain consent. The EPDP Team requested external legal counsel guidance on this topic who provided the following summary answer: A: “In cases where the RNH and the technical contact are not the same person, relying on the RNH to provide notice on the registrar's behalf will not meet GDPR's notice requirements if the RNH fails to provide the notice. While this may provide grounds for a contractual claim against the RNH, it is unlikely to provide a viable defence under the GDPR. Moreover, this arrangement will make it difficult for registrars to demonstrate that notice has been provided. If notice is not effectively provided, this could affect the legitimate interests analysis, since technical contacts may not "reasonably expect" the manner in which their data will be processed. If relying on consent, such an arrangement would make it difficult to document that consent has been provided” . Article 6(1)(b) Q: The EPDP Team asked two questions about the application of Article 6(1)b to external legal counsel: Does the reference 'to which the data subject is party' limit the use of this lawful basis only to those entities that have a direct contractual relationship with the Registered Name Holder? Does "necessary for the performance of a contract" relate solely to the registration and activation of a domain, or, alternatively, could related activities such as fighting DNS abuse also be considered necessary for the performance of a contract? External legal counsel provided the following summary answers: A: “a) it is not clear if the contractual necessity condition can only apply where there is a contract between data controller and data subject, or whether the contract could be between another person and the data subject. (For example, so that ICANN or a registry could argue that their processing is necessary for the contract between the registrar and the RNH/data subject). In countries where we have checked, there are no cases on point. Some data protection authorities interpret the provision narrowly. However, there is also guidance arguing for a more liberal approach. We think a more liberal approach is correct – but this is untested. b) What is 'necessary' is interpreted strictly. We do not think that the EPDP could successfully argue that preventing DNS abuses is 'necessary' for the contract with the RNH. There is guidance from the Article 29 Working Party on this which has examples somewhat similar to ICANN's situation”.

1 0

Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10
by Alan Greenberg Feb. 1, 2019

Feb. 1, 2019

Milton, you say that "Compliance can check the full Whois record". That is certainly not the case now, nor is it assured that it will be the case going forward. Right now they must ask for specific fields and Purpose 5 says "If a contractual compliance complaint is filed, the complainant provides certain information regarding the issue, which may contain personal data. Depending on the nature of the issue, ICANN Compliance may ask the Registrar or Registry Operator for the minimum data needed to investigate the complaint. Compliance may also look at the public WHOIS to supplement its review or processing." If we follow that, then Compliance must depend on the good faith of the registrar and that is problematic. Are you prepared to alter Purpose 5 to make it clear that Compliance has unfettered access to the actual entire WHOIS record? Alan At 01/02/2019 11:36 AM, Mueller, Milton L wrote: Maybe I do not understand what you are saying, AlanG, but your statement below seems mistaken. Party X sends some kind of a request which is supposed to be relayed to a RNH. The registrar forwards it and assign it a number, as AlanW suggests below. Party X gets no response and becomes concerned. They ask ICANN compliance to look into the accuracy of the Whois record. Compliance can check the full Whois record. Further, the concern about “requests not being relayed” is very different from “requests being relayed to a non-viable contact address.” The former is a registrar failure (and I am not sure WHY exactly a registrar would fail to forward a request), the latter is an accuracy problem for which the RNH is responsible. Seems to me these more complicated procedures for tracking email delivery and responses are simply a way for certain private parties to offload the costs of their monitoring and enforcement activities onto Registrars (and indirectly, RNHs). We oppose that. --MM From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Friday, February 1, 2019 10:10 AM To: Alan Woods <alan(a)donuts.email>; Greg Aaron <greg(a)illumintel.com> Cc: GNSO EPDP <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10 Alan, "Should ICANN compliance wish to test the fidelity of the system, that is in their purview to do so to ensure the mechanics of the system." does not give compliance the ability to address complaints that messages are seemingly not being relayed (or are being relayed to a non-viable contact address). Alan At 01/02/2019 05:34 AM, Alan Woods wrote: Thank you Greg and our SSAC colleagues for this, However, with my privacy lawyer hat on, can we actually remind ourselves here of the goal. The Goal here is to simply confirm that the registrar has relayed the requestors communication. The suggestion from our SSAC colleagues, has the Registrar, not only maintaining this log, but creating a database of requestor data, email addresses, metadata, and, for good measure, a positive obligation to further monitor responses from those emails sent, so as to initiate an action which may result in a suspension of a domain name. Outside of the fact that a system of this size is likely complex and cost prohibitive to smaller registrars, it ignores necessity and data minimization and alas fails the privacy by default and privacy by design tests. I'm sure that the very clever folks at the registrars can come up with a much simpler and functional system along the lines of: A communication request received is assigned a number e.g. #X The number is provided to the requester (for their own reference) but the registrars have no need to maintain a record of which requester is assigned which number, just that request #X is made, and the system has confirmed its relay of the message associated with #X. Should ICANN compliance wish to test the fidelity of the system, that is in their purview to do so to ensure the mechanics of the system. None of the other data or actions are remotely necessary. I would also suggest that we give the registrars a bone here and state that nothing in our recommendation language should prevent the registrar from taking appropriate actions to prevent excessive use or abuse of the registrant contact process. Now to display how number 4 may be achieved, but also noting that this is not within ICANN's controllership and therefore outside of the ICANN policy reach: 4a. A Registrar may, at their own discretion, keeps a sufficiently anonymized log of requests (whereby the system pseudonymizes of somehow anonymizes personal data of the requester but is capable of logging where requestor (let's call him Y) has made 30000 requests #X ,#Z etc. This can then be used to perhaps filter such future requests from that requestor. To confirm this would be solely at the option of the regsitrar, abased on their own needs, size, resources etc. The registrar would be controller here, and ICANN base policy cannot dictate this. This would indeed be a prudent step for a larger registrar to prevent abuse of the relay system, and to avoid allegation that they are 'spamming' their registrants. To that end. I think Sarah's' proposed wording with Kristina's addition (and perhaps the clarification contained in 4 above) is still wholly sufficient for the goal and purpose pursued. Kind regards, Alan Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <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, Jan 31, 2019 at 11:25 PM Greg Aaron <greg(a)illumintel.com<mailto:greg@illumintel.com>> wrote: The SSAC team proposes a revised version of #2. A goal is to make measurement and compliance activity around this contractual requirement possible. The Temp Spec doesn't offer that, and the existing proposals don't yet either. The RrSG proposal says that no personal data about the activity will retained, and log format or content are not specified. If so, how will a registrar demonstrate that a message from any requestor was sent to the registrant? The below makes clear that the records about forwarding are for examination by ICANN Compliance (only). If someone who originated a message is concerned, they can make a complaint to ICANN. That is the same model that we have now for invalid WHOIS and abuse reporting complaints. We also assume that such records will be retained for only an appropriate term. Part of the recommendation below is based on an existing procedure in the RAA. so it is familiar. It creates no new personal data transfer, and there is already a â��Pâ��urpose defined for cor contracted parties to send personal data to Compliance. It does not require the registrar to keep the entire email message if they do not want to. Proposed text: "2) The EPDP Team recommends that Registrars must maintain records that demonstrate that the communication from the requestor was relayed by email to the Registered Name Holder. This information must include the requestor's identity as it was provided to the Registrar, the Registered Name Holder's email address, and a timestamp. Such records will be available to ICANN for compliance purposes, upon request. If Registrar receives a bounced email notification or non-delivery notification message, the Registrar must initiate re-verification of the registrant's contact data per the RAA's WHOIS Accuracy Program Specification, paragraph 4." From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Friday, January 25, 2019 4:14 PM To: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] RrSG Comment on Recommendation 10 Hello All, For Recommendation 10, the RrSG has the following proposed new text: 1) In relation to facilitating email communication between third parties and the Registered Name Holder, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. 2) The EPDP Team recommends Registrars MUST maintain Log Files, which shall not contain any Personal Information, and which shall contain confirmation that a relay of the communication between the requestor and the Registered Name Holder has occurred, not including the origin, recipient, or content of the message. The registrar cannot be reasonably expected to confirm, or attempt to confirm by any means, the receipt of any such relayed communication. 3) DELETE 3 -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

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

Feb. 1, 2019

Alan, it is correct that the contents of a reply could contain identifiable information then the same is true for a web form. Are you saying that therefore there is NO possible way to allow contact? At some point, registrants need to take responsibility for what they do. Alan At 01/02/2019 07:46 AM, Alan Woods 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 which have unddergone 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 Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <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 Fri, Feb 1, 2019 at 12:57 AM Alex Deacon < alex(a)colevalleyconsulting.com<mailto:alex@colevalleyconsulting.com>> wrote: 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<mailto:alex@colevalleyconsulting.com> +1.415.488.6009 _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@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

1 0

RrSG Comment on Recommendation 10
by Sarah Wyld Feb. 1, 2019

Feb. 1, 2019

Hello All, For Recommendation 10, the RrSG has the following proposed new text: 1) In relation to facilitating email communication between third parties and the Registered Name Holder, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. 2) The EPDP Team recommends Registrars MUST maintain Log Files, which shall not contain any Personal Information, and which shall contain confirmation that a relay of the communication between the requestor and the Registered Name Holder has occurred, not including the origin, recipient, or content of the message. The registrar cannot be reasonably expected to confirm, or attempt to confirm by any means, the receipt of any such relayed communication. 3) DELETE 3 -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392

3 2

Revised Recommendations for (Final) Review
by Kurt Pritz Feb. 1, 2019

Feb. 1, 2019

Hello Everyone: Thanks again for your perseverance. And - thank you in advance for your spirit of cooperation and compromise in considering the attached. We have spent the last few days reviewing the transcripts and other records of our recent discussions and then amending the Final Report Recommendations - taking into account the Initial Report Recommendations, the small team work, the conclusions in Toronto and these last several meetings. The Recommendations included here are: Recommendation 5 - Data elements to be transferred from Registrars to Registries Recommendation 10 - Email communication Recommendation 12 - Reasonable Access Recommendation 14 - Responsible Parties [Not included are Rec. 13 (sent earlier) and Rec. 11 and the Research Purpose (to be sent tomorrow.] Each of these documents has a brief forward containing a description of the pertinent discussion and an explanation for choosing the wording in the Recommendations. They each then contain the Recommendation as originally written and a redline of the proposed recommendation based on the most recent discussions. Please read the entire documents (they are not long), and not just the recommendation itself. I am certainly not asking for you to stand silently by if you disagree with these Recommendations because they would negatively impact GDPR compliance. I am asking that you study the balancing that went into this and be ready to accept wording in cases where it does not match your own choice. Please review with your groups and return to us by Monday so that we can put any of these on the Tues/Wed/Thur agendas. Sincerely, Kurt

1 0