February 2019 - Gnso-epdp-team

Geographic Basis - Recommendation for inclusion in the Final Report
by Kurt Pritz Feb. 10, 2019

Feb. 10, 2019

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

Proposed Agenda - Meeting #45
by Caitlin Tubergen Feb. 10, 2019

Feb. 10, 2019

Dear EPDP Team, Please find the proposed agenda for tomorrow below. Updated langauge for the data retention recommendation (#15, formerly #11) will be circulated shortly. Best regards, Marika, Berry, and Caitlin EPDP Meeting #45 Agenda Monday, 11 February 2019 1. Roll Call & SOI Updates (5 minutes) 2. Welcome and Updates from EPDP Team Chair (5 minutes) a. Review of outstanding action items b. Other updates, if applicable 3. Implementation Bridge – Recommendation #28 (30 minutes) a. Review proposed language for inclusion in the Final Report: The EPDP Team recommends that the effective date of the gTLD Registration Data Policy shall be [February 29, 2020]. All gTLD Registry Operators and ICANN-accredited registrars will be required to comply with the gTLD Registration Data Policy as of that date. The EPDP Team recommends that until [February 29, 2020], registries and registrars are required EITHER to comply with this gTLD Registration Data Policy OR continue to implement measures consistent with the Temporary Specification (as adopted by the ICANN Board on 17 May 2018, and expired on 25 May 2019). Registries and registrars who continue to implement measures compliant with the expired Temporary Specification will not be subject to Compliance penalty specifically related to those measures until February 29, 2020. The EPDP Team furthermore recommends that, as a matter of urgency, the GNSO Council and ICANN Org, informally convene the Implementation Review Team to allow for the necessary planning to take place before ICANN Board consideration of this Final Report, following which the IRT would be formally convened. b. Discuss proposed language for inclusion in the Final Report c. Confirmation of agreement reached or next steps to come to agreement 4. Recommendation #18 (old #12) - Reasonable Access (30 minutes) a. Consider how to address applicability of the criteria in the body of the report – Thomas to suggest language? b. Confirmation of agreement reached or next steps to come to agreement 5. Recommendation #15 (old #11) – Data Retention (30 minutes) a. Review revised language circulated to the mailing list b. Discuss revised language c. Confirmation of agreement reached or next steps to come to agreement 6. Data Elements Workbooks (30 minutes) a. Status Update b. Further updates expected in relation to Final Report c. Questions / Comments? 7. Next Steps (10 minutes) 11 February 2019EPDP Team Meeting (if necessary) Consider any remaining / outstanding issues EPDP Team 11 February 2019 (Council Document Deadline)(Draft) Final Report SubmissionSubmit motion and latest version of Final Report to GNSO Council for considerationStaff Support Team / Council Liaison 11 – 15 February 2019Quiet Time“Quiet Time” – opportunity for EPDP Team to review Final Report, flag any issues that were overlooked, are inconsistent or in error and review consensus designations (note, this is NOT an opportunity to reopen previously closed issues or question previously reached agreements)GNSO Council 14 February 2019Council Special MeetingOpportunity to brief GNSO Council on the draft Final Report, highlighting that further updates are possible as a result of issues that may have been identified during the quiet period. GNSO Council 15 February 2019Deadline Quiet Period IssuesDeadline for flagging any issues that were overlooked, are inconsistent or in error, or disagreement with consensus designationsEPDP Team 19 February 2019EPDP Team Meeting (if necessary) Consider issues flagged as a result of the quiet period review and consider how these should be addressed EPDP Team 20 February 2019EPDP Team Meeting (if necessary) Consider issues flagged as a result of the quiet period review and consider how these should be addressed EPDP Team 20 February 2019Final Report Submit Final Report or confirm that version submitted on 11 February should be considered finalStaff Support Team / Council Liaison 21 February 2019Consider Final Report for adoptionGNSO Council 4 March 2019Consider Final Report for adoption (if needed)GNSO Council 8. Wrap and confirm next meeting to be scheduled for Tuesday, 19 February 2019 at 14.00 UTC (5 minutes) a. Confirm action items b. Confirm questions for ICANN Org, if any

1 0

Updated Implementation Bridge Language
by Alan Woods Feb. 10, 2019

Feb. 10, 2019

Hey All, Just wish to send around the proposed Implementation Bridge language for the team's revie:. The EPDP Team recommends that the effective date of the gTLD Registration > Data Policy shall be [February 29, 2020]. All gTLD Registry Operators and > ICANN-accredited registrars will be required to comply with the gTLD > Registration Data Policy as of that date. The EPDP Team recommends that > until [February 29, 2020], registries and registrars are required EITHER > to comply with this gTLD Registration Data Policy OR continue to implement > measures consistent with the Temporary Specification (as adopted by the > ICANN Board on 17 May 2018, and expired on 25 May 2019). Registries and > registrars who continue to implement measures compliant with the expired > Temporary Specification will not be subject to Compliance penalty specifically > related to those measures until February 29, 2020. 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.

2 1

Consensus Calls - Cluster 1
by Ben Butler Feb. 10, 2019

Feb. 10, 2019

Hi Kurt, Following deliberations with the SSAC concerning cluster 1 (Purposes), please find below the SSAC comments. We approve as written Purposes 1, 3-7, seeing no significant security or stability concerns. Regarding Purpose 2 (and by extension Recommendation 2), the SSAC provides the following comment: SSAC supports the sentiment behind Recommendation 2, but not the language. The language is flawed and does not provide a clear and actionable recommendation to the GNSO Council and the ICANN Board. SSAC takes this opportunity to clarify intent and urge that the problems with the language be fixed. SSAC believes that the ePDP team shared a common sentiment: that policy-making regarding lawful access of non-public data should definitely proceed now that the gating factors have been addressed. SSAC supports that sentiment. There are three problems with Recommendation 2's language: 1. It says the group makes a recommendation but then does not say what the recommendation is. It should clearly recommend that further policy development on the topic take place. The current ambiguity leaves open the prospect that the Recommendation will be misunderstood. 2. Recommendation 2 says that "the EPDP team will consider amongst other issues, disclosure in the course of intellectual property infringement and DNS abuse cases." But that is technically not possible, because the current ePDP is expiring and this ePDP team cannot consider further issues. Council will need to authorize a new or add-on policy process to complete the unfinished work from the current ePDP. 3. It does not address timing or urgency. The issues were included in the current ePDP’s charter and were supposed to be addressed already but remain unfinished. The open issue is vital to security and stability, and in SAC104 the SSAC has urged the Council to adopt an ambitious deadline to complete this work. We therefore suggest that the first part of the recommendation be something more clear and actionable, such as: “The EPDP Team recommends that the Council immediately authorize an additional ePDP to consider a system for Standardized Access to non-public Registration Data (referred to in the Charter as ’Standardised Access’). This should be designed to fulfill undelivered work items contained in the present EPDP Team Charter. It will be in line with Purpose #2, and is possible to begin because the gating questions in the charter have been answered.” [footnote to below:] [Staff can place the following in the footnote:] The above comments are based on statements endorsed by the entire SSAC, found in: * SAC101 Recommendation 1A: "ICANN policy-making should result in a domain registration data policy, including statements of purposes for the collection and publication of the data." * SAC101 Recommendation 1D: "The ICANN Board should support the creation of an accredited RDDS access program, with the ICANN Organization ensuring the creation, support of, and oversight of the supporting technical access mechanism. This program will identify qualified users, enable their access under appropriate data protection measures, and will allow RDDS server operators to manage those users’ access accordingly. The technical access mechanism should include a credential management system so that users do not need to negotiate and set up access with RDDS operators individually." * SAC101 Recommendation 3: "The ICANN Board and EPDP policy-makers should ensure that security practitioners and law enforcement authorities have access to domain name contact data, via RDDS, to the full extent allowed by applicable law." * SAC104: "The SSAC urges the GNSO to begin planning further efforts now, to complete the policy-making that has been started. It is vital to keep momentum. Driven by the GDPR, the EPDP is finally addressing some long-delayed issues. It will not serve the Internet community, or ICANN as a multistakeholder organization, if the work is allowed to drift. We urge the GNSO to begin planning next steps, with specific deliverables and ambitious deadlines for completion." (Section 2.3) Thanks, -Ben From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Kurt Pritz <kurt(a)kjpritz.com> Date: Friday, February 8, 2019 at 11:27 AM To: GNSO EPDP <gnso-epdp-team(a)icann.org> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion Hi Everyone: To summarize this discussion: We have read Trang’s intervention carefully and recognize the wording referenced in the GDPR. In this email chain, we also recognized the research that Thomas (with Farzaneh) conducted in forming their advice to this team and Alan’s reference to local laws and authoritative GDPR guidance. After considering that, 1) I have not seen any team member representing a Stakeholder Group or Advisory Committee recommend a departure from the use of the word “agreement’ in the recommendation. I.e., I have not seen support for changing “agreement” to “arrangement.” Kavouss has made a good faith offer of compromise in suggesting “mutually agreed upon…” but I don’t see the purpose of compromise at this juncture. Without describing the rationale for staying with “agreement,” I can easily see reasons why each SO/AC here would appreciate that level of specificity. 2) While I agree with the conclusions Thomas has reached regarding the requirement for JCAs, I think the wording currently proposed (by the contracted parities and supported by the GAC) is acceptable in order to provide the parties negotiating the ability to determine which processing steps are best addressed with the parties as Joint Controllers, Controllers and Processors. 3) With regard to concerns about the clause, “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," as raised by Chris, I don’t read this as meaning that all liability is borne by the Controller, or as Chris states the ICANN Board concern, “by ICANN.” For example, negligence on the part of a processor should not raise liability in the Controller absent some specific circumstances. On this last topic, I think we ae waiting to hear more from the Board or elsewhere in ICANN. Itaking Chris recommendation into account and doing some type of mashup: “Indemnification clauses shall ensure that the risk for certain data processing is borne, to the extent appropriate, by either one or multiple parties that determine the purpose and means of the processing." In total: The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements, 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 should ensure that the risk for certain data processing is borne, to the extent appropriate, 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. Please respond and let me know whether you believe this to be an appropriate solution. Best regards, Kurt On Feb 8, 2019, at 5:05 AM, Emily Taylor <emily.taylor(a)oxil.co.uk<mailto:emily.taylor@oxil.co.uk>> wrote: Hi all I support Alan's point of view. While I understand the need to retain flexibility, and to avoid overly restrictive language that will cause problems later on, the word 'arrangement' could mean almost anything - from something that imposes legal benefits and responsibilities to something that's very informal, undocumented and just a way of working. So, I support use of the word 'agreement' instead of 'arrangement'. Best wishes Emily On Fri, Feb 8, 2019 at 1:02 PM Alan Woods <alan(a)donuts.email<mailto:alan@donuts.email>> wrote: Just to be exceptionally clear and although I do not wish to belabor the point any farther, I still submit, on the record, that the correct term to be used in the recommendation is 'AGREEMENT' Whereas I appreciate that ICANN have mirrored the GDPR language of Art 26 in their use of the word of 'arrangement' I believe it would make more sense to consider the subsequent interpretation of their lead DPA (i.e Belgium, as confirmed by the Belgian Autorité de Protection des Données (APD) letter of 15th January 2019 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby…> and the therein referenced letter of September 26th, 2018<https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby…> ). I would therefore respectfully submit that it remains more proper for our recommendation to therefore consider and mirror the Belgian legislatures and the APD's interpretation of the GDPR as being our guiding, if not determinative factor: 1) Article 52 of the Loi relative à la protection des personnes physiques à l’égard des traitements de données à caractère personnel (30 July 2018)<http://www.ejustice.just.fgov.be/cgi_loi/loi_a.pl?language=fr&dt=LOI&cherch…> (see page 27 of the Gazette as linked) requires " Un accord définit de manière transparente les obligations respectives des responsables conjoints de traitement, " [emphasis added], Which translates to "an agreement which defines the respective obligations of the joint controllers" [emphasis added] 2) The APD have also released a legal notation of the July 2018 law<https://www.autoriteprotectiondonnees.be/sites/privacycommission/files/docu…>, and they note the joint controller requirement as being "par voie d’accord' (see page three under heading or again to translate, is an "by agreement". (see page 3 under the heading "Responsables conjoints de traitment") Therefore I still believe and submit that the ePDP teams original wording of "agreement" should stand, and I don't believe that ICANN's reference to their past statement i.e. "arrangement” could take the form of an agreement, a policy, or a specification" is sufficient as it dilutes the expectation of the APD. This is not sufficiently specific in the circumstances; nor does it provide the comfort that the ePDP team is seeking in this recommendation from ICANN. Kind regards, Alan [Donuts Inc.]<http://donuts.domains/> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [http://storage.googleapis.com/signaturesatori/icons/facebook.png]<https://www.facebook.com/donutstlds> [http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc> [http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh(a)gmail.com<mailto:kavouss.arasteh@gmail.com>> wrote: Dear Kurt I have indicated at several occasions that when we refer to an action to be performed by two parties / entities ,we need to indicated " as mutually agreed" The proposed text to be amended to read as below 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, "AS MUTUALLY AGREED " 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. Please kindly insert that in the text Regards Kavouss On Thu, Jan 24, 2019 at 12:23 AM Kurt Pritz <kurt(a)kjpritz.com<mailto:kurt@kjpritz.com>> wrote: 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 _______________________________________________ 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 _______________________________________________ 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 -- Emily Taylor CEO, Oxford Information Labs MA (Cantab), Solicitor (non-practising), MBA, Associate Fellow, Chatham House; Editor, Journal of Cyber Policy Lincoln House, Pony Road, Oxford OX4 2RD | T: 01865 582885 E: emily.taylor(a)oxil.co.uk<mailto:emily.taylor@oxil.co.uk> | D: 01865 582811 | M: +44 7540 049322 [https://drive.google.com/a/oxil.co.uk/uc?id=1-3eDLYPfLpkj30Jc34NcbkD1xt8NQp…]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>[https://docs.google.com/a/oxil.co.uk/uc?id=0B7sS_6djDxsHNm92d21jM21HMDQ&exp…]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017> Registered office: Lincoln House, 4 Pony Road, Oxford OX4 2RD. Registered in England and Wales No. 4520925. VAT No. 799526263 . _______________________________________________ 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

