February 2019 - Gnso-epdp-team

FYI Motion For EPDP Final Report Approval
by Rafik Dammak Feb. 12, 2019

Feb. 12, 2019

hi all, Please find below the email sent to GNSO council to submit the motion for council consideration to approve the final report. You can find the latest version of the report posted in word and redline version on the wiki space https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report. Best Regards, Rafik ---------- Forwarded message --------- From: Rafik Dammak <rafik.dammak(a)gmail.com> Date: mar. 12 févr. 2019 à 08:10 Subject: Motion For EPDP Final Report Approval To: Council GNSO <council(a)gnso.icann.org> Hi all, I am glad to submit today the motion for the approval of EPDP Final Report Please find attached the motion and the draft final report. That version of the report is being currently reviewed by EPDP team members during this week - "quiet time". You will find below a cover letter from the EPDP leadership team giving more details in that regard. The motion may need to be amended in due time to be in line with the level of support for the recommendations in the Final Report. Best Regards, Rafik Dammak ------------------------------------------------------------------------------------------------- Dear Councillors: We are pleased to present this Draft Final EPDP Report Final Report of the Temporary Specification for gTLD Registration Data. The purpose in sending this draft Final Report is so that you can become acquainted with its layout and contents in advance of the release of the Final Report, expected on 20 February. It is hoped that this early release will facilitate your review of the final document. The EPDP Team is grateful to have two additional weeks for its deliberations.We are using the first week as a sort of “quiet period” to review the draft Final Report and have scheduled meetings for next week to reach conclusions on open issues. So we expect so substantive and non-substantive amendments to the report. With regard to the level of consensus, the report indicates those items where: - The Chair has indicated a consensus level and the EPDP Team has had the opportunity to review and comment on that designation - The Chair has indicated a level of Consensus and the EPDP Team has not yet had the opportunity to review and comment on that designation - The Chair has not made a designation yet because the issue is still open for some discussion. In many (nearly all) of the open recommendations, we are very close to final language but we have attempted to be conservative in the consensus designation and so have left some of these recommendations with no designation as of yet. The language you are reading in this report is close to final. Sections that still remain open are designated with brackets. The next steps for those sections are highlighted in yellow. We will also conduct a final Consensus call on the entire document when the report is final to identify any issues raised by the interplay between the Recommendations. Finally, and there will be more about this when the final report is delivered, this work product represents a significant sacrifice in time and effort by the working group members and, more significantly, a willingness by them to collaborate, cooperate, and compromise for our common goals. Best regards, EPDP Leadership Team

3 2

Fwd: Rec. relating Effective date
by Kurt Pritz Feb. 12, 2019

Feb. 12, 2019

Reading this - I think Kavouss’ second suggestion makes sense. Kurt > Begin forwarded message: > > From: Arasteh <kavouss.arasteh(a)gmail.com> > Subject: Rec. relating Effective date > Date: February 11, 2019 at 10:25:53 PM PST > To: Kurt Pritz <kurt(a)kjpritz.com> > > Dear Kurt > Yesterday you forcefully defended Ashley , point who was absent > But you did nit support my proposals in two area > 1. The last sentence of the big para . > I suggested 5 time to add at the beginning g the following, > Should registries and registrars, under certains circumstance continue the expired Temp Spec..... > 2. Delete informally and leave it to GNSO /ICANN to take appropriate action as it is not up to Team to decide in their behalf > In both cases I had support > Pls then implement those in final version > I expect to test equally everybody > Regards > Kavouss > > > Sent from my iPhone

1 0

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Monday, 11 February 2019
by Andrea Glandon Feb. 12, 2019

Feb. 12, 2019

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Monday, 11 February 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/TJ0WBg MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-11feb19… AC Recording: https://participate.icann.org/p71sv86k16l/<https://participate.icann.org/p71sv86k16l/?OWASP_CSRFTOKEN=0b487d148c1a4460…> ** 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

List of closed vs outstanding items
by Anderson, Marc Feb. 11, 2019

Feb. 11, 2019

