January 2019 - Gnso-epdp-team

Recommendation 13 - Responsibilities of the Parties - email list discussion
by Kurt Pritz 10 Feb '19

10 Feb '19

Hi Everyone: With the goal of progressing on issues via email, the leadership team has considered the discussion provided during the Toronto meeting and suggests the following compromise language to address the different positions expressed. (This is a resend of an earlier email with only the subject line of the email updated.) Discussion The language below is the same language proposed by the small team that reviewed the comments, but modified: as suggested by Diane during the meeting to reflect that GDPR Art 28 is unlikely to apply in this situation, and by an addition (bracketed & bolded below) to reference the analysis in the Final Report that this team recommends the creation of Joint Controller Agreements, to appropriately influence the negotiation of GDPR-compliant agreements. This language is intended to strike a balance between those preferring to leave some flexibility for ICANN Org and Contracted Parties to consider the appropriate agreements and those preferring to be specific about the type of agreement to be pursued. I understand this is a complex topic that might require additional discussion but it is also possible that we cannot be dispositive on this issue prior to a lengthy contract formation discussion that extends well beyond our time frames. For that reason, we are taking the liberty of making this recommendation and hope you accept it in the spirit it is offered. Proposed Recommendation #13 Language The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing. [Due consideration should be given to the analysis carried out by the EPDP Team in its Final Report.] Action: Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed. Deadline: Monday, 28 January, additional email discussion might follow depending on responses. Sincerely, Kurt

19 37

Geographic Basis - Recommendation for inclusion in the Final Report
by Kurt Pritz 10 Feb '19

10 Feb '19

Hi Everyone: With the ongoing goal of progressing issues via email, the leadership and support teams have considered the review of public comment made during the recent plenary conference call and suggests the following language to capture the agreement in principle that was developed on making Geographic Distinctions. Based on that discussion the recommendation below is proposed for EPDP Team consideration. Team Discussion The Initial Report did not contain a Recommendation for the handling of personal data based on geographical considerations. Instead, the Initial Report asked three questions so that the community input could provide a guide for the EPDP Teams deliberations leading to the Final Report. Those questions were: h) Applicability of Data Processing Requirements h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis? h2) Is there a legal basis for Contracted Parties to differentiate between registrants on a geographic basis? The EPDP Team considered the public comment and developed the following thoughts in its deliberations in addressing the charter questions: The EPDP Team discussed this extensively (as documented in the Initial Report) as well as in the context of the review on the public comments received on the Initial Report. In relation to part of charter question h1, the EPDP Team agrees that contracted parties should be (and are) permitted to differentiate between registrants on a geographic basis; However, the EPDP Team members have divergent views on whether differentiation on a geographic basis should be required. Recognizing that ICANN is a Data Controller in many scenarios and that ICANN may be considered “established” in Europe (within the meaning of the GDPR), the EPDP Team discussed whether those factors would have an effect upon the discussion and determining GDPR-compliant outcomes. It became clear that legal guidance in relation to the applicability of GDPR in the context of ICANN having an ‘establishment’ in Europe could further inform requirements. The EPDP Team also discussed the possibility of developing a set of rules for guiding the making of geographical distinctions in an GDPR-compliant manner (akin to the EWG hypothesized “rules engine”). The Team agreed that creating this set of rules was a complex task (just as it would be for individual registrars) and agreed such development could not occur within the remit of this Phase I EPDP. Such a development would also be dependent on the response to the aforementioned legal guidance. EPDP Team Recommendation (a new recommendation as there was none in the Initial Report) The EPDP Team recommends that the existing requirements of §§ 2.1 and 3 of the Temporary Specification remain in place, i.e., contracted parties should (and are) permitted to differentiate between registrants on a geographic basis, but are not obligated to do so. Based on the legal guidance that is provided on this topic: The EPDP Team may reconsider this recommendation in phase 2 of its work, an Consider the feasibility conditions and methodology for the development of a rule set for making decisions on geographic distinctions. Action Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed. If there are additional questions for ICANN Compliance that would serve to inform the deliberations on this recommendation, please share these also. Deadline: Tuesday, 29 January, additional email discussion might follow depending on responses. Best regards, Kurt

