Re: [Gnso-epdp-team] [Ext] Re: EPDP Recommendation 11 - email list discussion
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-10aug15-en.pdf>. Best, Dan & Trang ICANN Org Liaisons From: Alan Woods <alan@donuts.email> Date: Thursday, January 24, 2019 at 8:50 AM To: Theo Geurts <gtheo@xs4all.nl> Cc: Trang Nguyen <trang.nguyen@icann.org>, EPDP <gnso-epdp-team@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&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=> 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_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> [Image removed by sender.] [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> [Image removed by sender.] [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Jan 24, 2019 at 1:22 PM Theo Geurts <gtheo@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&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=> 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_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> [Image removed by sender.] [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> [Image removed by sender.] [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Wed, Jan 23, 2019 at 2:53 PM Theo Geurts <gtheo@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&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=> 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_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> [Image removed by sender.] [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> [Image removed by sender.] [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Tue, Jan 22, 2019 at 11:43 PM Trang Nguyen <trang.nguyen@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_resources_pages_policy-2Dstatement-2D2012-2D02-2D25-2Den&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=gSciXDCLwToip-KVqvqL5A4Yuch4VO2F0ALwpUeM0i8&e=>> 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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Kurt Pritz <kurt@kjpritz.com<mailto:kurt@kjpritz.com>> Date: Tuesday, January 22, 2019 at 1:20 PM To: EPDP <gnso-epdp-team@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@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Hello All, Thank you Trang for bringing up the 2013 RAA Data Retention Specification. We need to identify the purpose and legal basis for every instance of data retention; being included in the 2013 RAA Data Retention Specification is not sufficient -- instead, each instance of retaining data needs to be grounded in an EPDP Purpose. Looking at the PDF you linked to, I notice that most of the retained elements show a purpose of registrar's internal use and billing issues. These are not purposes defined by the EPDP; if the data is retained for these reasons it would be under the Controller's own controllership and not due to an external requirement. For other data elements there are a couple other purposes listed in the PDF, but the only specific policy mentioned there is the TDRP, otherwise it's all quite general and thus insufficient to be counted as a purpose with a legal basis. I suggest we still need to leave the recommendation as Alan W suggested, asking ICANN to undertake a review of all processes that request data from a registrar, to identify the full spectrum of data retention requirements and align them with ICANN Purposes coming out of the EPDP work. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 1/28/2019 8:50 PM, Trang Nguyen wrote:
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-10aug15-en.pdf>.
Best,
Dan & Trang
ICANN Org Liaisons
*From: *Alan Woods <alan@donuts.email> *Date: *Thursday, January 24, 2019 at 8:50 AM *To: *Theo Geurts <gtheo@xs4all.nl> *Cc: *Trang Nguyen <trang.nguyen@icann.org>, EPDP <gnso-epdp-team@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&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=>
*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_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> Image removed by sender. [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> Image removed by sender. [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Thu, Jan 24, 2019 at 1:22 PM Theo Geurts <gtheo@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&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=>
*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_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> Image removed by sender. [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> Image removed by sender. [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Wed, Jan 23, 2019 at 2:53 PM Theo Geurts <gtheo@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) R*etention 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&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=>
*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_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> Image removed by sender. [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> Image removed by sender. [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Tue, Jan 22, 2019 at 11:43 PM Trang Nguyen <trang.nguyen@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_resources_pages_policy-2Dstatement-2D2012-2D02-2D25-2Den&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=gSciXDCLwToip-KVqvqL5A4Yuch4VO2F0ALwpUeM0i8&e=>> 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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Kurt Pritz <kurt@kjpritz.com<mailto:kurt@kjpritz.com>> *Date: *Tuesday, January 22, 2019 at 1:20 PM *To: *EPDP <gnso-epdp-team@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@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Dear all, I am in full agreement with Sarah on this. .@Trang I do think that merely referring 2013 RAA Data Retention Specification as, as noted by Sarah, does not provide the required review, detail, necessity as to Why ICANN requires, in it's base policy, it to be 'retained'. Just from a cursory review, it does appear that the document referenced does not make out a case in any of the noted elements for ICANN's need for retention, except for those matters that refer to transfers as 'example', and as such this is already covered by the TDRP and the 1 year period already defined and linked to the TDRP : *1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.7, 1.1.8, 1.2.1* : the 'legitimate purpose' is referred to as *'registrar's internal use'* etc - ICANN cannot mandate this, as these elements are, as per the document a registrar internal matter. *1.1.6 -* This seems like it's a TDRP matter. Also I must note that the description of a 'for some period' as the retention period is far too anomalous and does not bode well for the though and specificity vis á vis Data protection. I'm unsure, nor is it apparent if the list of data noted here are actually required however by the TDRP - seems more like a kitchen sink approach, rather than a considered list of necessary elements. *1.2.2 , 1.2.3 - *Again the maintenance of such records are outside of ICANN's reach. Fraud prevention and billing disputes are private matters of the registrar. ICANN's base policy should not claim control over such retention, and if they do, the legal power to do so is certainly not made out. All matters referred to are matters of contract, and the reference to transfers is duplication of 1.1.6 and again merely is referring to the actual subset of powers that ICANN may claim, the TDRP. If ICANN claims ALL Billing records etc. are necessary, then much more review is required. Therefore again, noting I defer to my registrar colleagues on the exigencies of their retention requirements, I agree with Sarah and say that ICANN should, to ensure completeness, undertake a review of all processes that request data from a registrar, to identify the full spectrum of data retention requirements and align them with ICANN Purposes coming out of the EPDP work. Kind regards, Alan [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Tue, Jan 29, 2019 at 3:06 PM Sarah Wyld <swyld@tucows.com> wrote:
Hello All,
Thank you Trang for bringing up the 2013 RAA Data Retention Specification.
We need to identify the purpose and legal basis for every instance of data retention; being included in the 2013 RAA Data Retention Specification is not sufficient -- instead, each instance of retaining data needs to be grounded in an EPDP Purpose.
Looking at the PDF you linked to, I notice that most of the retained elements show a purpose of registrar's internal use and billing issues. These are not purposes defined by the EPDP; if the data is retained for these reasons it would be under the Controller's own controllership and not due to an external requirement.
For other data elements there are a couple other purposes listed in the PDF, but the only specific policy mentioned there is the TDRP, otherwise it's all quite general and thus insufficient to be counted as a purpose with a legal basis.
I suggest we still need to leave the recommendation as Alan W suggested, asking ICANN to undertake a review of all processes that request data from a registrar, to identify the full spectrum of data retention requirements and align them with ICANN Purposes coming out of the EPDP work.
-- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392
On 1/28/2019 8:50 PM, Trang Nguyen wrote:
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-10aug15-en.pdf>.
Best,
Dan & Trang
ICANN Org Liaisons
*From: *Alan Woods <alan@donuts.email> <alan@donuts.email> *Date: *Thursday, January 24, 2019 at 8:50 AM *To: *Theo Geurts <gtheo@xs4all.nl> <gtheo@xs4all.nl> *Cc: *Trang Nguyen <trang.nguyen@icann.org> <trang.nguyen@icann.org>, EPDP <gnso-epdp-team@icann.org> <gnso-epdp-team@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: Image removed by sender. Donuts Inc.][donuts.domains] <https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=>
*Alan Woods*
Senior Compliance & Policy Manager, Donuts Inc. ------------------------------
The Victorians,
15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
[image: Image removed by sender.][facebook.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> [image: Image removed by sender.] [twitter.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> [image: Image removed by sender.] [linkedin.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Thu, Jan 24, 2019 at 1:22 PM Theo Geurts <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: Image removed by sender. Donuts Inc.][donuts.domains] <https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=>
*Alan Woods*
Senior Compliance & Policy Manager, Donuts Inc. ------------------------------
The Victorians,
15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
[image: Image removed by sender.][facebook.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> [image: Image removed by sender.] [twitter.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> [image: Image removed by sender.] [linkedin.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Wed, Jan 23, 2019 at 2:53 PM Theo Geurts <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) R*etention 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: Image removed by sender. Donuts Inc.][donuts.domains] <https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=>
*Alan Woods*
Senior Compliance & Policy Manager, Donuts Inc. ------------------------------
The Victorians,
15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland
[image: Image removed by sender.][facebook.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> [image: Image removed by sender.] [twitter.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> [image: Image removed by sender.] [linkedin.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=>
Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
On Tue, Jan 22, 2019 at 11:43 PM Trang Nguyen <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_resources_pages_policy-2Dstatement-2D2012-2D02-2D25-2Den&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=gSciXDCLwToip-KVqvqL5A4Yuch4VO2F0ALwpUeM0i8&e=>> 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@icann.org> on behalf of Kurt Pritz <kurt@kjpritz.com> *Date: *Tuesday, January 22, 2019 at 1:20 PM *To: *EPDP <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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing listGnso-epdp-team@icann.orghttps://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Thanks Sarah and Alan, It would be helpful if you and the rest of the EPDP Team could please clarify whether the current text of recommendation 11 is intended to result in a replacement of the current requirements in RAA Section 3.4 and the Data Retention Specification (https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#data... DATA RETENTION SPECIFICATION 1. During the Term of this Agreement, for each Registered Name sponsored by Registrar within a gTLD, Registrar shall collect and securely maintain in its own electronic database (as updated from time to time) the data specified below: 1.1. Registrar shall collect the following information from registrants at the time of registration of a domain name (a "Registration") and shall maintain that information for the duration of Registrar's sponsorship of the Registration and for a period of two additional years thereafter: 1.1.1. First and last name or full legal name of registrant; 1.1.2. First and last name or, in the event registrant is a legal person, the title of the registrant's administrative contact, technical contact, and billing contact; 1.1.3. Postal address of registrant, administrative contact, technical contact, and billing contact; 1.1.4. Email address of registrant, administrative contact, technical contact, and billing contact; 1.1.5. Telephone contact for registrant, administrative contact, technical contact, and billing contact; 1.1.6. WHOIS information, as set forth in the WHOIS Specification; 1.1.7. Types of domain name services purchased for use in connection with the Registration; and 1.1.8. To the extent collected by Registrar, "card on file," current period third party transaction number, or other recurring payment data. 1.2. Registrar shall collect the following information and maintain that information for no less than one hundred and eighty (180) days following the relevant interaction: 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; 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 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. 2. If, based on the receipt of either (i) a written legal opinion from a nationally recognized law firm in the applicable jurisdiction that states that the collection and/or retention of any data element specified herein by Registrar is reasonably likely to violate applicable law (the "Opinion") or (ii) a ruling of, or written guidance from, a governmental body of competent jurisdiction providing that compliance with the data collection and/or retention requirements of this Specification violates applicable law, Registrar determines in good faith that the collection and/or retention of any data element specified in this Specification violates applicable law, Registrar may provide written notice of such determination to ICANN and request a waiver from compliance with specific terms and conditions of this Specification (a "Waiver Request"). Such written notice shall: (i) specify the relevant applicable law, the allegedly offending data collection and retention elements, the manner in which the collection and/or retention of such data violates applicable law, and a reasonable description of such determination and any other facts and circumstances related thereto, (ii) be accompanied by a copy of the Opinion and governmental ruling or guidance, as applicable, and (iii) be accompanied by any documentation received by Registrar from any governmental authority, in each case, related to such determination, and such other documentation reasonably requested by ICANN. Following receipt of such notice, ICANN and Registrar shall discuss the matter in good faith in an effort to reach a mutually acceptable resolution of the matter. Until such time as ICANN's Procedure for Handling Whois Conflicts with Privacy Law is modified to include conflicts relating to the requirements of this Specification and if ICANN agrees with Registrar's determination, ICANN's office of general counsel may temporarily or permanently suspend compliance and enforcement of the affected provisions of this Specification and grant the Waiver Request. Prior to granting any exemption hereunder, ICANNwill post its determination on its website for a period of thirty (30) calendar days. Following such modification of ICANN's Procedure for Handling Whois Conflicts with Privacy Law, all Waiver Requests (whether granted or denied) shall be resolved pursuant to such modified procedures. 3. If (i) ICANN has previously waived compliance with the requirements of any requirement of this Data Retention Specification in response to a Waiver Request from a registrar that is located in the same jurisdiction as Registrar and (ii) Registrar is subject to the same applicable law that gave rise to ICANN's agreement to grant such waiver, Registrar may request that ICANN to grant a similar waiver, which request shall be approved by ICANN, unless ICANN provides Registrar with a reasonable justification for not approving such request, in which case Registrar may thereafter make an Waiver Request pursuant to Section 2 of this Data Retention Specification. 4. Any modification of this Data Retention Specification to address violations of applicable law shall only apply during the period of time that the specific provisions of the applicable law giving rise to such violations remain in effect. If the applicable law is repealed or modified (or preempted) in a manner that would no longer prohibit the collection and/or retention of data and information as originally specified in this Data Retention Specification, Registrar agrees that the original version of this Specification will apply to the maximum extent permitted by such modified applicable law. Thank you, Dan and Trang ICANN Org Liaisons From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Alan Woods <alan@donuts.email> Date: Wednesday, January 30, 2019 at 5:04 AM To: Sarah Wyld <swyld@tucows.com> Cc: GNSO EPDP <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] [Ext] Re: EPDP Recommendation 11 - email list discussion Dear all, I am in full agreement with Sarah on this. .@Trang I do think that merely referring 2013 RAA Data Retention Specification as, as noted by Sarah, does not provide the required review, detail, necessity as to Why ICANN requires, in it's base policy, it to be 'retained'. Just from a cursory review, it does appear that the document referenced does not make out a case in any of the noted elements for ICANN's need for retention, except for those matters that refer to transfers as 'example', and as such this is already covered by the TDRP and the 1 year period already defined and linked to the TDRP : 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.7, 1.1.8, 1.2.1 : the 'legitimate purpose' is referred to as 'registrar's internal use' etc - ICANN cannot mandate this, as these elements are, as per the document a registrar internal matter. 1.1.6 - This seems like it's a TDRP matter. Also I must note that the description of a 'for some period' as the retention period is far too anomalous and does not bode well for the though and specificity vis á vis Data protection. I'm unsure, nor is it apparent if the list of data noted here are actually required however by the TDRP - seems more like a kitchen sink approach, rather than a considered list of necessary elements. 1.2.2 , 1.2.3 - Again the maintenance of such records are outside of ICANN's reach. Fraud prevention and billing disputes are private matters of the registrar. ICANN's base policy should not claim control over such retention, and if they do, the legal power to do so is certainly not made out. All matters referred to are matters of contract, and the reference to transfers is duplication of 1.1.6 and again merely is referring to the actual subset of powers that ICANN may claim, the TDRP. If ICANN claims ALL Billing records etc. are necessary, then much more review is required. Therefore again, noting I defer to my registrar colleagues on the exigencies of their retention requirements, I agree with Sarah and say that ICANN should, to ensure completeness, undertake a review of all processes that request data from a registrar, to identify the full spectrum of data retention requirements and align them with ICANN Purposes coming out of the EPDP work. Kind regards, Alan [Image removed by sender. Donuts Inc.][donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=S9tgGzWUyFOG9nI7g9oe4usI7q8poliT12dr2rzqLr0&s=mgqKvLq16JDlaxpwKBWnxekQJnKQCTEWhl388lZF5jk&e=> 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_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=S9tgGzWUyFOG9nI7g9oe4usI7q8poliT12dr2rzqLr0&s=If6k93VfHAXxrcUmthMuH-rZd5yNvjNHizAnW0w6K_w&e=> [Image removed by sender.] [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=S9tgGzWUyFOG9nI7g9oe4usI7q8poliT12dr2rzqLr0&s=PVTOMrLAJHqnta-arfUg4nCKEo35pQd_koefRpfllh8&e=> [Image removed by sender.] [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=S9tgGzWUyFOG9nI7g9oe4usI7q8poliT12dr2rzqLr0&s=B7RYVLrZNCG93SRx1VntTYNvCsZBigN1WGp2Rt3ibM8&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Tue, Jan 29, 2019 at 3:06 PM Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> wrote: Hello All, Thank you Trang for bringing up the 2013 RAA Data Retention Specification. We need to identify the purpose and legal basis for every instance of data retention; being included in the 2013 RAA Data Retention Specification is not sufficient -- instead, each instance of retaining data needs to be grounded in an EPDP Purpose. Looking at the PDF you linked to, I notice that most of the retained elements show a purpose of registrar's internal use and billing issues. These are not purposes defined by the EPDP; if the data is retained for these reasons it would be under the Controller's own controllership and not due to an external requirement. For other data elements there are a couple other purposes listed in the PDF, but the only specific policy mentioned there is the TDRP, otherwise it's all quite general and thus insufficient to be counted as a purpose with a legal basis. I suggest we still need to leave the recommendation as Alan W suggested, asking ICANN to undertake a review of all processes that request data from a registrar, to identify the full spectrum of data retention requirements and align them with ICANN Purposes coming out of the EPDP work. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 1/28/2019 8:50 PM, Trang Nguyen wrote: 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-10au... [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system_files_files_raa-2Ddata-2Dretention-2Delements-2D10aug15-2Den.pdf&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=S9tgGzWUyFOG9nI7g9oe4usI7q8poliT12dr2rzqLr0&s=Rfhi7CqGCOBn9r_sSn10fH4X0VkYCpC4DRurEAlydgI&e=>>. Best, Dan & Trang ICANN Org Liaisons From: Alan Woods <alan@donuts.email><mailto:alan@donuts.email> Date: Thursday, January 24, 2019 at 8:50 AM To: Theo Geurts <gtheo@xs4all.nl><mailto:gtheo@xs4all.nl> Cc: Trang Nguyen <trang.nguyen@icann.org><mailto:trang.nguyen@icann.org>, EPDP <gnso-epdp-team@icann.org><mailto:gnso-epdp-team@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 Error! Filename not specified.[donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland Error! Filename not specified.[facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> Error! Filename not specified. [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> Error! Filename not specified. [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Jan 24, 2019 at 1:22 PM Theo Geurts <gtheo@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]. Error! Filename not specified.[donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland Error! Filename not specified.[facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> Error! Filename not specified. [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> Error! Filename not specified. [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Wed, Jan 23, 2019 at 2:53 PM Theo Geurts <gtheo@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 Error! Filename not specified.[donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=qErXpoDLXrgaa9yUzua-eC4ieccDO74A6lp0-GPnd8g&e=> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland Error! Filename not specified.[facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=aamdD9WBtJsJaJs966aJvmpKSo3Asy15jKkvuoWyqIk&e=> Error! Filename not specified. [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=s6nJrelSmR7S-d2qQwUnRhkCi7VNQWHqnAMzwKb5FlE&e=> Error! Filename not specified. [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_donuts-2Dinc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=Prrhwd8PbpjmrvkiujAgkQFz8Vj4YTIbim4ymnRlIvc&e=> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Tue, Jan 22, 2019 at 11:43 PM Trang Nguyen <trang.nguyen@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_resources_pages_policy-2Dstatement-2D2012-2D02-2D25-2Den&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=NghSLFqweTwAOFMJpbYA3LcVJ0Vvvw6-wxrKoS5l6VY&m=gyM0LQPvqlS_44QFFd7EFD_OYLhfc-A353B_HKq7Bok&s=gSciXDCLwToip-KVqvqL5A4Yuch4VO2F0ALwpUeM0i8&e=>> 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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Kurt Pritz <kurt@kjpritz.com<mailto:kurt@kjpritz.com>> Date: Tuesday, January 22, 2019 at 1:20 PM To: EPDP <gnso-epdp-team@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@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@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@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
participants (3)
-
Alan Woods -
Sarah Wyld -
Trang Nguyen