Kurt and team, First off apologies if this has already been sent or if I'm missing something obvious from the working group wiki, but I'm looking for a list of the items/recommendations that are considered closed and which ones are considered outstanding. I expect that the purposes from the Batch 1 consensus call and the recommendations from the Batch 2 consensus call are the closed items while everything else is outstanding and will be covered in a batch 3. If there is a consolidated list somewhere, that would be very helpful. Also, should we be working off the 8 February draft of the final report for the latest version of language for each recommendation? I expect we may see some changes as a result of today's discussion so how and where will those changes be tracked? Thank you, Marc Marc Anderson mcanderson(a)verisign.com<mailto:mcanderson@verisign.com> Cell: 571.521.9943 Office: 703.948.3404 12061 Bluemont Way, Reston, VA 20190 Verisign.com<http://www.verisign.com/>

3 2

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 19 February 2019 at 14:00 UTC
by Andrea Glandon Feb. 11, 2019

Feb. 11, 2019

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

1 0

For your review: updated Rec. 15 (data retention)
by Caitlin Tubergen Feb. 11, 2019

Feb. 11, 2019

Dear EPDP Team: Please find updated language for Recommendation 15 attached for your review. The edits, which come today’s EPDP meeting, appear in bold. Please note the attached language will be included in the pro forma version of the Final Report, which will be sent the GNSO Council today. The language, however, will be flagged as still open. Accordingly, if you believe this language does not accurately reflect today’s discussion, please note the issue and proposed edits over the list. Best regards, Marika, Berry, and Caitlin

1 0

Notes, action items - EPDP Meeting #45
by Caitlin Tubergen Feb. 11, 2019

Feb. 11, 2019