10 14

Re: [Gnso-epdp-team] [Ext] Re: EPDP Recommendation 11 - email list discussion
by Trang Nguyen 05 Feb '19

05 Feb '19

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

3 3

ICANN Compliance question in relation to EPDP Recommendation 7
by Marika Konings 05 Feb '19

05 Feb '19

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

5 4

RrSG Comment on Recommendation 10
by Sarah Wyld 01 Feb '19

01 Feb '19

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

3 2

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Thursday, 31 January 2019
by Andrea Glandon 31 Jan '19

31 Jan '19

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

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 05 February 2019 at 14:00 UTC for 3 hours
by Andrea Glandon 31 Jan '19

31 Jan '19

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

1 0

Re: [Gnso-epdp-team] schedule for completing our work?
by Greg Aaron 31 Jan '19

31 Jan '19

Dear Kurt: Thanks for the schedule notes that you mentioned at the top of today's meeting: * Tomorrow: a draft report goes out to the team * Next week: Kurt begins consensus measuring work * Next week: team begins review of open items Questions: * When do you expect a Final Report draft to be delivered to participants for their final review? * When do you expect the Final Report to be delivered to Council? * What is the schedule for the "Phase 2" work? Thanks, --Greg From: Greg Aaron <greg(a)illumintel.com> Sent: Wednesday, January 30, 2019 4:44 PM To: 'EPDP' <gnso-epdp-team(a)icann.org> Cc: 'Kurt Pritz' <kurt(a)kjpritz.com> Subject: schedule for completing our work? Dear Kurt: As some have mentioned on the list, time to deliver the Final Report is rapidly approaching, and it will be difficult to squeeze yet more hours out of the team. On behalf of SSAC I'm requesting your view about what the schedule will look like between now and delivery of the Final Report to Council. It's our understanding that the GNSO operating guidelines and the EPDP charter oblige the WG to deliver certain things in the Final Report, which the WG team will need prepare in the next few weeks. The language of some of the Recommendations continues to evolve, so we are wondering at what point everyone puts down their pencils and participants will be able to review the proposed final Recommendation language. It seems that only at that point will it be possible to confirm consensus levels. Some of the tasks still to be accomplished are as follows. What is your plan for the below? 1. "Each recommendation in the Final Report should be accompanied by the appropriate consensus level designation, per the Standard Methodology for Making Decisions". When will the measuring or designation process take place, and what process are your planning to use? 2. "It is the role of the Chair to designate which level of consensus is reached and announce this designation to the Working Group. Member(s) of the Working Group should be able to challenge the designation of the Chair as part of the Working Group discussion." 3. "In cases of Consensus, Strong support but significant opposition, and No Consensus, an effort should be made to document that variance in viewpoint and to present any Minority View recommendations that may have been made. Documentation of Minority View recommendations normally depends on text offered by the proponent(s). In all cases of Divergence, the WG Chair should encourage the submission of minority viewpoint(s)." #3 above will require that the WG participants get some time with the draft Final Report to perform review and submit final notes. If all of this has already been laid out to the team, please excuse me asking again. (The schedule info I have been able to find looks out of date.) Anyway, it seems like a good time to confirm this stuff to the team as we all push to the finish line together. With best wishes, --Greg

2 2

Re: [Gnso-epdp-team] [Ext] Re: For your review - Proposed language for agreements reached in principle
by Alan Greenberg 31 Jan '19

31 Jan '19