5 5

EPDP Consensus Call #1
by Kurt Pritz Feb. 9, 2019

Feb. 9, 2019

Hi Everyone: This is a long email but each of the points here is important to me, so please read it. This email launches what will be at least three "consensus calls" that will conclude the first phase of our work. The process and timing for this step has been so often discussed that I am afraid it appears to some than a much a bigger step than it really is, which is to reconfirm the state of our work. During earlier stages of our work, I was of a mind to conduct these consensus calls as we came to individual conclusions - so that these steps would not seem like so much of a big deal. To me, the big deal occurred when we came to agreement on each of the seven “purposes” that are now part of our recommendations. We started out with the 13 purposes that were in the Temporary Specification and, after many hours of discussion and compromise, developed the current list of seven. I think that is what this group did best. Even though there has been a time gap between each of our agreements and this consensus call, this final step should be treated as the natural follow-on to our discussion. There are a few particulars in the published guidelines of the consensus calls process that I wish to call out to explain why we are following this methodology (and why I believe you can treat this step as a natural follow-on to our previous work). 1) We are making this call via email because, "Consensus calls should always involve the entire Working Group and, for this reason, should take place on the designated mailing list to ensure that all Working Group members have the opportunity to fully participate in the consensus process.” 2) I am making these assignments as to the level of agreement on my own and then I am checking them with you because, "It is the role of the Chair to designate which level of consensus is reached and announce this designation to the Working Group. Members of the Working Group should be able to challenge the designation of the Chair as part of the Working Group discussion.” 3) I believe we have satisfied the requirement that, "After the group has discussed an issue long enough for all issues to have been raised, understood and discussed, the Chair makes an evaluation of the designation and publish it for the group to review,” because we discussed each issue (either led by CBI or me), and there was a significant pause at the end of each conclusion to check for other viewpoints. (There were mild complaints by some that this was done to excess.) The conclusions were then published for team review: in meeting notes, on the team wiki page, and in drafts of final reports. This is the time in this email for me to state that this is not the time for revisions or the re-opening of discussion. While we have completed this phase of work in a relatively short time, each discussion was thorough and knowledgable. (Even today, a small team is reviewing every data element and processing step in the data workbooks in order that the final report reflects the competence of our work.) Memories of our extended discussion to arrive at the current set of recommendations are likely buried under the avalanche of the work in attending to the remaining issues. While the particulars of those earlier discussions might be forgotten, we should have confidence that the earlier debates need not be repeated. The penalties for not completing our work by the due date (as imposed by others) has become more clear over time and we are not afforded the luxury of re-checking our work. The language in many of these recommendations makes it clear that these are the product of compromise - I think every group on this team has made a significant concession along the way. Given that, I am making a slight perturbation in the way your feedback to each of my designations is collected. The way the process is described in the working group guidelines is that for each of the recommendations (including each of the purposes for collecting registration data), I am obligated to indicate the degree of agreement that has been reached on each: full consensus, consensus, strong support, divergence, and minority view. (The definitions of each are in an attached document.) Generally, minority statements by groups in opposition to “consensus" or "strong agreement” can be published. Given the degree of compromise that has occurred, I also want to give a voice to groups who go along with the consensus position but that want to preserve an argument for the record or for a later date. I think that groups who had the courage to compromise and support agreement on an issue should not be prevented from publishing supplemental thoughts. If your group wishes to provide a supplementary statement to accompany your support of consensus, that will be accepted for publication along with the final report. If offered, each of these statements should begin with some affirmation of the consensus position. So with that, we’ve divided these emails into three sections of the team’s work. We did this to make the process easier for you to manage (avoiding 20+ emails), and to start this process while the last issues are being completed. We will The three sections are: The Purposes for Processing Registration Data: Purpose 1 - Establish the rights of a Registered Name Holder Purpose 2 - Maintaining SSR through enabling of lawful access Purpose 3 - Enable communication with RNH Purpose 4 - Safeguarding RNH's Registration Data Purpose 5 - Handling Contractual Compliance Purpose 6 - Resolution of DRPs Purpose 7 - gTLD registration policy eligibility criteria Recommendations considered completed in our earlier discussions: Recommendation #2 - Commitment to consider a system for Standardized Access to non-public Registration Data Recommendation #3 - Requirements related to accuracy Recommendation #15 - URS / UDRP Recommendation #16 - Instructions for RPM PDP WG Recommendation #17 - Input from RPM PDP WG to inform subsequent access discussion Recommendation #18 - Data processing agreements with dispute resolution providers (incl. Question #4) Recommendation #19 - Transfer Policy Recommendation #20 - Input to Transfer Policy review (incl. Question #5) Recommendation #21 - Data processing agreements with non-Contracted Party entities involved in registration data processing Recommendation #8 - Redaction Recommendation #13 - Controller Agreement Recommendation #6 - Escrow Providers Recommendation #7 - Contractual Compliance New – Consent to publish additional information Recommendations in the process of being completed or where there is disagreement: Recommendation #9 - Organization field Recommendation #NEW - City Field Recommendation #10 - Email communication Recommendation #14 - Responsible parties Recommendation #4 - Data elements to be collected by Registrars (incl. Question #2) Recommendation #5 - Data elements to be transferred from Registrars to Registries Recommendation #New - Geographic Basis Recommendation #New - Natural vs. legal Recommendation #12 - Reasonable access Recommendation #NEW - Implementation Transition Period Recommendation #11 - Data retention Recommendation #22 - Impact on other policies Recommendation #NEW - Additional Purposes It will come as no surprise to you that I believe that we have reached agreement on the first two sets of recommendations, and also that I wish to work pretty hard during the time we have on resolving the remaining issues in the third set. The third set these recommendations might be “unbundled” as we come to agreement on some or if we think extending or tolling the discussion might get us to consensus on others. The attached document contains a summary of the first set of agreements. Each contains the shorthand title and the wording of the recommendation in the final report. It is important to note that the shorthand title does not appear in the final report, just the recommendation itself plus the accompanying explanation that you can read in the currently posted version of the final report. Also, I have added for your reference the GNSO Guidelines for working group decision making are included. In another slight contravention to the standard practice, I have used the label, “Full Consensus / Consensus” as a signal to the GNSO Council that we have reached a consensus position on these issues but also as a salute to or indiction of the degree of teamwork and compromise that has taken place. Either term has an equivalent effect on the Council discussion. On this first set, please revert to me by the end of Wednesday if you disagree with my assessment and if you will provide a statement for the final report. Remember that you can support a consensus position and still provide a statement. The second set will be published tomorrow and will ask for feedback by Thursday. If we can in someway extend these deadlines (and we are working to do that), I will let you know. Thank you for taking your time to read this. Sincerely, Kurt