Dear All, Please find the notes and action items from today’s EPDP Meeting #45 below. Best regards, Marika, Berry, and Caitlin EPDP Meeting #45 11 February 2019 High-level Notes/Actions Support Staff to retain the CPH originally-proposed language for Recommendation 28 (the implementation bridge) into the Final Report. Any groups who wish to propose edits are asked to do so over the list during the quiet period, i.e., as soon as today and no later than Friday, 15 February. Support Staff to revert Recommendation 18 (reasonable requests for lawful disclosure) back to its previously-agreed form, i.e., delete proposal from Thomas, remove Ashley’s edits for the reasons described during the discussion. Any groups who wish to propose edits are asked to do so over the list during the quiet period, i.e., as soon as today and no later than Friday, 15 February. Support Staff to circulate updated text for Recommendation 15 (data retention) based on today’s discussion. EPDP Team to review the update Data Elements Workbook (Annex D) and flag any issues during the quiet period, i.e., no later than Friday, 15 February. During the quiet period, groups should flag any inconsistencies or errors in the Final Report. Please refrain from opening previously-closed issues. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ . 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) a. Review of outstanding action items b. Other updates, if applicable A version of the Final Report was sent to the Team on Friday. If any edits are needed due to today's meeting, the edits will be applied. The updated version will be sent to the Council for instructive purposes. EPDP Leadership will be presenting the Final Report during Thursday's Council meeting. Kurt will distribute the third consensus bundle following today's call. 3. Implementation Bridge – Recommendation #28 (30 minutes) a. Review proposed language for inclusion in the Final Report: The date of February 29, 2020 has been added. Also, the language allows implementation to begin as soon as possible. Team Feedback: Why are there no compliance penalties? Why is the term informally inserted before convened? This should be deleted. Interpretation: if the CP is not following the new policy, it must be following the Temp Spec. The flexibility of the language allows for an informal group to convene before Board consideration. Until 29 Feb, CP may operate under the new policy or under the Temp Spec. As long as the contracted party is operating under the one of those regimes, the contracted party will not be subject to compliance penalties. In the second paragraph, "will not be" should be changed to "may not be". The language is not meant to show preference to either regime. Perhaps the word expired should be inserted before Temp Spec. What does it mean to informally convene the IRT? The word "informally" was inserted to allow for earlier implementation. Rather than "shall be" it should be "shall be no later than". We should not refer to an expired policy in a policy recommendation. We should say "should not be subject to compliance penalties". The policy recommendations need to be translated into policy language, and that takes time, which is why there is a period for implementation. The language was the result of compromise, and any changes or additions will need to taken back to the list. The preference should be for the contracted parties to follow the policy, not the Temp Spec. The burden of why a contracted party cannot follow the new policy should be on them to provide. The standard practice is for contracted parties to apply status quo until the policy effective date, following the implementation of the policy. This language allows for contracted parties to adopt the new policy recommendations sooner. To require justification on the contracted parties, that would trigger a new procedure and accompanying burden and would likely not be accepted by the contracted parties. The goal is to move more quickly through defined processes for the benefit of contracted parties and the community. 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? The idea of the updated language (in bold) is to add color to the previous sentence re: LEA disclosure. It notes the team did not have enough time to review language for LEA requests. The language notes the above recommendation does not apply to LEA requests. The language does not exclude LEA requests but does not limit LEA requirements either. The language also clarifies where we are in the process, i.e., that more work needs to be done. Is the updated language compatible with concerns previously raised on the list? Yes, the updated language addresses the concerns addressed. LEAs should not be putting their eggs in the Rec. 18 basket. The language was not intended to put law enforcement in a worse position, so the updated text goes a long way in clarifying that. Why are we inserting this language here when we will grapple with these issues in Phase 2. The language could be misinterpreted. The insertion of this language is, therefore, unnecessary. When we talk about different criteria and processes, are we discussing within the WHOIS policy or outside of it? This language should be deleted. Change to reasonable requests for lawful disclosure, and the "reasonable request" language is described more below. Action: revert the wording back to "reasonable requests for lawful disclosure" - delete the quote at the end. Revert the language back the way it was and groups can note their disagreement (if any) during the quiet period. 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 The language to this recommendation was agreed with the following exceptions: paragraph 1 was edited per Marc A's proposed rewording. Also, Marc A. noted the language in para 3 was slightly confusing, so leadership and the support team attempted to clarify the language. The EPDP team should not invite community members. Paragraph 1 is clearer now that additional information will be gathered to inform Phase 2. Re: para 2 - it's unclear what contractual language is maintained and what is not. Re: para 3 - the new language recognizes that there is an existing waiver process and that it should be looked at. The language is trending in the right direction, but registrars should weigh in on para. 2. Thought the group decided on a general retention period of one year - not just for the TDRP. In essence, para. 2 is fine, but the point about the period may need to be longer than one year to get over the hiatus in the TDRP, for example. Possibly an 18-month period could resolve the issue Alan G. has raised. The recommendation in para. 3 that the waiver procedure applies to period less than ICANN requirements and not that is more. Consider adding a footnote about the TDRP. In the first bullet point: it should say different retention periods. For second paragraph - 1 year period beyond the registration based on the TDRP, and another six months to implement the deletion. The reference to "shorter periods" needs more clarification. The Team could consider adding a footnote about the details being worked out in Phase 2. Action: change period to 18 months (insert Thomas' language) 2 changes: 1. 18 months. 2. in para 1, change different retention purposes to different retention periods. 3. add footnote about phase 2 Action: Support Staff to circulate revised language following this call. 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 Thank you to Berry for all of the work involved in this. When we are looking at the data elements, we are looking at it per purpose. Significant work to document the purposes across data elements and it make it more user-friendly. The Team must now review the tables for understanding and accuracy. b. Further updates expected in relation to Final Report c. Questions / Comments? 7. Next Steps (10 minutes) Silent review should be used for pointing out errors or inconsistencies Draft report will be forwarded to the GNSO Council and will be discussed during the Council Based on flagged issues, the Team may hold meeting next week (placeholder invites have already been sent out). Report will be sent on 20 Feb to Council. Question: what words will be used when full consensus is not designated? Deadline for feedback on the Final Report is EOD Friday, 15 February. 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

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

Feb. 11, 2019

I agree. We do not yet fully understand the process for non-EU LEA access to data and Process 2 had no such limitations. Alan 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

7 10

Re: [Gnso-epdp-team] [Ext] RE: Proposed path for additional topics flagged
by Marika Konings Feb. 10, 2019

Feb. 10, 2019