On Legal vs Natural, any study must also consider the potential risks associated with NOT making the distinction. On the Org Field, the proposal is problematic. If the Registrar has received approval to publish the Org Field, it must be uniformly published. Alan At 31/01/2019 05:25 AM, Alan Woods wrote: Dear all, Apologies that this is late, but alas the never-ending email inbox did it's level best to hide this one on me! Particularly in response to Trang's helpful reminders that the Registry Operator's role requires some clarification in both the legal/natural and the Recommendation 9. To that end we suggest the following edits to Legal/natural (rather straightforward additions within the square brackets) and an additional standalone bullet point to Recommendation 9. Natural vs Legal The EPDP Team recommends that the policy recommendations in this Final Report apply to all gTLD registrations, without requiring Registrars [or registries] to differentiate between registrations of legal and natural persons, although registrars [and registries] are permitted to make this distinction. The EPDP Team recommends that as soon as possible ICANN Org undertakes a study, for which the terms of reference are developed in consultation with the community, that considers: * The feasibility and costs [(including both implementation costs and potential liability costs)] of differentiating between legal and natural persons * Examples of industries or other organizations that have successfully differentiated between legal and natural persons; * Privacy risks to registered name holders of differentiating and not differentiating between legal and natural persons; and * Other potential risks (if any) to registrars and registries of not differentiating. * The EPDP team will discuss the Legal vs Natural issue in Phase 2. Depending on the timing of the research, its discussions may inform the scope of research and/or use its findings. NOTE 1: The original recommendation alternates between 'distinction' and 'differentiation' for no apparent reason. It should be consistent, therefore we opted to use 'differentiate' throughout. NOTE 2: The second inclusion re implementation and liability is just to ensure there is clarity as to what 'costs' are being referred to. Recommendation 9 We suggest the addition of the following bullet point in Recommendation 9: * A Registry Operator, where they believe it feasible to do so, may publish or redact the Org Field in the RDDS output. Rationale: Although we defer to our registrar colleagues on this matter, the expectation of the registry operator's as a result of this, remain unclear. We therefore propose the bullet point to clarify our role. This inclusion highlights the still unreviewed and hugely problematic concept of the transfer of consent between Ry and Rr. The proposed recommendation allows for the publication of the Org at the 'Opt in' option of the registrant, and provides no further process, or clarification as to the onward application of this consent, and indeed makes no provision for adequate implementation of an Art 17 request to either the Ry or Rr. I have no doubt that this process will, in future, undergo technical and legal improvements, which may make this feasible for the registry to accept and apply the 'Opt-In' as obtained at the registrar level, but in the interim, our inclusion, although not purporting to affect the agreement reached for publication of the ORG field by a registrar, now also makes way for an optional publication by the RO (e.g. where a Registry Operator, who perhaps based on the specific model of the Rr (e.g. brand registrars etc) and/or based on other assurances provided to them, including the development and availability of prerequisite technology are satisfied, that the risk of data breach has been lowered to such an acceptable level, that the registry operator may choose to unredact the ORG field in the Registry RDDS output. Again apologies for delay in sending (happy to tee this up on a call), and thank you for the consideration. Alan Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Mon, Jan 28, 2019 at 12:14 PM Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> > wrote: Alan, all, In relation to recommendation #9, please find attached the new thread that Kurt started on this topic with propose updated. You can also find the latest version of the language of recommendations under review, as well as deadlines here: https://community.icann.org/x/VZwWBg (see status of review doc at the bottom of the page). Best regards, Caitlin, Berry and Marika From: Alan Woods <alan(a)donuts.email> Date: Monday, January 28, 2019 at 03:50 To: "Mark Svancarek (CELA)" <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> Cc: "James M. Bladel" <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>>, "Mueller, Milton L" <milton(a)gatech.edu<mailto:milton@gatech.edu>>, Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> >, Trang Nguyen <trang.nguyen(a)icann.org<mailto:trang.nguyen@icann.org> >, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >, Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>, " gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: [Ext] Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle Hey all, Perhaps its the mountain of emails on umpteen topics, but I'm now lost on this recommendation. Perhaps someone refresh the thread with where the text of recommendation 9 now stands after all the back and forth? Thank you! Alan [donuts.domains]<https://urldefense.proofpoint.com/v2/url?u=http-3A__donuts.domains&d=DwMFaQ…> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [facebook.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donut…> [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&…> [linkedin.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_compa…> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Jan 24, 2019 at 8:39 PM Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > wrote: That works for me. From: James M. Bladel <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>> Sent: Thursday, January 24, 2019 09:42 To: Mueller, Milton L <milton(a)gatech.edu<mailto:milton@gatech.edu>>; Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> >; Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>>; Trang Nguyen <trang.nguyen(a)icann.org<mailto:trang.nguyen@icann.org> >; Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >; Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle Taking all of these comments on board, as well as consulting other registrars, I think step 3.3 should provide Registrars the option to “delete” OR “redact” upon no response from the Registrant. Thanks� J. From: "Mueller, Milton L" <milton(a)gatech.edu<mailto:milton@gatech.edu>> Date: Thursday, January 24, 2019 at 6:09 AM To: Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> >, "Mark Svancarek (CELA)" <marksv(a)microsoft.com<mailto:marksv@microsoft.com>>, Trang Nguyen <trang.nguyen(a)icann.org<mailto:trang.nguyen@icann.org> >, "James M. Bladel" <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>>, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >, Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>, " gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle We (NCSG) prefer deletion. If the registrant has been notified about the change and they choose not to respond, then they have chosen not to opt in. Under the principle of both data minimization and opt-in, the only legal path is to delete the information. --MM From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Alan Greenberg Sent: Wednesday, January 23, 2019 1:57 PM To: Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>>; Trang Nguyen <trang.nguyen(a)icann.org<mailto:trang.nguyen@icann.org> >; James M. Bladel <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>>; Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >; Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle I prefer redaction as well. It means there needs to be a flag to indicate it can be publicly displayed, but I agree with the ICANN Org concern about losing potentially important imformation. Alan At 22/01/2019 06:25 PM, Mark Svancarek \(CELA\) via Gnso-epdp-team wrote: Regarding redaction/deletion, I think I prefer redaction. I defer to James whether redaction is technically more annoying than deletion. From: Trang Nguyen <trang.nguyen(a)icann.org<mailto:trang.nguyen@icann.org> > Sent: Tuesday, January 22, 2019 3:14 PM To: Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>>; James M. Bladel <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>>; Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >; Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle Dear All, Regarding the organization field, ICANN org flagged the following in the AC chat during the Toronto face-to-face meeting last week. We wanted to flag this again for your consideration/discussion as you work to finalize the recommendation: Some registrants use the organization field to identify themselves, an example of this is ICANN where the registrant name is â��Domain Administrator�râ� and organization is â��ICANNâ� â€ ( https://www.godaddy.com/whois/results.aspx?domain=icann.org&quot [nam06.safelinks.protection.outlook.com] ;). Under 3(c) in Jamesâ€�s email below, if registrants do not respond the organizatioon field would be deleted. This could result in a number of registrations where identifying information for registrants would no longer be available. Itâ��s unclear if deletion is needed or whether redaedaction of the information would achieve the intent of the recommendation? Regarding the Natural vs. Legal recommendation, the proposed text of the recommendation says: â��without requiring Registrastrars to differentiate between registrations of legal and natural persons, although registrars are permitted to make this distinction.â� Is the intent of the recommendation to limit the requirement to registrars only, or should the text include registries as well? Best, Dan and Trang ICANN Org Liaisons From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of "Mark Svancarek (CELA) via Gnso-epdp-team" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Reply-To: "Mark Svancarek (CELA)" <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> Date: Tuesday, January 22, 2019 at 8:32 AM To: "James M. Bladel" <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>>, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >, Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>, " gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle Makes sense, thanks for clarifying. From: James M. Bladel <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>> Sent: Tuesday, January 22, 2019 8:08 AM To: Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>>; Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >; Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle I think we need to standardize on what the â��Registrant t Orgâ� field is telling us. Some registrars use thiis field to indicate that the Organization is the registrant, so if the end user deletes this information, it has the effect of re-assigning the name to natural person listed as the Registrant. J. From: "Mark Svancarek (CELA)" <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> Date: Tuesday, January 22, 2019 at 8:05 AM To: "James M. Bladel" <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>>, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >, Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>, " gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: RE: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle I think I agree: can you clarify what this means? * Registration is re-assigned to Registrant (natural person) From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Tuesday, January 22, 2019 6:30 AM To: Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> >; Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle Hi Folks �< Letâ��s try to untangle this with the aim on simplicitcity & minimizing confusion (epdp and registrants). Here are my recollections from Toronto: Between the adoption of ePDP and some future date (Jan 1 2020?) Redact Registrant ORG field. Registrars contact Registrants who have data in this field, and ask them to confirm the data is correct & accurate. Based upon Registrant Action � 1. Registrant Confirms or Corrects � Data remains n Org field. > 2. Registrant Declines � Data in Org field is DELETED, Registration iss re-assiigned to Registrant (natural person) 3. Registrant No Response � Data in Org field is DELETED, Registrationn is re-assigned to Registrant (natural person) After future date � New registrations would present some disclosure/disclaimer when data is entered in the ORG field Registrars are free to innovate on the exact process, either an opt-in, or pop-up or locked/grayed out field, etc. ORG will be treated as the legal-person registrant of the domain name, with the Natural Person listed as a point of contact. ORG field will be published, if it contains data. From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org> > Date: Tuesday, January 22, 2019 at 6:02 AM To: Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>>, " gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle Thanks, Sarah, for flagging this. We actually went back and forth on this looking at the transcript and our understanding was that opt-in was for existing registrations, while opt-out would apply to any new registrations (with the appropriate information being provided to the registrant that the information for the Organization field would be published, unless indicated differently). However, as this was Jamesâ��s proposal, we would like to ask him to confirm rm what the original proposal was so that the recommendation can be adjusted, as needed. James, over to you. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Sarah Wyld <swyld(a)tucows.com<mailto:swyld@tucows.com>> Organization: Tucows Date: Tuesday, January 22, 2019 at 05:36 To: " gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Subject: Re: [Gnso-epdp-team] For your review - Proposed language for agreements reached in principle Good morning, I notice a significant difference between the Toronto Day 3 notes and the draft below, regarding the Organization field. Day 3 notes - "Principles for Redaction of Registrant Organization Field" #4: 4. Upon (1) the registration of a Registered Name sponsored by Registrar or (2) the transfer of the sponsorship of a Registered Name to Registrar, the Registrar MUST inform all Registered Name Holders that the Registrant Org field will be redacted unless the Registered Name Holder affirmatively opts in to the publication of the Registrant Org field. Updated Recommendation #9 below: 4. Upon (1) the registration of a Registered Name sponsored by Registrar or (2) the transfer of the sponsorship of a Registered Name to Registrar, the Registrar MUST inform the Registered Name Holder that the Registrant Org field will be published unless the Registered Name Holder affirmatively opts in to redaction of the Registrant Org field. The Org field should be redacted by default, and the Registered Name Holder should be able to opt-in to publication. This aligns with the principle of Privacy by Default and is what we agreed on during the Day 3 meeting. Thanks, -- Sarah Wyld Tucows +1.416 535 0123 Ext. 1392 On 1/22/2019 12:33 AM, Marika Konings wrote: Dear EPDP Team, In Toronto, we reached agreement in principle on several issues but did not have time to develop language to which the team agreed. To move that discussion forward, the support team has developed the proposed language below for discussion and inclusion in the Final Report. Please review this language with your group to ensure it aligns with the agreement that was reached. If you are of the view that it does not conform to the agreement, please: Respond to this message and change the subject line to the topic of the recommendation about which you have concerns; Outline your concerns, focusing on how the proposed language does not reflect the principle agreement reached, and; Propose edits that would address your concerns that are in line with the agreement reached. The deadline for doing so is Thursday 25 January so that there is sufficient time to review and discuss any concerns. If no concerns are raised, this language will be incorporated into the draft Final Report for your review. Best regards, Caitlin, Berry and Marika ========= Based on the discussions during the F2F meeting in Toronto, the following updated language is provided for EPDP Team review on the following topics / recommendations: Natural vs. legal Draft recommendation1) The EPDP Team recommends that the policy recommendations in this Final Report apply to all gTLD registrations, without requiring Registrars to differentiate between registrations of legal and natural persons, although registrars are permitted to make this distinction.2) The EPDP Team recommends that as soon as possible ICANN Org undertakes a study, for which the terms of reference are developed in consultation with the community, that considers: * The feasibility and costs of distinguishing between legal and natural persons; * Taking into account examples of industries or other organizations where this has been successfully done; * Consider privacy risks to registrants, and; * Consider the risks of not differentiating. 3) Depending on the timing of the research, whether to inform the scope or make use of its findings, the EPDP team will discuss the Legal vs Natural issue in Phase 2. Consent to publish additional contact information Agreement in principle: In its discussion on consent, the Temporary Specification omitted RNH email as a piece of information to which the registrant could consent to publication. This draft recommendation corrects that omission. Draft recommendationThe EPDP Team recommends that, as soon as commercially reasonable, Registrar must provide the opportunity for the Registered Name Holder to provide its Consent to publish additional contact information. Organization Field Agreement in principle: Rather than requiring the publication or redaction of the Organization Field, a phased approach was suggested by Team Members that gained general agreement. Updated Recommendation #9 1. The EPDP Team recommends that Registrars MAY begin redacting the Registrant Org field immediately.2. For existing registrants: the EPDP Team recommends that Registrars MUST notify all existing Registered Name Holders that the Registrant Org field will be treated as non-personal data for new registrants beginning on [x date - to be agreed upon during the implementation of this Policy], and accordingly, the field will be published for new registrants in the freely-accessible directory beginning on [x date]. However, if existing Registered Name Holders wish to have its Organization field published within the freely-accessible database, it must affirmatively consent to the publication by opting in. If the Registered Name Holder affirmatively opts in to the publication of its existing (or modified) Registrant Organization, the Registrar may publish the Registrant Organization Field immediately and/or on the agreed-upon [x] date.3. The EPDP Team recommends if the existing Registered Name Holder does not affirmatively opt in to the publication of its Registrant Organization field, the Registrar will show the existing Registrant Organization Field but the field MAY be left blank.4. Upon (1) the registration of a Registered Name sponsored by Registrar or (2) the transfer of the sponsorship of a Registered Name to Registrar, the Registrar MUST inform the Registered Name Holder that the Registrant Org field will be published unless the Registered Name Holder affirmatively opts in to redaction of the Registrant Org field. Deferring consideration of new proposed purposes to phase 2 Agreement in principle: With regards to proposed Purpose O, the Purpose supporting ARS, and the additional purposes received through public comment, the EPDP Team understands some legal clarification is required as to whether those purposes can fall under existing Purposes. Additional complexities were introduced. Therefore, the Team decided to put off this discussion for Phase 2 where the EPDP Charter makes it clear that additional Purposes are, in fact, anticipated. Draft recommendationThe EPDP Team commits to considering in Phase 2 of its work whether additional purposes should be considered to facilitate research carried out by ICANNâ��™s Office of the Chief Technology Officer (OCTO) as well as the continuation of the WHOIS Accuracy Reporting System (ARS). This consideration should be informed by legal guidance on if/how provisions in the GDPR concerning research apply to ICANN Org. Marika KoningsVice President, Policy Development Support � GNSO, Internet Corporatioon for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSOFind out more about the GNSO by taking our interactive courses [nam06.safelinks.protection.outlook.com]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…> and visiting the GNSO Newcomer pages [nam06.safelinks.protection.outlook.com]<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefens…>. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team [nam06.safelinks.protection.outlook.com] [ nam06.safelinks.protection.outlook.com [nam06.safelinks.protection.outlook.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__nam06.safelinks.protect…>] _______________________________________________Gnso-epdp-team mailing listGnso-epdp-team(a)icann.org<mailto:listGnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team [nam06.safelinks.protection.outlook.com] _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team ---------- Forwarded message ---------- From: Kurt Pritz <kurt(a)kjpritz.com<mailto:kurt@kjpritz.com>> To: EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> > Cc: Bcc: Date: Fri, 25 Jan 2019 11:13:26 -0800 Subject: [Gnso-epdp-team] Organization Field - Updated - Recommendation #9 Hi Everyone: In the ongoing and seemingly never-ending attempt to close discussion on Recommendations for the Final Report via email discussion, below please find amended wording for Recommendation 9, having to do with the publication / redaction of the Organization field. After posting of the initial version, I read the email list comment and was drawn to James’ rather clean outline, as opposed to my less clear earlier proposal. Therefore, I took the liberty of reorganizing the proposed Recommendation somewhat, taking into account not only James structure but also the email comments before and after that (as well as the meeting notes). The result is below. I also placed the procedure itself as part of our “implementation advice” as there will be operational details to figure out. The implementation effort can ensure that those “details” are consonant with the policy goals. Proposed Recommendation #9 The EPDP Team recommends that: - The Organization field will be published if that publication is acknowledged or confirmed by the registrant via a process that can be determined by each registrar. If the registered name holder does not confirm the publication, the Organization field can be redacted or the field contents deleted at the option of the registrar. - The implementation will have a phase-in period to allow registrars the time to deal with existing registrations and develop procedures. - In the meantime, registrars will be permitted to redact the Organization Field. Implementation advice: the implementation review team should consider the following implementation model discussed by the EPDP Team: For existing registrations, the first step will be to confirm the correctness / accuracy of the existing Organization field data. For the period between the adoption of EPDP policy recommendations and some future “date certain” to be determined by the implementation review: 1) Registrars will redact the Organization field 2) Registrars will contact the registered name holders that have entered data in the Organization field and request review and confirmation that the data is correct. a. If the registered name holder confirms or corrects the data the data will remain in the Organization field. b. If the registrant declines, or does not respond to the query, the Registrar may redact the Organization field, or delete the field contents. If necessary, the registration will be re-assigned to the Registered Name Holder. 3) If Registrar chooses to publish the Registrant Organization field, it will notify these registered name holders that of the “date certain,” the Organization field will be treated as non-personal data and be published, for those Registered Names Holders who have confirmed the data and agreed to publication. For new registrations, beginning with the “date certain”: 1) New registrations will present some disclosure, disclaimer or confirmation when data is entered in the Organization field. Registrars are free to develop their own process (e.g., opt-in, pop-up advisory or question, locked/grayed out field). 2) If the registered name holder confirms the data and agrees to publication: a. the data in the Organization field will be published, b. The Organization will be listed as the Registered Name Holder. c. The name of the registered name holder (a natural person) will be listed as the point of contact at the Registrant Organization. Actions: Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed. Deadline for comment: Tuesday 29 Jan. Thank you and best regards, Kurt

1 0

Purpose 1(a) & 1(b) workbooks
by Alan Woods 31 Jan '19

31 Jan '19

Dear team, Many apologies for the delay in getting these documents to you. The issue lies in the fact that the processes described are rather complex and are not an easy fit in the Workbook format, as it does not allow for an actual true representation of the data flows and processes. Hopefully this can be refined as soon as possible, (the small team???) but in the meantime the data elements for the minimum data set for these purposes are however more clear in these. Kind regards, Alan Alan Woods Senior Compliance & Policy Manager, Donuts Inc. The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland 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.

2 2