5 5

Proposed path for additional topics flagged
by Marika Konings Feb. 9, 2019

Feb. 9, 2019

Dear EPDP Team, The leadership team has reviewed the additional topics that were put forward for EPDP Team consideration by the deadline and has suggested a path forward in the attached document. Please do have a look to make sure that you are comfortable with the proposed path forward and confirm that it aligns with the EPDP Team discussions to date. We would like to especially draw your attention item 3 (optional tech contact), item 6 (redaction) and item 11 (purpose 1). If your group is not comfortable with the proposed path forward for any of the topics in the table, please flag this as soon as possible, preferably prior to tomorrow’s meeting so it can be added to the agenda for tomorrow’s meeting, but no later than Thursday 7 February COB. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

4 4

Re: [Gnso-epdp-team] For your review: updated recommendations 10, 11, 12
by Kavouss Arasteh Feb. 9, 2019

Feb. 9, 2019

Dear All, The amendment proposed by Marc SEENS REASOABLE THUS i SUPPORT IT Regards Kavouss On Sat, Feb 9, 2019 at 10:37 AM Arasteh <kavouss.arasteh(a)gmail.com> wrote: > Kurt > Thomas > Ashley > Thank you all > Let us wait the reaction of Thomas > Kurt > Once again > I request you to kindly treat all comments and suggestion equally based on > their merits > I have made several but never ever you analysed that like what you did for > thus and few other cases > Pls kindly reconsider sud-est your treatment > All of us are equal . > We should kyste. To the song and NOT THE SINGER > TKS > > Sent from my iPhone > > On 8 Feb 2019, at 17:04, Kurt Pritz <kurt(a)kjpritz.com> wrote: > > Thanks for this additional input on Recommendation 13. Please forgive > these observations and consider this recommendation for closing off this > remaining issue. > > During our meeting Thomas was given the floor to explain his edits. During > that, there was the usual chat going on: first some non-substantive > commentary, then a different discussion. Partially through Thomas’ > intervention, I shook myself out of watching the chat to listen to Thomas, > who was making a careful, studied explanation of his addition. I kicked > myself (figuratively) for missing part his explanation when, in a few > months, any of us would probably give a lot to have Thomas available to > answer questions such as these. It made we wonder how many of us were > watching the chat instead of listening. > > Understanding Thomas point, I made the suggestion to the group that we > retain it in some form (a more complete explanation of the issue) but move > it down into the body of the recommendation as an item to be considered. At > that point, my sense was that the team wanted to leave it first and > foremost and I withdrew my suggestion to move it. > > Having said that, I understand Ashley’s comment that we don’t have a full > handle on the effect of the GDPR sections Thomas cited on out > recommendations. > > I recommend that we: > > - respectfully ask Thomas to augment the issue somewhat with a couple > / few sentences. > - move that issue to the annotation describing the recommendation with > a notation that this issue be sorted out during the implementation > discussion. > > > Let me know what you think. > > Best regards, > > Kurt > > > > > At 07/02/2019 03:52 PM, Heineman, Ashley wrote: > > Thanks for this and hello colleagues, > > After further reflection on todayâ€™s discussion of Recommendation 12 and > the new text proposed by Thomas, I believe this language should be > deleted. Specifically –“ â€œThese criteria are applicable to disclosure > requests relating to civil claims. LEA requests will be handled according > to applicable laws.â€ > > While I am extremely pleased with the state of the Recommendation overall, > this new insertion has not been fully considered and I believe is > misplaced. > > I understand and am sympathetic to Thomasâ€™ concerns, but that being > said, I believe those concerns are best addressed elsewhere. The singular > intent of Recommendation 12 is to provide clarity around the process and > expectations of reasonable lawful disclosure in terms of making requests. > The recommendation attempts to ensure that expectations are set for how to > submit requests and in what fashion those requests will be handled once > received. The Recommendation does NOT assume that disclosure will be made > and, further, it isnâ€™t even contemplated how and on what basis a decision > for disclosing (or not) will be made. Those issues are to be dealt with in > Phase 2 and/or otherwise in a specific access discussion. > > Iâ€™m thus concerned that by explicitly limiting this recommendation to > civil requests will unfairly and unnecessarily remove the benefits of > process clarity for LEA. > > In light of these concerns, I strongly recommend the deletion of this > text. Thomasâ€™ legitimate concerns should then be taken up and addressed > in our Phase 2 work. > > Thanks! > > Ashley > 202 482 0298 > > *From:* Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> *On Behalf Of * > Caitlin Tubergen > *Sent:* Thursday, February 7, 2019 3:26 PM > *To:* gnso-epdp-team(a)icann.org > *Subject:* [Gnso-epdp-team] For your review: updated recommendations 10, > 11, 12 > > Dear EPDP Team: > > Attached, please find the updated recommendations. The updates are the > result of todayâ€™s EPDP Team discussion > > As always, please feel free to flag any text that you believe does not > represent what the Team agreed to. > > Best regards, > > Marika, Berry, and Caitlin > > > > _______________________________________________ > Gnso-epdp-team mailing list > Gnso-epdp-team(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-epdp-team > > _______________________________________________ > Gnso-epdp-team mailing list > Gnso-epdp-team(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-epdp-team > > > _______________________________________________ > Gnso-epdp-team mailing list > Gnso-epdp-team(a)icann.org > https://mm.icann.org/mailman/listinfo/gnso-epdp-team > >

1 0

For your review: updated recommendations 10, 11, 12
by Caitlin Tubergen Feb. 9, 2019

Feb. 9, 2019

Dear EPDP Team: Attached, please find the updated recommendations. The updates are the result of today’s EPDP Team discussion As always, please feel free to flag any text that you believe does not represent what the Team agreed to. Best regards, Marika, Berry, and Caitlin

6 6

Updated version of Final Report posted for review
by Marika Konings Feb. 9, 2019

Feb. 9, 2019

Dear EPDP Team, Please note that the latest version of the EPDP Team Final Report has now been posted on the wiki for your review: https://community.icann.org/x/VZwWBg. Note that there are still a few recommendations that have not been completely finalized yet – we hope to do so at the latest by Monday’s EPDP Team meeting. These recommendations, which are bracketed in the report are: * Data retention – comments on the list have suggested that some clarifications may be needed * Reasonable access – discussion on the list in relation to the first sentence which has been bracketed * City field – awaiting legal guidance * Implementation bridge – language has been added to the recommendation to align with Thursday’s discussion to have the IRT convene informally as soon as possible after Council adoption of the recommendations Note that this version includes the updated data elements workbooks and tables (these do not appear in redline as the document could not handle that). Note that the Data Elements Team (DET) still needs to do an overall review, and provide an update about how the DET deliberated on the logic changes to reflect how Registries "collect" info which may need to be reflected in the report. Also note that as a result of new recommendations, the numbering has changed. You will find attached an overview of the new / old numbering. When referring to a recommendation, please make sure to add the topic as well as old & new numbering so everyone is clear what you are referring to. If there are any other issues that your group thinks need to be addressed during Monday’s meeting, please flag these as soon as possible. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

Phase II
by Arasteh Feb. 8, 2019

Feb. 8, 2019

Dear Kurt At different occasions and in various recommendations reference is made to Phase II OR to further review of the case in question. May I respectfully request you and the supporting secretariat to make a formal list in which these cases as outlined above are clearly mentioned and any course of action to be taken in the meantime until they are adequately addressed and approved Moreover, asI mentioned in my earlier message the timing of phase two and the associated transitional arrangements together with a clear indication the course of action and the associated procedure to be used in the meantime Regards Kavouss Sent from my iPhone

2 3