Hi Marc, As there did not appear to be support for the changes proposed, the language will remain as is in the next iteration of the Final Report, but with the addition as proposed by the RrSG: The 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 in the RDS for the sponsoring registrar. Best regards, Caitlin, Berry and Marika From: "Anderson, Marc" <mcanderson(a)verisign.com> Date: Friday, February 8, 2019 at 13:30 To: Marika Konings <marika.konings(a)icann.org>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] RE: [Gnso-epdp-team] Proposed path for additional topics flagged I understand that staff is working on a new draft of the final report and so I expect we will get to see the latest version of the language for some, if not all of these shortly. That said, I want to flag one item. On item #4 (new recommendation – consent) – this document requests input on the mailing list followed by discussion if needed, however this recommendation was also a part of the batch 2 consensus call (which closed yesterday). Can we get a clarification on the state and status of this recommendation? Best, Marc From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> On Behalf Of Marika Konings Sent: Wednesday, February 06, 2019 1:36 PM To: gnso-epdp-team(a)icann.org Subject: [EXTERNAL] Re: [Gnso-epdp-team] Proposed path for additional topics flagged Please use the attached version which has the numbering included as referenced below. Apologies for the inconvenience, 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 Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> Date: Wednesday, February 6, 2019 at 11:22 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: [Gnso-epdp-team] Proposed path for additional topics flagged 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…>.

3 2

Recommendation 13 - Responsibilities of the Parties - email list discussion
by Kurt Pritz Feb. 10, 2019

Feb. 10, 2019

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 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

Re: [Gnso-epdp-team] Proposed path for additional topics flagged
by Marika Konings Feb. 8, 2019

Feb. 8, 2019

Please use the attached version which has the numbering included as referenced below. Apologies for the inconvenience, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Wednesday, February 6, 2019 at 11:22 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed path for additional topics flagged 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…>.

3 2

REMINDER: Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Monday, 11 February 2019 at 14:00 UTC
by Terri Agnew Feb. 8, 2019

Feb. 8, 2019

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

1 0

EPDP Consensus Call #2
by Kurt Pritz Feb. 8, 2019

Feb. 8, 2019

Hi Everyone: I am trying to keep up with the comments on the list so am gaining an appreciation for the position of you members of the team. Thanks for your involvement and the tone in your emails - obviously trying to find a path to finishing each of these recommendations. Nonetheless, I am delivering the second set of Recommendations in this consensus call process. Please note that, given the recent discussion on the email list, I have moved three of the Recommendations out of “Bundle 2,” which includes those Recommendations where discussion is considered completed. These Recommendations are now in Bundle 3 and in blue font. 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 #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 #6 - Escrow Providers 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 Recommendation #8 - Redaction Recommendation #13 - Controller Agreement Recommendation #7 - Contractual Compliance On this second set, please revert to me by the end of Thursday 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. If we can in someway extend these deadlines (and we are working to do that), I will let you know. Thank you for your attention on this and all else. Sincerely, Kurt

5 5

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

Feb. 7, 2019

No it does not. "Any contact information" might be Tech contact which is not a contact for the RNH itself. And it does not require there to be both telephone and e-mail. And that is the current minimum contact requirement. My version says that and also gives contracted parties full flexibility in implementing. Immediately following this meeting, I will be driving all day and will be out of contact. Alan At 07/02/2019 09:25 AM, Ayden Férdeline wrote: Okay, thanks Alan. "Published" was the wrong word for me to use then in my explanation, because you are right that we are talking about collection as well, but I still think the language that I proposed addresses both of our concerns? Ayden ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, February 7, 2019 9:13 AM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: At 07/02/2019 08:41 AM, Ayden FÃ©rdeline wrote: Hi Alan G., I hope to find a compromise here so that we can move forward, but I find your language to be too prescriptive. I don't understand why we'd call out "voice telephone and email contact information"? I used those terms because they are the ones that are used in the RAA and my understanding was that being specific as to which fields we are talking about. Surely if these are fields that are mandatory for a registrant to provide, in asking for full contact information (of mandatory fields), they would be covered? No, that is the entire point. In the 2009 RAA, there were not considered mandatory. That is why they may be missing as stated in the opening clause. I also have concerns with the sentence, "Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder." I believe this sentence is redundant. It is not redundant and not prescriptive. It is telling registrars (and registrants) that they have complete flexibility on how they treat these fileds once our policy is active. As it stands, we have another recommendation that allows a RNH to request that additional data elements be published. This has nothing to do with publishing. It is about whether the fields exist at all and whether they need to be collected. And it is about protecting registrant in the case of a Rr/Ry failure. Alan May I suggest the following language: Redline: Recognizing that in the case of some existing registrations, there may be an Administrative Contact information but no or incomplete Registered Name Holder contact information, the EPDP team recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains the Registered Name Holder voice telephone and e-mail contact information. Prior to the Administrative Contact fields being eliminated, Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder. Clean: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no or incomplete Registered Name Holder contact information, the EPDP team recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains contact information. Best wishes, Ayden â€�â��â��â��â��â�144;â€�â�� Original Message â��â��#144;â��â��â��â��â�� On Wednesday, February 6, 2019 10:59 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: Hi Ayden, The issue is not collecting and maintaining. It would be foolish for registrars to have to collect Admin data post-EDPD-policy implementation if the intent is to get rid of the field. All of those registrations where they might collect Admin data, we know that the Registrant contact details are mandatory (since they would be subject to 2013 rules). The issue is we cannot eliminate the field from the database structure (and eliminate disclosing it when applicable) until we make sure there are no empty registrant contact fields. Moreover, as I pointed out in the my previous message, a registration might include Technical contact info but that is not sufficient to replace Registrant/Admin. Here is something that will work. "Recognizing that in the case of some existing registrations, there may be Administrative Contact information but no or incomplete Registered Name Holder contact information, the EPDP recommends that prior to eliminating Administrative Contact fields, all Registrars must ensure that each registration contains the Registered Name Holder voice telephone and e-mail contact information. Prior to the Administrative Contact fields being eliminated, Registrars may, at their option, either not collect Administrative Contact fields, or collect them at the option of the Registered Name Holder." This would ensure that we do not eliminate the Admin fields until we can ensure that every registration (and particularly every registration in the escrow files) has SOME contact info for someone responsible for the registration. That protects the registrant, but does not required Registrars to keep collecting data that is being phased out. The list of fields to be collected would have to note this recommendation instead of just omitting the Admin fields. Alan At 06/02/2019 05:57 PM, Ayden FÃƒÂ©rdeline wrote: Hi Alan, I have tried to strike a balance between the text I shared earlier and the comments you have raised here. Here is what I have come up with: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to eliminating the collection and maintenance of the current Administrative Contact field, the Registrar MUST ensure that each registration will contain contact information. Can you live with this? I have removed the reference to "some contact", which you found vague, and "name", because you noted this was unnecessary given the RAA. However I have still deleted the last sentence, because I do think it is redundant. Best wishes, Ayden Ã¢��Ã¢��44;Ã¢��Ã¢��Ã¢��Ã¢��Ã¢�4;Ã¢€� Original Message Ã¢��Ã¢�4;Ã¢â�â‚¬�Ã¢��Ã¢��Ã¢��Ã¢�Ã¢�Ã¢â�¬� On Wednesday, y, February 6, 2019 5:27 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca> wrote: Now that I have posting rights again: Two comments on "... will contain the name and contact information of some contact" - It is not really necessary to mention "name" since the 2009 RAA did require a Name field for the Registrant. - "some contact" is too wide, since we are still requiring (optionally) a technical contact which may not be the entity responsible for the registration (for instance it my be the hosting provider). Since we are also eliminating the Billing fields, the Registrant is the only remaining non-technical contact, so replacing the phrase with: "... will contain full Registrant Contact information" That also eliminates the need for the e.g. Regarding Ayden's recommendation to eliminate the final sentence, I do not agree. We need to make it clear that ensuring the Registrant contact information being present is a gating requirement to elimination of the Admin fields. We could in fact stop collection admin contact details before that, because for all new or changing registrations the 2013 rules apply which ensures Registrant data. Alan At 06/02/2019 06:58 AM, Ayden FÃƒÆ’Ã�Â©rdeline wrote: Thanks, Marika. I have some suggested edits, which are stylistic and not substantive: Redline: Recognizing that in the cases of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to in eliminating the collection and maintenance of the current Aadministrative Ccontact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact., e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. Clean: Recognizing that in the case of some existing registrations, there may be an Administrative Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, prior to eliminating the collection and maintenance of the current Administrative Contact field, the Registrar MUST ensure that each registration will contain the name and contact information of some contact. Best wishes, Ayden FÃƒÆ’Ã�Â©rdeline > ÃƒÂ¢��ÃƒÂ¢��ÃƒÂ¢�¢€�ÃƒÂ¢��¬�ÃƒÂ¢Ã¢144;ÃƒÂ¢Ã�¢�Â¬�ÃƒÂ¢��ÃƒÂ¢�� Ori; Ori; Original Message ÃƒÂ¢�ÃƒÂ¢��ÃƒÂ¢�ÃƒÂ¢�ÃƒÂ¢��ÃƒÂ¢��Ã¢�Â¢‚Â¬�ÃƒÂ¢�� On Tuesday, Febrruary 5, 2019 66:18 PM, Marika Konings <marika.konings(a)icann.org> wrote: In line with the comments made, would the following work for inclusion in the Final Report: New Recommendation: Recognizing that in the cases of some registrations, there may be an Admin Contact but no Registered Name Holder or any other contact, the EPDP Team recommends that, in eliminating the collection and maintenance of the administrative contact, the Registrar MUST ensure that each registration will contain the name and contact information of some contact, e.g., the Registered Name Holder. This will need to happen before the administrative contact is eliminated. If you have any concerns about this proposed language, please share this with the mailing list by Wednesday 6 February COB. Best regards, Caitlin, Berry and Marika From: Alan Greenberg <alan.greenberg(a)mcgill.ca> Date: Monday, February 4, 2019 at 18:20 To: Kurt Pritz <kurt(a)kjpritz.com> Cc: Marika Konings <marika.konings(a)icann.org>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] FW: Response from ICANN Compliance re. registrations under the 2009 RAA Kurt, that would be fine. But that is not "elimination of the field". The registrar "ensuring" must happen before the field disappears. We have an escrow program to protect registrants against failures in registrars and registries. The escrow data going forward must always include contact info. I am just about to name an alternate for tomorrow and will lose posting privileges to this list. Alan At 04/02/2019 07:07 PM, Kurt Pritz wrote: Thanks for this Alan: Might another approach be to write into the policy something to the effect that, ÃƒÆ’Ã�Â¢��Recognizing thatat iat in thehe cases of s some registrations there is an ÃƒÆ’Ã�Â¢��Adminin ContactÃƒÆ’Ã�Â¢�but n€but no Registered Name ame Holder or any otherr contact, it is required that, in the eliminating the collection and maintenance of the administrative contact, the registrar will ensure that each registration will contain the name and contact information of some contact, e.g., the registered name holder.ÃƒÆ’Ã�Â¢�� Something like that to let eaach registrar manage its own situation and also to give compliance a way to monitor registrations to ensure that there is contact information. Best regards, Kurt On Feb 4, 2019, at 3:58 PM, Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Another alternative is to say that the Admin contacts are not to be collected for new, changed or transferred registrations (which are all subject to the 2013 RAA requirement for Registrant contact data) and that the fields will be eliminated once all registrars confirm that all of the registrations under their sponsorship have Registrant contact information. Alan At 04/02/2019 05:14 PM, Alan Greenberg wrote: I do not believe that we can eliminate the Admin contact information (as currently recommended) without a concrete idea of how many registrations might be left without contact information and just a note that implementation should investigate the potential impact. If that investigation (if it is even possible given the data that ICANN possesses) we to show that there are a substantive number of such registrations, what could they do? We know that registrars have resisted the requirement to take corrective action on registration (which is why the validation/verification requirements in the 2013 RAA only apply when there are changes). If we eliminate Admin fields, we must provide for ensuring that all registrations have contact information within a relatively short period of time. The easy fix given the timeline is to not eliminate the Admin fields. Alan At 04/02/2019 08:19 AM, Marika Konings wrote: Dear Alan G., all, In relation to the question regarding the 2009 RAA you formulated a while back, note that ICANN Org had already provided a response: Alan GreenbergÃƒÆ’Ã�â��Ãƒ�Ã�Â¢Ã‚Â¢��s Questistion: br> < The EPDP is requesting that ICANN Org confirm that all registrars are now operating under the 2013 RAA. The EPDP is requesting that ICANN Org provide its interpretation of the requirement under the RAA Data retention Specification 1.1 whether registrars, as part of their adoption of the 2013 RAA, are required to ensure that Registrant contact email and telephone fields are completed, or whether the phrase "shall maintain that information" (which was validly allowed to be blank at registration time) allows them to preserve any empty Registrant contact fields. If the former, is Contractual Compliance taking any action to ensure that registrars fulfill this obligation? ICANN org Compliance Response: Registrars are not required to collect additional contact information for 2009 Registrar Accreditation Agreement (RAA) registrations. However, registrars may be required to update existing contact information for 2009 RAA registrations when there is a triggering event under the 2013 RAA that may require them to do so (e.g., the domain name is an inbound transfer, the registrant changes, there is information to suggest the current contact information is incorrect). This response is also posted here: https://community.icann.org/x/ahppBQ. Please let us know if this does not sufficiently address your question. In order to ensure this issue is not overlooked during the implementation phase, would it be helpful to add a sentence along the following lines in the implementation part of the report: ÃƒÆ’Ã�â��Ãƒ�Ã�Â¢��‚Â¢€œAs parart of the implplplplementation, consideration needs toto be given to the potential impact of these policy recommendations on legacy registrations that without additional mitigation could end up with no contact information if the administrative contact is the only information currently available (this could be the case for a limited number of registrations that are still under the 2009 Registrar Accreditation Agreement)ÃƒÆ’Ã�â��Ã™Ãƒ�Ã�Â¢��? ; > br> > Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support � GNSO, Internet Corporation fforr Asssiggned Namees and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<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

6 7

Notes and action items - EPDP Team Meeting #44
by Caitlin Tubergen Feb. 7, 2019

Feb. 7, 2019

Dear All, Please find the notes and action items from today’s EPDP Team call. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting #43 Wednesday, 6 February 2019 Notes and Action Items High-level Notes/Action EPDP Team to review the table of outstanding items, which was circulated to the list. yesterday. Please note the Support and Leadership teams’ proposed path forward and please flag the options you cannot accept. Support Team to update Recommendations 10, 11, and 12 (Email, Data Retention and Reasonable Access, respectively) to account for today’s discussion and circulate the updated text to the list. Support Team to circulate updated Final Report draft tomorrow, Friday, 8 February. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ . Proposed Agenda: 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) a. Review of outstanding action items b. Other updates, if applicable Please review the table sent yesterday, which outlines outstanding issues raised by team members and includes proposed paths forward, suggested by the leadership team re: outstanding issues raised and the proposed path forward from the leadership team The Support Team will send an updated version of the Final Report tomorrow 3. Implementation Bridge Per last week’s action item, CPH to present language/approach for implementation bridge discussion a. CPH to present updated language proposal CPH Proposed Language: The EPDP Team recommends that the effective date of the gTLD Registration Data Policy shall be [DATE]. 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 [DATE], 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 inquiry specifically related to those measures. When would the date be filled in? The date could be up for discussion. The initial placeholder was January 1, 2020. The thinking behind this proposal is that it lightweight and accounts for companies who are able to comply sooner and those who may need extra time. It also allows Compliance to have an enforcement mechanism. Some contracted parties were concerned with this language, so this represents a compromise. The proposed language looks good, though it will be important to figure out the date. A date may also need to be inserted into the last sentence. How would a third party know which regime the contracted party chooses to operate under? It may be helpful to have a defined term for the date, such as consensus policy date. Agree that there needs to be some signal as to which regime the contracted party is operating under. Need more clarification on the last sentence- what does "will not be subject to compliance inquiry" mean? In the last sentence, suggest changing inquiry to action. The group can put a date on the table - there is likely not time for an IRT. January 1, 2020 was the first idea thrown out. Re: the term compliance inquiry, that should be changed - perhaps compliance sanction could be considered. Should there be a date in the last sentence? Yes, that is OK. Re: which regime a CP is operating under? That will be more difficult. Perhaps the date should not be January 1, as it's difficult to finalize changes over a holiday. CPs could let ICANN know which regime they're operating under, and ICANN could publish this. The Team could put in a target date. The IRT does not begin until the Board adopts the recommendations. The reason a target date is proposed is b/c you cannot fix yourself to a certain date in the event the implementation is ready. The effective date can only be confirmed once implementation is completed. Action: contracted parties to consider a target date. Could the group form a mirrored group similar to the IRT that could start sooner than the IRT? Disagree with the term target date. b. Discuss proposal c. Confirmation of agreement reached or next steps to come to agreement 4. Recommendation #12 - Reasonable Access (30 minutes) a. Review revised proposal b. Discuss revised proposal Having an auditable system is necessary; it is not about penalizing the contracted parties. The objective is to allow a trusted system to exist. This looks like the focus has been shifted to the request itself rather than the process for dealing with the request. The onus and burden is flipped - the onus is on the requestor to make a reasonable request. The trusted system we are working with is the GDPR. Thomas' added sentence may be too restrictive. What about out of jx requests? The reason the clarification was inserted was not to deter law enforcement. 6(1)(f) allows for the disclosure of data if you perform the balancing test. 6(1)(f) cannot be used by public authorities in performing their core functions. It's not appropriate for us to establish criteria for law enforcement. Perhaps this sentence could be preserved but not included as the "headline". The first bullet re: two business days to determine if something is reasonable and lawful may be too short. Perhaps it can be two business days to acknowledge receipt. This would stay in place unless replaced by another policy. This is not intended to be the last word on access to data. This is a placeholder to sort out procedural responsibility for non-law enforcement actors. Thomas' language should be included at the top. The wording changes include: Amr's comments about 2-day response period and that this is acknowledgement - wording in chat has been accepted. Response time for acknowledging receipt of disclosure requests" seems fine to me. This would cover both disclosure requests that are reasonable/lawful, and those that aren't. I suspect it would be too soon to determine which bucket the disclosure requests falls into within 2 days after it's submitted. Ashley's wording seems to have gained acceptance. c. Confirmation of agreement reached or next steps to come to agreement 5. Recommendation #10 – Email Communication a. Review revised proposal b. Discuss revised proposal Action: support team to specify RAA requirement to address SSAC's concern in the text. In reference to the "must not identify" would provide that registrars could provide an option that redacted information be displayed. If possible or if practical, bounced messages should be included in the log. Registrars may log bounced emails, but they do not act on it. Add something like 'unless as per recommendation X, the registrant has provided consent for the publication of the email address'? Bounced emails should be separated from the webform. Even though the RAA requires the registrar to act, there is still a gap that the requestor does not know that the email is bounced. What kinds of action are the registrars are concerned with and address them? There may be a decent volume of requests depending on requests. Would not want to leave the impression that a large number of requests could be sent as long as the requests are valid. The logic being proposed is not thinking at scale. Registrars can be held to the requirements that they transmit a notification and keep records that the transmission was sent. Requiring a registrar to ensure that the transmission is received, read and acted upon is not practical. Prevent abuse - any process that allows registrars to block an IP address of the source if someone is abusing the system. It may be helpful to give readers an example of the abuse we are trying to address. Registrars cannot be expected to follow up on ever bounced message, but at the very least, they should be included in the log file. Concerned with the last sentence of Note 2. This follows the agreement reached in principle in Toronto - the Council may look into this email issue. Is it policy work, is it something else? It's an area where several groups have noted concerns, so this is designed to allow the Council to consider further. Request to separate the web form and the pseudonymized email address. The GNSO could consider working with technical arms to further address this issue. The note could be reworded to account for this. Potentially three things to add to the notes on the rec: (1) note SSAC's questions and how that is addressed; (2) a note that reasonable is meant to take reasonable steps to combat specific abuses - it's not a reason for ignoring legitimate requests; (3) unless as per recommendation X, the registrant has provided consent for the publication of the email address' c. Confirmation of agreement reached or next steps to come to agreement 6. Recommendation #11 – Data Retention a. Review revised proposal b. Discuss revised proposal ICANN Org sent a message with other known processes requiring retention The TDRP is not the longest-specified retention period, but rather well-justified period. It is for the controller to set the retention period, not someone else. A lot of work needs to be done with respect to what ICANN can claim. The term - as a matter of urgency should be added to paragraph 1. Is this recommendation intended to override the RAA data retention spec? The answer to does this replace the data retention specification? Yes. A registrar will not turn around and delete data, but the retention period in the contract does not have a reason – that is why the team underwent the analysis and noted the TDRP. Troubling that we are not clear on this at this point in time. With a good data map, you can determine who is in control of what. c. Confirmation of agreement reached or next steps to come to agreement 7. Review of additional topics raised from table (if time allows) 8. Wrap and confirm next meeting to be scheduled for Monday, 11 February 2019 at 14.00 UTC (5 minutes) a. Confirm action items b. Confirm questions for ICANN Org, if any

1 0