August 2018 - Gnso-epdp-team

Pro-forma Triage Report
by Kurt Pritz Aug. 21, 2018

Aug. 21, 2018

Hi Everyone: It was requested that we prepare a “pro forma” Triage Report for review and discussion - a version of the Triage report that might be submitted to the Council when the surveys are completed. This represents the work from the first survey, about 30% of the Temporary Specification. So you can see, it will be a fairly long report. The report includes an executive summary, our operating methodology, the summary table of inputs, the issue summaries that were created for each section and an appendix with all written comments. This report hasn’t had sufficient vetting on the leadership-support side yet but I wanted you to see the formatting and level of content as soon as possible. I apologize for the font size in the appendix. We will reorganize the table of all comments in some way that is readable in time for the actual publication. We will continue building this report and amending it in accordance with comments and discussion as we go along. Remember that this report is designed to help but not limit, prejudice or restrict our future work. So let’s spend time to make this good, but not perfect. I hope you find this helpful. Best regards, Kurt

5 8

Triage Report 1-3.pdf
by Kurt Pritz Aug. 18, 2018

Aug. 18, 2018

Hello Everyone: Attached Is the next version of the Triage Report that incorporates the results of surveys 1-3. In this version: 1) the edits (from comments) and additions are in blue; 2) I have not included the appendix, which is the spreadsheets that includes all of your comments. We hope to have a draft final version shortly after receiving your last surveys and plan to send it to the GNSO sometime during the upcoming week. Talk to your own soon, Kurt

1 0

22 August deliverable (Early Input)
by Kurt Pritz Aug. 16, 2018

Aug. 16, 2018

Hi Everyone: We had a question at the start of the meeting asking about a deliverable on 22 February. During the meeting, I stated that here was no deliverable for that date. I was technically correct but mostly wrong. Please recall the Early Input request. According to the requirements of the policy development process, each SO/AC/SG/C was sent a letter, allowing them to provide Early Input by 22 August. (See: https://go.icann.org/2w82uT7 <https://go.icann.org/2w82uT7> This is a distinct effort from the triage surveys we are currently reviewing. While a separate submission from each SG/AC/SG/C is not mandatory, each SO/AC/SG/C was afforded the opportunity to provide input, if they so choose. It is likely that, because you are on this team, you would have been the one tapped to take on this task. I hope this clarifies the matter for you and I apologize for the lapse in memory. Best regards, Kurt

3 4

Notes and action items from today's EPDP Team Meeting - 16 August 2018
by Caitlin Tubergen Aug. 16, 2018

Aug. 16, 2018

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 21 August, 13:00 UTC. Best regards, Marika, Berry, and Caitlin =============== EPDP Team Meeting - 16 August 2018 High-level Notes/Actions: Goran Marby, CEO of ICANN org, sent a letter to Kurt, asking to share any thoughts the EPDP Team might have regarding a process by which (1) ICANN org can share guidance they receive from the DPAs and European Data Protection Board with the EPDP Working Group; and (2) How the EPDP Working Group will provide input regarding access to ICANN org to use in our interactions with DPAs and European Data Protection Board to obtain legal guidance that will help guide the Working Group in its work. Kurt sent a draft response to the EPDP Team for review. If any members have suggested edits or additional thoughts, please submit them by 01:00 UTC on 17 August (COB Los Angeles time). EPDP Members should complete Part 4 of the Triage Survey by Sunday, 19 August by 19.00 UTC. Note that Part 4 of the Triage Survey includes Section 8 and Appendix C. Kurt distributed a pro-forma draft for the Triage report, which is the EPDP Team’s first deliverable to the GNSO Council. The Leadership Team will continue to populate the content of the Triage report, but EPDP Team Members are encouraged to provide comments now so that they can be incorporated and the report can be delivered shortly after we finish our Survey exercise. Today’s discussion concerned registrar and registry provided services, how GDPR blocked the provision of those services and the work-arounds that were successfully implemented. (“Successfully” meaning that all three services are in operation today.) There was a sense of the group that these functioning services (and the Temporary Specification description of them) should be left as is. There was an issue raised as to whether each of the personal datum transferred during these processes was necessary given the principle of minimization, and it was agreed that this should be raised during the access discussion. Questions for ICANN Org from the EPDP Team: Believing that ICANN org has its own GDPR implementation plan in place, it would be helpful for our group to understand the elements and implementation status of the plan so that the Team can draw comparisons to the EPDP Team’s work. The Council envisioned, via the EPDP Charter, to have direct participation of ICANN org liaisons, within the EPDP Team. As we leave the Triage and head into substantive detail, do the ICANN liaisons see a role or specific set of actions for ICANN supporting the team? All Action Items: Kurt sent a draft response to the EPDP Team for review. If any members have suggested edits or additional thoughts, please submit them by 01:00 UTC on 17 August (COB Los Angeles time). EPDP Members should complete Part 4 of the Triage Survey by Sunday, 19 August by 19.00 UTC. Note that Part 4 of the Triage Survey includes Section 8 and Appendix C. Kurt distributed the draft framework for the triage report, which is the EPDP Team’s first deliverable. The Leadership Team is still reviewing and populating the content of the triage report, but EPDP Team Members are welcome to provide comments or suggestions on the format at this stage. 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/2IpHBQ. 1. Roll Call & SOI Updates 2. Welcome and Updates from EPDP Team Chair · During today’s meeting, the team will be reviewing Appendices D, E, and G. · We received an email from Göran Marby, CEO of ICANN. Kurt’s draft response was sent to the EPDP Team for review. Action: If EPDP Team Members have comments on Kurt’s draft to Goran, please submit them by 01:00 UTC on 17 August (COB Los Angeles time) – Kurt would like to respond by COB Los Angeles time today. · Draft of first section of triage report – the triage report is a requirement from the charter. The first draft of the triage report was distributed to the team. If we have time at the end of the meeting, the plan is go through the draft triage report with you. Question for ICANN: ICANN, as other companies, may have an overall plan with milestones for GDPR implementation. The Temp Spec has an impact on ICANN Org as well as different departments inside ICANN. If ICANN has already reviewed its own work in certain areas or plans to do so, it would be helpful for our group to understand its thinking in relation to the EPDP’s work. · Part 4 of the Survey is due on Sunday. Due to a conflict, the GAC’s response will miss the due date but delivered prior to the discussion and so can be included in the report. · Re: Goran’s letter – Goran mentions how ICANN Org can share guidance from DPAs with the EPDP Working Group. Does Goran have more in mind that he would like share with us other than what is already posted on the blog? Curious how the EPDP Team can provide input to ICANN Org. Question for ICANN Org: The Council envisioned, via the Charter, to have direct participation of ICANN Org liaisons, within the EPDP Team. Is more needed here? · It seems ICANN is already posting everything it receives. It appears that ICANN Org is already creating an access model, so it may be useful to understand their work and our remit. · Is a report expected from each SO/AC/SG/C by 21 August? · No, in lieu of separate reports from each group, please complete Part 4 of the Survey, and we will continue to build the triage report from that. Correction: after the meeting it was determined that the question referred to the request for Early Input that was sent to community leaders. While not directly on the task list of this Team, the Team members should be aware of the opportunity and the 22 Aug due date. · What is ICANN’s plan with the access model? Will this be implemented, is there a timeline for implementation? Does this mean EPDP Team will not have input? 3. Summary of responses to EPDP Input Survey Part 3 - Results for Appendix D: Uniform Rapid Suspension, Appendix E: Uniform Domain Name Dispute Resolution Policy, Appendix G: Supplemental Procedures to the Transfer Policy · There seems to be agreement on many of these sections, but some serious issues were also raised. 4. Substantive Discussion of Temporary Specification: Part 3 of the Survey can be found at https://www.surveymonkey.com/r/7PWQPP7 Appendix D: Uniform Rapid Suspension Issue Summary: The majority of groups support the text of Appendix D as written or deferred to registrars. Otherwise, the following questions/issues were raised: Should the language "participate in another mechanism" in Section 1.1 be clarified or eliminated? Does the language in section 1.2 (for thin registries) create possible incompatibilities with existing URS procedures? There is currently no processing agreement with an Asian URS providers in place. Is this an issue for the EPDP Team? Does the term "contact details" in Section 2 of Annex D need to be further defined? Should language allowing the Complainant to file an amended URS Complaint once it receives registration data be included in Section 2? Is the review of Appendix D more appropriately addressed by the RPM PDP, and timing, i.e., should the review of Appendix D be deferred until after the EPDP Team deliberates on the access model/framework? Does Section 2 of Appendix D need additional safeguards to ensure against abuse, i.e., a complainant filing "doe complaints" in an attempt to get registration data? EPDP Team feedback: · Registrars are OK with this as the URS is working. Registrars have experience with ccTLDs, which publish no personal information in WHOIS. On question 3 regarding processing agreements, this also includes URS and UDRP providers. This, however, is not an issue for the EPDP Team, but could be addressed somewhere else in ICANN. · The changes made to the URS in the Temporary Specification allow the BC to use the mechanisms ICANN put in place. Waiting for another forum to decide this could result in issues, and if the URS no longer works, it will be a big problem for the BC. · With respect to incompatibilities, the existence of Appendix D allows the URS to go forward in spite of redacted WHOIS. We may have to look at Appendix D because the language is not bad, but it may cause issue with URS procedures, and the question is – should the EPDP Team fix it, or should the RPM Working Group deal with this? Specifically, with respect to “doe complaints”, one issue is under URS procedures, only the Complainant can amend a complaint, not the provider, but the language in the Temp Spec contradicts this. However, the RySG did not have major issues with the wording in Appendix D or E. Tweaks may be needed, but this should happen in the RPM Working Group, not the EPDP Team. · The RPM Working Group is a policy development group, and they are fashioning policy around the benefits and the cost, while the EPDP Team’s role is to make sure the procedure still works in light of the temp spec. · The RPM Working Group may be in a better position to understand the subtleties of the URS, but our job as the EPDP Team is to ensure the URS still works. If, for instance, the Team thinks it is reasonable to change a doe complaint, we should make these changes now. The problem with passing it off to the RPM Working Group is timing – they may not be in a position to make the changes right away, or conversely, they may finish before the EPDP Team has a chance to properly examine all of the issues. If there is a change needed to make these processes actually work, we should make the changes now. · Disagree with the coupling of the Temp Spec with issues related to URS. Not aware of any conflicts with the URS and the Temp Spec. Registries and Registrars seem to indicate there are no problems currently. There is not an access issue here that is not handled by existing procedures. · If contracted parties say this is OK as written, we can move along. If not, we need to fix that. · We could approach this in terms of what we know about the URS now. It would be helpful to be in the loop as to any changes the RPM Working Group foresees in terms of what the URS will look like in the future. As far as our task is concerned, there are a number of reasons why users may request access to registrant contact details. There are other features in the URS that allow complainants to file multiple complaints against the same registrant – the only way to do that would be to have all of the relevant contact details. Our task here is to determine what legitimate interests exist and whether they warrant access to contact details. We should keep an eye on what is happening with respect to the URS review, keeping in mind that it does need to be compliant with GDPR. This should be a two-way communication between the EPDP Team and the RPM WG. · RySG suggestion makes sense – make whatever tweaks we need to make sure that the URS works, knowing the RPM WG can fix it later. If we do not fix it, when the Temp Spec expires, the URS will not work. This language exists to ensure complainants can submit complaints even if they do not have access to the full data set. · From the registrar point of view, the URS and UDRP are working now. Trademark holders can file a complaint, and a balancing of interests takes place. In reference to the RPM WG, it is expected that what the group develops would be in line with data protection laws. · Does ICANN have an overall plan with compliance with GDPR? We should create a parking lot of issues that need to be resolved as a result of GDPR implementation, but that are not a part of the Temp Spec. If we have time, we can get to the issues in the parking lot, but if not, we can leave it to the next PDP. · There is a question regarding the data that is currently being shared as a part of URS, but we can take that up as part of the access discussion. · It is within the remit of the EPDP Team to discuss access to personal information due to URS and UDRP. · Reasonable access is part of this process, and it should not be parked. · It sounds like everyone agrees that the Temp Spec requires reasonable access, but it’s the EPDP Team’s job to define what reasonable access means. · Registrars are already required to provide reasonable access under the Temp Spec. The leap that some members are making in terms of having a policy to define what reasonable access means. Reasonable access is defined based on where the registrar is located is already happening under the Temp Spec. The EPDP Team has to answer gating questions before it can determine what uniform access will be. The sequence is clear in the charter. The question of reasonable access is an open question, not a question the EPDP Team must answer. · All GAC “yes” answers should be read as a qualified yes, since additional text is provided with each yes. We should discuss unified access at a later date, so we should not completely dissociate this issue. · All Members have different opinions on what reasonable is, and it may vary by jurisdiction. The difference in when we are talking about the URS/UDRP – if what we are doing in this group causes ICANN Consensus Policies to break, we need to address this so that the policies continue to be operable. · If members are going to state that access is not an appropriate topic, we should be careful about the words we use. Some are saying the words reasonable access, and others are saying we do not have to talk about access at all. These disconnects in the conversation are resulting in overhead and confusion. Appendix E: Uniform Domain Name Dispute Resolution Policy Issue Summary: The majority of groups support the text of Appendix E as written. Otherwise, the following questions/issues were raised: Should the language "participate in another mechanism" in Section 1.1 be clarified or eliminated? Does the language in section 1.2 create possible incompatibilities with existing UDRP procedures? Does Section 2 of Appendix E require additional safeguards to ensure against abuse, i.e., a complainant filing "doe complaints" in an attempt to get registration data? Should language allowing the Complainant to file an amended UDRP Complaint following receipt of registration data be included in Section 2 of Appendix E? Is the EPDP Team's review of Appendix E more appropriately addressed by the RPM PDP, and timing, i.e., should the review of Appendix E be deferred until after the EPDP Team deliberates on the access model/framework? EPDP Team Feedback: · All participants in the GAC have questions about what “participate in another mechanism” means. · We need more clarification on what “participate in another mechanism” means. · It seems to mean if the RPMs define a new mechanism or another mechanism is proven necessary, this language would allow for the new mechanism. Appendix G: Supplemental Procedures to the Transfer Policy Issue Summary: The following concerns/issues were flagged by groups not in support of the language as written: Does the revised transfer process create new security risks and vulnerabilities such as domain name theft and hijacking, and if so, should the EPDP Team address this as part of the work of this EPDP? Should this Team's consideration be affected by existing efforts to replace/modify the Transfer Policy? Does Section 1.2 of Appendix G, imposing redundant processes on the registrant, overly denigrate the user experience? Is there an alternative? Should the language "to be offered" be removed from Section 1 to avoid confusion? EPDP Team Feedback: · If we rely on the auth-code alone, we are severing the relationship between the gaining registrar and the registrant. An easy solution could be for the gaining registrar to use EPP to communicate with the the losing registrar and ask for the relevant contact information. · The last time the Transfer Policy was discussed in a PDP on whether the FOA was still needed, the decision was it was still needed. The Temp Spec says it is no longer needed, which goes against the conscious decision made in the previous PDP. · What is in the Temp Spec that has been created by the Tech-Ops group, which is comprised of registrars and registries. The language in the Temp Spec was the proposed solution from this group and it is working pretty well. When there is a transfer, there is always an FOA from the Losing Registrar to the registrant. The difference is there is no longer an incoming FOA (the FOA from the Gaining Registrar to the registrant). Regarding security, registrars do see an issue, and it is an old issue. WHOIS is redacted now and it becomes more complex to deal with unauthorized transfers, and this problem is amplified in the revised transfer process. The registrar suggestion is to deal with this outside of this EPDP because it is a very complex problem. · The RrSG put forward many comments and ideas, but the Registrar EPDP Team Members decided to include high-level comments only because registrars believe the Transfer Policy needs to be reviewed, but the review is not within the remit of the EPDP Team. What is in the Temp Spec is working for now, but we would support a review of the entire Transfer Policy at a later time. · If there is always an FOA, why do we need 1.1? · The Losing Registrar FOA is still required, but the FOA is no longer required from the Gaining Registrar. Transfers now work like this: https://www.realtimeregister.com/blog/post-gdpr-gtld-transfers/ · This is an important issue – preventing unauthorized hijacking is deeply important; however, this issue, per the registrars, could be discussed as part of Transfer Policy PDP, not within this EPDP Team. The Transfer Policy issue should be added to the “parking lot”. It is not clear if the Temp Spec is causing any notable problems that the EPDP Team needs to fix. · Transfer of information is very important, and it should be part of this Temp Spec. Unauthorized transfers and security issues should be addressed in this EPDP, and we should not dissociate these issues. · This Transfer Policy is currently working and for purposes of the temporary specification, if there are security concerns with how the Transfer Policy is working, the EPDP Team could examine those when we finish reviewing the Temp Spec. · Now that WHOIS from most registrars is redacted, it makes it harder for criminals to hack accounts since information is no longer displayed. While there are no detailed numbers to share right now, it is likely that domain theft has actually gone down under the revised transfer policy. · If numbers regarding reduced domain theft/hijacking could be provided in the future, it would be very useful for our purposes. · Does this updated process make transfers harder or easier on registrants? · From the registrar perspective, the updated process has resulted in less complaints, the transfer process got easier, and the resellers are happier. 4. Confirmation of action items and questions for ICANN Org, if any Action: Kurt sent a draft response to the EPDP Team for review. If any members have suggested edits or additional thoughts, please submit them by 01:00 UTC on 17 August (COB Los Angeles time). Action: EPDP Members should complete Part 4 of the Triage Survey by Sunday, 19 August by 19.00 UTC. Note that Part 4 of the Triage Survey includes Section 8 and Appendix C. Action: Kurt distributed the draft framework for the triage report, which is the EPDP Team’s first deliverable. The Leadership Team is still reviewing and populating the content of the triage report, but EPDP Team Members are welcome to provide comments or suggestions on the format at this stage. Questions for ICANN Org: If ICANN has already reviewed its own work in certain areas or plans to do so with respect to GDPR compliance implementation, it would be helpful for our group to understand its thinking in relation to the EPDP’s work. The Council envisioned, via the Charter, to have direct participation of ICANN Org liaisons, within the EPDP Team. Is more needed with respect to the EPDP Team’s engagement with ICANN Org? 5. Wrap and confirm next meeting to be scheduled for Tuesday 21 August at 13.00 UTC. (Part 4 Survey results due Sunday, 19 August by 19.00 UTC)

1 0

Recordings, attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Thursday, 16 August 2018
by Andrea Glandon Aug. 16, 2018

Aug. 16, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Thursday, 16 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/owtpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-16aug18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p9q7tzi7okf/<https://participate.icann.org/p9q7tzi7okf/?OWASP_CSRFTOKEN=e491c17805cccb72…> ** 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 [community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> Thank you. Kind Regards, Andrea Glandon

1 0

Congradulations
by Kavouss Arasteh Aug. 16, 2018

Aug. 16, 2018

Dear Kurt Dear ICANN Staff Support, Marika and other memeber of supporting team I have briefly reviewed your draft to be further reviewed by the Team before being sent to GNSO Council Being professional for more than 4 decade, I admire the devotion, skills ,attention, preciseness and valuable draft. ,in particular, conciseness of the Draft being prepared in such a short time I wish to formally and sincerely express my appreciation AND PROFOUND GRATITUDES which I am sure will be shared by other Members of the EPDP Team to yourself and the ICANN supporting Team for such a helpful and constructive draft Congratulations Kavouss

1 0

Re: [Gnso-epdp-team] FW: Fwd: Coordination between ICANN org and EPDP
by Arnaud WITTERSHEIM Aug. 16, 2018

Aug. 16, 2018

Thanks Kristina for the proposal to allow alternates to access the AC Room. It greatly helps to follow more easily the exchanges and thus be up to date information in the case where the alternate must replace a member. I was able to resume the history of the last exchanges and am therefore ready to follow the meeting later. Have a nice day Arnaud Le 16/08/2018 à 05:35, 'Rosette, Kristina' via ePDP team a écrit : > > FYI. Not sure of the timing of Kurt’s response so recommend that any > comments/proposed changes be provided to Alan, Marc and Arnaud > tomorrow. (Arnaud is acting as Member on my behalf until Monday.) > > K > > *From:*Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] *On > Behalf Of *Kurt Pritz > *Sent:* Wednesday, August 15, 2018 5:14 PM > *To:* GNSO EPDP <gnso-epdp-team(a)icann.org> > *Subject:* [Gnso-epdp-team] Fwd: Coordination between ICANN org and EPDP > > Hi Everyone: > > Yesterday, I received the email below from Göran Marby. I wanted those > of you who are interested to see and have the ability to comment on my > draft reply, which is immediately below Göran’s letter. > > The reply will be from me so I might not include all comments - not > necessarily because I disagree with the substance but it might be > because of tone, timing or level of detail. > > On the other hand, I’d be foolish not to consult with you as many of > you have been involved with ICANN efforts at correspondence and issue > resolution. If you have input, I will read and consider it carefully. > > I am not sure I want to make this a topic of discussion in tomorrow’s > meeting as finishing the triage is more important. I see the letter as > more of an invitation to start a dialogue where we can integrate > efforts, rather than pursue separate objectives. > > Best regards, > > Kurt > > > > Begin forwarded message: > > *From: *Goran Marby <goran.marby(a)icann.org > <mailto:goran.marby@icann.org>> > > *Subject: Coordination between ICANN org and EPDP* > > *Date: *August 14, 2018 at 8:17:13 AM PDT > > *To: *"rafik.dammak(a)gmail.com <mailto:rafik.dammak@gmail.com>" > <rafik.dammak(a)gmail.com <mailto:rafik.dammak@gmail.com>>, > "kurt(a)kjpritz.com <mailto:kurt@kjpritz.com>" <kurt(a)kjpritz.com > <mailto:kurt@kjpritz.com>> > > *Cc: *David Olive <david.olive(a)icann.org > <mailto:david.olive@icann.org>>, Theresa Swinehart > <theresa.swinehart(a)icann.org > <mailto:theresa.swinehart@icann.org>>, John Jeffrey > <john.jeffrey(a)icann.org <mailto:john.jeffrey@icann.org>>, "Akram > Atallah" <akram.atallah(a)icann.org > <mailto:akram.atallah@icann.org>>, Chris Disspain > <chris.disspain(a)board.icann.org > <mailto:chris.disspain@board.icann.org>>, > "leon.sanchez(a)board.icann.org > <mailto:leon.sanchez@board.icann.org>" > <leon.sanchez(a)board.icann.org > <mailto:leon.sanchez@board.icann.org>>, Cassia Oliveira > <cassia.oliveira(a)icann.org <mailto:cassia.oliveira@icann.org>> > > Kurt, > > Today, ICANN org held a call to provide community leaders with > updates regarding various GDPR activities. The slides and > recording of the call are available > athttps://www.icann.org/resources/pages/data-protection-meetings-2017-12-08…. > > On the call, a few community leaders reinforced the value of > coordination between ICANN org and the EPDP Working Group, > particularly around access model. To this end, please share with > us any thoughts you might have regarding a process by which (1) > ICANN org can share guidance we receive from the DPAs and European > Data Protection Board with the EPDP Working Group; and (2) How the > EPDP Working Group will provide input regarding access to ICANN > org to use in our interactions with DPAs and European Data > Protection Board to obtain legal guidance that will help guide the > Working Group in its work. As you know, we post all information we > receive through our blogs and engage with stakeholders, also > through communications we post whether through correspondence or > comments viagdpr(a)icann.org <mailto:gdpr@icann.org>. I look forward > to hearing your thoughts on how we can continue to strengthen our > work together toward the common goal of having an access model > that is guided by the law and supported by the community. > > Best regards, > > Göran Marby > > President & CEO ICANN > > +1(310) 578 8690 > > Cássia Oliveira > > Sr. Manager, Office of the President & CEO > > cassia.oliveira(a)icann.org <mailto:cassia.oliveira@icann.org> > > +1(310) 578 8656 > > Dear Goran: > > I have repeated some your email below so that there is a > clear connection between your questions and my responses. > > Today, ICANN org held a call to provide community leaders with updates > regarding various GDPR activities. The slides and recording of the > call are available at > https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en. > > On the call, a few community leaders reinforced the value of > coordination between ICANN org and the EPDP Working Group, > particularly around access model. To this end, please share with us > any thoughts you might have regarding a process by which: > > 1) ICANN org can share guidance we receive from the DPAs and > European Data Protection Board with the EPDP Working Group. > > a. Through its many recent actions: engaging with the ICANN > community, governments, the EDPB, and others, it is apparent that > ICANN is the midst of executing a plan to obtain certainty around the > various GDPR provisions. It would be instructive for the EPDP Team if > ICANN were to share its plan (or elements of it) so that the team can > anticipate the receipt (and timing) of new information. It would > also indicate where there is likely no additional information, i.e., > where the team would be left to draw conclusions based on the > information that is already available. This information would likely > cut down on the number of questions the ICANN Org receives from the team. > > We understand that the plan must have a degree of informality and be > flexible, with each step based upon the information received in the > step before it. However, where available, it would be instructive to > know the planned-for objectives, expected learnings, a set of ultimate > questions to be answered, planned inquiries, targets and so on. > > b. While ICANN has published each communication, the findings or > results of those communications have not been organized in anyway of > which we know. For example, observers of the back-and-forth between > the ICANN Org and the EDPB have offered conclusions that can be drawn > from these documents. However, no one has organized those conclusions > in a way that might become a rule set or set of guidelines for those > reviewing the Temporary Specification or creating an access model. > > > Coincidentally, in today’s EPDP meeting such a request was made: for > disclosure of all the communications with the EDPB and DPAs, the > staff commentary to those communications, and some organization of same. > > c. We also wish to hear of developments related to GDPR in other > industries, if available, such as: > > 1. what data processing protocols have been adopted > 2. what data processing protocols have been tested in courts > 3. what other privacy regimes are in works in other jurisdictions > 4. what data is available regarding: > > 1. the effects of GDPR on malfeasance detection, avoidance > 2. other positive or negative effects of GDPR > > > 2) How the EPDP Working Group will provide input regarding access > to ICANN org to use in our interactions with DPAs and European Data > Protection Board to obtain legal guidance that will help guide the > Working Group in its work. As you know, we post all information we > receive through our blogs and engage with stakeholders, also > through communications we post whether through correspondence or > comments via gdpr(a)icann.org <mailto:gdpr@icann.org>. > > a. The EPDP team’s third set of deliverables is to provide an, > “Initial Report and a Final Report regarding the EPDP Team’s > recommendations … for a System for Accredited Access to Non-Public > Registration Data.” Work on this could begin as early as > the completion and publication of the Initial Report on the > Temporary Specification. (The Team stays in close contact with the > GNSO Council leadership in pursuit of the deliverables to ensure the > spirit and letter of the EPDP Charter is followed.) > > b. While our current answer to this question is not yet finely > honed, it is likely that, from time to time, the EPDP Team will have > question regarding the constraints / opportunities imposed by the > GDPR. These questions might take the form of a proposed access model > (or elements of an access model). The EPDP Team will forward those to > ICANN, which, in turn, can test them against its own knowledge base, > with DPAs, with the EDPB, or elsewhere. > > c. As ICANN is a data controller involved in the collection, use > and disclosure of the same data that is the subject matter of this > Team’s work, it is expected that ICANN will work with the team on the > successor to the Temporary Specification and an access model. > > I hope you find this response helpful. The team is keen to continue an > active correspondence with ICANN in order to flesh out the > framework provided by GDPR with detailed clarifications, > implementation guidance and cases from other, similarly situated > industries that have faced many of these same issues. > > We also plan to remain in close communication with ICANN leaders > on this topic, through the ICANN-provided liaisons to the EPDP Team. > > Sincerely, > > -- > You received this message because you are subscribed to the Google > Groups "ePDP team" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to epdp-team+unsubscribe(a)googlegroups.com > <mailto:epdp-team+unsubscribe@googlegroups.com>. > To post to this group, send email to epdp-team(a)googlegroups.com > <mailto:epdp-team@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/epdp-team/c91e7ce1597342c995fecd08db01beb… > <https://groups.google.com/d/msgid/epdp-team/c91e7ce1597342c995fecd08db01beb…>. > For more options, visit https://groups.google.com/d/optout.

1 0

Slides + Part 3 Survey Results for 16 August EPDP Team Meeting
by Caitlin Tubergen Aug. 16, 2018

Aug. 16, 2018

Dear All, Please find a copy of the slides for our Thursday, 16 August EPDP Team meeting, as well as the results from Part 3 of the survey attached. Thank you. Best regards, Marika, Berry, and Caitlin From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Wednesday, August 15, 2018 at 10:29 AM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Agenda - EPDP Team Meeting #5 - 16 August at 13.00 UTC Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 16 August at 13.00 UTC. Note that the slides and other documents will follow later as survey responses have not all been received yet. Best regards, Caitlin, Berry and Marika EPDP Meeting #5 Agenda Thursday, 16 August 2018 Roll Call & SOI Updates Welcome and Updates from EPDP Team Chair Summary of responses to EPDP Input Survey Part 3 - Results for Appendix D: Uniform Rapid Suspension, Appendix E: Uniform Domain Name Dispute Resolution Policy, Appendix G: Supplemental Procedures to the Transfer Policy Substantive Discussion of Temporary Specification: Part 3 of the Survey can be found at https://www.surveymonkey.com/r/7PWQPP7 Appendix D: Uniform Rapid Suspension Appendix E: Uniform Domain Name Dispute Resolution Policy Appendix G: Supplemental Procedures to the Transfer Policy Confirmation of action items and questions for ICANN Org, if any Wrap and confirm next meeting to be scheduled for Tuesday 21 August at 13.00 UTC. (Part 4 Survey results due Sunday, 19 August by 19.00 UTC) Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.

1 0

Fwd: Coordination between ICANN org and EPDP
by Kurt Pritz Aug. 15, 2018

Aug. 15, 2018

Hi Everyone: Yesterday, I received the email below from Göran Marby. I wanted those of you who are interested to see and have the ability to comment on my draft reply, which is immediately below Göran’s letter. The reply will be from me so I might not include all comments - not necessarily because I disagree with the substance but it might be because of tone, timing or level of detail. On the other hand, I’d be foolish not to consult with you as many of you have been involved with ICANN efforts at correspondence and issue resolution. If you have input, I will read and consider it carefully. I am not sure I want to make this a topic of discussion in tomorrow’s meeting as finishing the triage is more important. I see the letter as more of an invitation to start a dialogue where we can integrate efforts, rather than pursue separate objectives. Best regards, Kurt > Begin forwarded message: > > From: Goran Marby <goran.marby(a)icann.org> > Subject: Coordination between ICANN org and EPDP > Date: August 14, 2018 at 8:17:13 AM PDT > To: "rafik.dammak(a)gmail.com" <rafik.dammak(a)gmail.com>, "kurt(a)kjpritz.com" <kurt(a)kjpritz.com> > Cc: David Olive <david.olive(a)icann.org>, Theresa Swinehart <theresa.swinehart(a)icann.org>, John Jeffrey <john.jeffrey(a)icann.org>, "Akram Atallah" <akram.atallah(a)icann.org>, Chris Disspain <chris.disspain(a)board.icann.org>, "leon.sanchez(a)board.icann.org" <leon.sanchez(a)board.icann.org>, Cassia Oliveira <cassia.oliveira(a)icann.org> > > Kurt, > > Today, ICANN org held a call to provide community leaders with updates regarding various GDPR activities. The slides and recording of the call are available at https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en <https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en>. > > On the call, a few community leaders reinforced the value of coordination between ICANN org and the EPDP Working Group, particularly around access model. To this end, please share with us any thoughts you might have regarding a process by which (1) ICANN org can share guidance we receive from the DPAs and European Data Protection Board with the EPDP Working Group; and (2) How the EPDP Working Group will provide input regarding access to ICANN org to use in our interactions with DPAs and European Data Protection Board to obtain legal guidance that will help guide the Working Group in its work. As you know, we post all information we receive through our blogs and engage with stakeholders, also through communications we post whether through correspondence or comments via gdpr(a)icann.org <mailto:gdpr@icann.org>. I look forward to hearing your thoughts on how we can continue to strengthen our work together toward the common goal of having an access model that is guided by the law and supported by the community. > > Best regards, > > Göran Marby > President & CEO ICANN > +1(310) 578 8690 > > > Cássia Oliveira > Sr. Manager, Office of the President & CEO > cassia.oliveira(a)icann.org <mailto:cassia.oliveira@icann.org> > +1(310) 578 8656 Dear Goran: I have repeated some your email below so that there is a clear connection between your questions and my responses. Today, ICANN org held a call to provide community leaders with updates regarding various GDPR activities. The slides and recording of the call are available at https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en. On the call, a few community leaders reinforced the value of coordination between ICANN org and the EPDP Working Group, particularly around access model. To this end, please share with us any thoughts you might have regarding a process by which: 1) ICANN org can share guidance we receive from the DPAs and European Data Protection Board with the EPDP Working Group. a. Through its many recent actions: engaging with the ICANN community, governments, the EDPB, and others, it is apparent that ICANN is the midst of executing a plan to obtain certainty around the various GDPR provisions. It would be instructive for the EPDP Team if ICANN were to share its plan (or elements of it) so that the team can anticipate the receipt (and timing) of new information. It would also indicate where there is likely no additional information, i.e., where the team would be left to draw conclusions based on the information that is already available. This information would likely cut down on the number of questions the ICANN Org receives from the team. We understand that the plan must have a degree of informality and be flexible, with each step based upon the information received in the step before it. However, where available, it would be instructive to know the planned-for objectives, expected learnings, a set of ultimate questions to be answered, planned inquiries, targets and so on. b. While ICANN has published each communication, the findings or results of those communications have not been organized in anyway of which we know. For example, observers of the back-and-forth between the ICANN Org and the EDPB have offered conclusions that can be drawn from these documents. However, no one has organized those conclusions in a way that might become a rule set or set of guidelines for those reviewing the Temporary Specification or creating an access model. Coincidentally, in today’s EPDP meeting such a request was made: for disclosure of all the communications with the EDPB and DPAs, the staff commentary to those communications, and some organization of same. c. We also wish to hear of developments related to GDPR in other industries, if available, such as: what data processing protocols have been adopted what data processing protocols have been tested in courts what other privacy regimes are in works in other jurisdictions what data is available regarding: the effects of GDPR on malfeasance detection, avoidance other positive or negative effects of GDPR 2) How the EPDP Working Group will provide input regarding access to ICANN org to use in our interactions with DPAs and European Data Protection Board to obtain legal guidance that will help guide the Working Group in its work. As you know, we post all information we receive through our blogs and engage with stakeholders, also through communications we post whether through correspondence or comments via gdpr(a)icann.org. a. The EPDP team’s third set of deliverables is to provide an, “Initial Report and a Final Report regarding the EPDP Team’s recommendations … for a System for Accredited Access to Non-Public Registration Data.” Work on this could begin as early as the completion and publication of the Initial Report on the Temporary Specification. (The Team stays in close contact with the GNSO Council leadership in pursuit of the deliverables to ensure the spirit and letter of the EPDP Charter is followed.) b. While our current answer to this question is not yet finely honed, it is likely that, from time to time, the EPDP Team will have question regarding the constraints / opportunities imposed by the GDPR. These questions might take the form of a proposed access model (or elements of an access model). The EPDP Team will forward those to ICANN, which, in turn, can test them against its own knowledge base, with DPAs, with the EDPB, or elsewhere. c. As ICANN is a data controller involved in the collection, use and disclosure of the same data that is the subject matter of this Team’s work, it is expected that ICANN will work with the team on the successor to the Temporary Specification and an access model. I hope you find this response helpful. The team is keen to continue an active correspondence with ICANN in order to flesh out the framework provided by GDPR with detailed clarifications, implementation guidance and cases from other, similarly situated industries that have faced many of these same issues. We also plan to remain in close communication with ICANN leaders on this topic, through the ICANN-provided liaisons to the EPDP Team. Sincerely,

1 0

For your review - EPDP Team Communications Plan
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Dear All, Following yesterday’s meeting, please find attached for your review the proposed EPDP Team Communications Plan that has been developed with the support of our colleague Arial Liang. You are encouraged to provide any suggestions, comments and/or input you may have. Thanks, 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<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

2 1

**Added view only Adobe Connect room option/ Audio cast information for alternates and observers / 16 August 2018, 13:00 UTC
by Terri Agnew Aug. 15, 2018

Aug. 15, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesday’s and Thursday’s at 13:00 UTC 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/owtpBQ Kind regards, Terri

1 0

Re: [Gnso-epdp-team] [Ext] Re: For your review - EPDP Team Communications Plan
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Hah, someone just had the same problem with Becky’s presentation so I too quickly assumed it was that document you were referring to. Here is the communications plan – hopefully now everyone has what they need and is able to open it! Best regards, Marika From: Chris Disspain <chris(a)disspain.uk> Date: Wednesday, August 15, 2018 at 19:50 To: Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Re: [Ext] Re: [Gnso-epdp-team] For your review - EPDP Team Communications Plan It opens fine but is the wrong document…. :-) Cheers, Chris On 15 Aug 2018, at 18:48, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> wrote: Apologies, I have been having some issues with my attachments lately. Hopefully the attached version does not have the same issues. If it does, the slides can also be downloaded from here: https://gnso.icann.org/sites/default/files/file/field-file-attach/picket-fe… [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d…>. Best regards, Marika From: Chris Disspain <chris(a)disspain.uk<mailto:chris@disspain.uk>> Date: Wednesday, August 15, 2018 at 19:31 To: Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> Cc: "gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [Ext] Re: [Gnso-epdp-team] For your review - EPDP Team Communications Plan Marika, The attachment won't open so may be corrupt. It’s labelled as a ‘mail attachment' which doesn't look right. Cheers, Chris On 15 Aug 2018, at 17:09, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Following yesterday’s meeting, please find attached for your review the proposed EPDP Team Communications Plan that has been developed with the support of our colleague Arial Liang. You are encouraged to provide any suggestions, comments and/or input you may have. Thanks, 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 [learn.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. <Mail Attachment>_______________________________________________ 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 <Picket Fence Presentatino - Becky Burr.pdf>

1 0

Re: [Gnso-epdp-team] [Ext] Re: For your review - EPDP Team Communications Plan
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Apologies, I have been having some issues with my attachments lately. Hopefully the attached version does not have the same issues. If it does, the slides can also be downloaded from here: https://gnso.icann.org/sites/default/files/file/field-file-attach/picket-fe…. Best regards, Marika From: Chris Disspain <chris(a)disspain.uk> Date: Wednesday, August 15, 2018 at 19:31 To: Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] For your review - EPDP Team Communications Plan Marika, The attachment won't open so may be corrupt. It’s labelled as a ‘mail attachment' which doesn't look right. Cheers, Chris On 15 Aug 2018, at 17:09, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Following yesterday’s meeting, please find attached for your review the proposed EPDP Team Communications Plan that has been developed with the support of our colleague Arial Liang. You are encouraged to provide any suggestions, comments and/or input you may have. Thanks, 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 [learn.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. <Mail Attachment>_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

1 0

Proposed Agenda - EPDP Team Meeting #5 - 16 August at 13.00 UTC
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 16 August at 13.00 UTC. Note that the slides and other documents will follow later as survey responses have not all been received yet. Best regards, Caitlin, Berry and Marika EPDP Meeting #5 Agenda Thursday, 16 August 2018 1. Roll Call & SOI Updates 1. Welcome and Updates from EPDP Team Chair 1. Summary of responses to EPDP Input Survey Part 3 - Results for Appendix D: Uniform Rapid Suspension, Appendix E: Uniform Domain Name Dispute Resolution Policy, Appendix G: Supplemental Procedures to the Transfer Policy 1. Substantive Discussion of Temporary Specification: * Part 3 of the Survey can be found at https://www.surveymonkey.com/r/7PWQPP7 * Appendix D: Uniform Rapid Suspension * Appendix E: Uniform Domain Name Dispute Resolution Policy * Appendix G: Supplemental Procedures to the Transfer Policy 1. Confirmation of action items and questions for ICANN Org, if any 1. Wrap and confirm next meeting to be scheduled for Tuesday 21 August at 13.00 UTC. (Part 4 Survey results due Sunday, 19 August by 19.00 UTC) 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<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Picket fence presentation
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Dear All, As per the action item of yesterday’s meeting, please find attached the presentation that was provided by Becky Burr to the GNSO Council during its Strategic Planning Session that took place in January of this year. Below you will also find the notes from this session that have been excerpted from GNSO Council Strategic Planning Meeting Report. Best regards, Caitlin, Berry and Marika =================== From the GNSO Council Strategic Planning Meeting Report (see http://mm.icann.org/pipermail/council/attachments/20180307/1b480812/GNSOCou…) Objective: Explain the “picket fence” and ICANN SO/AC structure in the context of history of the organization and how this impacts on the GNSO’s role and function within ICANN High level notes: See presentation provided by Becky Burr (https://gnso.icann.org/en/picket-fence-concept-overview-29jan18-en.pdf) * ICANN’s picket fence – what is it and where did it come from? * In October 1998 agreement to transition from Verisign as sole registry and registrar for .com, .net and .org, followed by naming of competing registrars in April 1999. * First registry agreement and registrar accreditation agreement signed on 10 November 1999. * ICANN needed the ability to uniformly enforce obligations, including the ability to add additional obligations without contractual negotiations. As part of that discussion, there was a need to identify the areas in which such additional contractual obligations could be added, tied to ICANN’s mission as well as a process by which such additional contractual obligations could be developed. * The “picket fence” characterized this area that would delineate the topics for which ICANN could enforce additional contractual obligations that would have gone through an agreed upon process; anything outside of that area would need to be the subject of contract negotiations. * Registry and registrar agreements cover the picket fence in slightly divergent ways. A number of examples were included in the agreements to provide an illustration of what topics would be considered within the picket fence. * Picket fence incorporated into the post-transition Bylaws: * The mission of the Internet Corporation for Assigned Names and Numbers (“ICANN”) is to ensure the stable and secure operation of the Internet’s unique identifier systems … (the “Mission”). Specifically, ICANN: * Coordinates the allocation and assignment of names in the root zone of the Domain Name System (“DNS”) and coordinates the development and implementation of policies concerning the registration of second-level domain names in generic top-level domains (“gTLDs”). In this role, ICANN’s scope is to coordinate the development and implementation of policies: * For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS including, with respect to gTLD registrars and registries, policies in the areas described in Annex G-1 and Annex G-2; and * That are developed through a bottom-up consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names systems. * Annex G-2 (Registry specification): * The topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD registries are: * Issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS; * functional and performance specifications for the provision of registry services; * security and stability of the registry database for a TLD; * registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; * resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names); or * restrictions on cross-ownership of registry operators and registrars or registrar resellers and regulations and restrictions with respect to registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or registrar reseller are affiliated. * Registrar specification (G-1) only differs with regards to domain name use. * As a result of the transition-related work, namely the CCWG-Accountability recommendations, the picket fence was incorporated into the Bylaws as part of ICANN’s mission. The mission is now clarified to include the constraints that are in place with regards to ICANN’s authority and ability to enforce contractual obligations on the topics as outlined in the Bylaws. * It was necessary from a contracted parties’ perspective to balance out ICANN’s need to develop policies and impose them on contracted parties, where those policies are necessary for security and stability reasons. Incorporating the picket fence into ICANN’s mission provides some measure of predictability and stability that businesses like contracted parties need. This sets up a unique situation whereby a contracting party is legally bound to terms which may not be consented to. * Picket fence circumscribes ICANN’s authority with regards to names. * Effective policy-making requires that affected stakeholders be able to participate, hence the structure of the GNSO Council. * In addition to examples of what is within the picket fence, the base registry and registrar agreements also contain certain examples of matters outside of the picket fence, such as pricing, fees paid to ICANN, etc. * Picket fence concept is inherently based on consensus-driven process. There is more predictability in the sense that there is more discussion and understanding of the different positions, that you may not get in a voting model. Consensus provides balance against capture. It is also the tradition by which decisions are made in the technical community. * ICANN Board has committed to tying decisions and actions explicitly to relevant Bylaws provisions that empower the Board to act or not act for any decisions going forward. SO/ACs will be encouraged to adopt this approach going forward. 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<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Notes and action items from today's EPDP Team Meeting - 14 August 2018
by Marika Konings Aug. 14, 2018

Aug. 14, 2018

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Thursday, 16 August, 13:00 UTC. Best regards, Caitlin, Berry, and Marika =============== EPDP Team Meeting - 14 August 2018 Tuesday, August 14, 2018 High-level Notes/Actions: 1. The next meeting is Tuesday 16 August at 13.00 UTC. The deadline for submission of Part 3 of the survey is Wednesday, 15 August at 19:00 UTC. 2. In response to a request for better access to the meeting proceedings, ICANN will provide a “read-only” Adobe Connect room where Alternates and Observers can see the presentations and chat and listen to the audio. The room was tested in today’s meeting and should be available for the next meeting. 3. In a discussion of the role of this “Triage” portion of the work it was pointed out that: * combining sections for comment can result in a result that there is not consensus on an issue where there often is agreement on the heart of the issue * the utility of the Triage discussion was also questioned as, after some issue identification, we skip over substantive discussion * by way of suggestion, if more “wordy” comments were submitted, support / non-support and root issues will be more easily identified * the goal of the Triage is to form the required deliverable for the GNSO where the comments provide a basis for the next round of discussions 1. Additional materials requested of ICANN: * “Picket Fence” presentation from by Becky Burr * Library and summation (e.g., staff notes and annotations) of communications between ICANN and EDPB and other similarly situated entities 2. ICANN’s role as a data controller should be noted and communicated for discussion at the appropriate time to ICANN in secs. 5.1 et.sec., particularly Data Escrow Questions for ICANN Org from the EPDP team: 1. Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data? 2. In section 5.7 of the Temporary Specification (and other sections), what is the meaning of “reasonable access”? Is it access to personal data reasonably provided? Does “reasonably” relate to the effort necessary to retrieve it? Does it mean how criteria for releasing it are applied, i.e., legitimate and not overcome by the rights of others? Should it just be “access”? All Action items: · Staff to circulate proposed Communication Plan with EPDP Team for input and review · EPDP Team to review communications plan and provide feedback · Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting. · Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC. · Staff to share “Picket Fence” presentation that Becky Burr provided to GNSO Council with EPDP Team. · Staff to forward message from Kavouss regarding selection of meeting venue with ICANN CEO and ICANN Board Chair (completed) and his spoken message in today’s meeting · EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC 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/2IpHBQ. 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 Chair · F2F meeting · Scheduled to be held in Los Angeles from Monday 24 - Wednesday 27 September 2018. Plan for full three day meetings. · Concerns expressed about visa ban that will prevent attendance of some members of certain nationalities. This has also affected attendance of members for other meetings such as ICANN60 in Puerto Rico. Request avoiding any future meetings in any country or geographic territory which impose an entry ban for certain nationals. This request has also been communicated to the ICANN CEO and Chairman of the ICANN Board. · Are alternates able to attend in person, if they would desire so? There may be space limitations that need to be factored in, but the leadership team is looking into options. Some disagree with the ability of alternates to attend - their role is to replace members in their absence not participate in addition to members. · Communications Plan · One of the requirements of the charter is to communicate on a regular basis with the GNSO Council and broader community. ICANN Staff has put together a plan & road map that outlines various ways of communicating regular updates. Action item #1: Staff to circulate proposed Communication Plan with EPDP Team for input and review Action item #2: EPDP Team to review communications plan and provide feedback · Access for Alternates · Request for read-only access to Adobe Connect room to facilitate alternates to follow deliberations. This could be done through using a shadow room. · Recommended that if there is support from GNSO SG/Cs for this request, to request Rafik as the GNSO Liaison to take this back to the GNSO Council for its consideration. · Proposed approach is to live stream the Adobe Connect room for alternates/observers to observe - this will allow for real time view of chat and slides. Testing is currently occurring with the hope that this solution can be rolled out by Thursday's meeting. Action item #3: Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting. Action item #4: Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC. · Draft Triage report · Still work in progress - the hope is to share the draft triage report shortly with the EPDP Team for review. 3. Summary of responses to EPDP Input Survey Part 2 a. Results for Sections 5-7 (Requirements Applicable to Registry Operators and Registrars) b. Appendices B (Supplemental Data Escrow Requirements) & F (Bulk Registration Data Access to ICANN) See summary table of results in slide deck 4. Substantive Discussion of Temporary Specification (beginning with Sections 5, 6, 7, Appendix B, & Appendix F) a. Part 2 of the Survey can be found at https://www.surveymonkey.com/r/7BMRCNS b. Responses and issue summaries are in the Spreadsheet accompanying this agenda Section 5. Requirements Applicable to Registry Operators and Registrars 5.1. Publication of Registration Data 5.2. Registrar and Registry Operator Service Level Agreement. Issue Summary: 5.1: There are many comments but none object to the incorporation of the Appendix into the Specification via this clause. 5.2: It was noted that the required date for the closure of SLA negotiation is past and should be reset to one quarter out or dealt with in some other way. Other comments state that discussions on access should not occur until after all gating questions have been answered, and Contracted Parties are data processors only to the extent necessary to fulfill the objectives clearly articulated within ICANN's mission statement. · Most comments pointed to the appendix not the section itself. · Add to the summary for 5.1 that there is disagreement regarding the content of the Appendices. Issue Summary: 5.3-5.4: Most groups support these clauses as incorporating the Appendix into the specification. There is disagreement regarding the content of the Appendices. 5.5: Discussion required to ensure this wording adequately addresses all possible combinations of countries involved in data transfer. · ICANN is not mentioned as party here, this is problematic. Need to make relationship clear - data agreement between escrow agents and ICANN. · ALAC comment was more of a question than an objection in relation to 5.5. Wording in the section refers to adequate processes but not clear whether in all cases there are adequate processes available. Should be clarified. Issue Summary: Many support sections 5.6 - 5.7. ICANN & this team should define "reasonable access" in Section 5.7. Those not in support of 5.7 state that ICANN needs to ensure that access is narrowly tailored for this purpose. There is a question as to why ICANN needs access to registration data for compliance purposes. Another group states ICANN should have full access to registration data. · Need to define "reasonable access" as part of 5.7 · Need to be precise in what data elements ICANN needs to get access to for what type of compliance action. Section 6. Requirements Applicable to Registry Operators Only Issue Summary: Several groups support 6.1 - 6.3; one noted that (1) section 6.3.2 should be amended to reflect that approval of RRA updates is necessary and (2) the community should strive to have a single, standardized approach on GDPR provisions in general, and international transfers in particular. Other comments: (1) amend the timeline in 6.2; (2) clarify the definition of periodic access in 6.1, the reporting requirements in Section 6.2, and the language around international data processing in 6.3; (3) Test 6.1 and 6.2 against data minimization principles · RySG suggested eliminating section 6.2 and suggested clarifications to 6.3. Do model clauses even apply in all circumstances? For 6.2 date is in the past so language is not relevant as it has been superseded by what has happened in practice. 6.3 goes into the limits of the picket fence, this gets into an area that goes beyond the picket fence. Encourage everyone to review specification 1 to the new gTLD Registry Agreement which sets out the parameters of what consensus policy can cover - this seems to go beyond that? This may need further analysis as not everyone may agree that this falls outside the picket fence - let's not make assumptions. If need be, specific questions could be asked of ICANN staff? · What are additional reporting requirements? What is meant with that? Clarification needed. · In relation to section 6, consider having registrar operators contributing to this contribution as they impose requirements on a blanket basis. Up to contracted parties to pass on any obligations to parties they have contractual agreements with. May confuse things if downstream parties are included in this conversation? · Need to consider whether article 6 approach is taken which would involve joint controller agreement between ICANN and contracted parties. · ICANN's Model RRA-Data Processing Agreement refers to the concept of Shared Personal Data (which is a subset of Personal Data and not mentioned in the Temp Spec.) General comments on triage effort · Objective of this exercise was originally to try and establish where there was agreement / support for certain sections but also understand where there is disagreement and why. Summaries aim to provide succinct summary of the main comments in each section. Tool for driving the discussions in the next phase where the EPDP Team will hone in on the substance and possible path forward. Individual comments will of course also be part of that. · Grouping of certain sections may unfairly indicate support or lack thereof as sometimes issues are with a very specific part. In certain cases a ‘No’ response may support the concept but may have objected to the actual phrasing. Need to figure out where there is agreement and/or minor issues that can be easily addressed so focus can be on the significant disagreements. · We do the triage exercise to establish which parts of the temporary specification are controversial and what the reasons for objections are. Therefore, suggestion is to indicate the level of support and be a little more wordy on the reasons for objections. That can probably help avoid discussions on these calls. · Need for proper definition of terms to be able to express views. · Maybe should have focused on, do you agree in principle with this section to weed out minor issues vs. substantial ones. Action item #5: Staff to share presentation that Becky Burr provided to GNSO Council with EPDP Team. Section 7. Requirements Applicable to Registrars Only Issue Summary 7.1 - 7.1.8: Some comments indicated this provision is too prescriptive and, as such, is likely to: (1) give a false impression that following this direction provides full GDPR compliance, (2) not address privacy regimes in other jurisdictions, and (3) does not accommodate different business models. It would be better to generally require GDPR notice requirements. This clause does not include ICANN’s role and notice requirements as a data controller. Some supported this detailed direction but indicated additional detail and definition of terms (e.g., legitimate interest”) is necessary. · Who decides what is commercially reasonable? Issue Summary 7.1.9 – 7.1.15: Some groups believe more precision and detail is needed to cover all aspects of GDPR ("consent" should used as in list of defined terms), but contracted parties believe that the sections are too prescriptive, and each registrar and registry must figure out how to comply given its business model · May need single policy across all registries and registrars - EPDP Team's role to define what that is. Issue Summary (7.2 - 7.2.4): The potential implementers of Section 7.2 note (1) the difficulty of gaining consent to publish "additional contact information" and more clarity is needed around the purposes of collecting additional contact information; (2) the difficulty of multiple parties (other that the registrant) providing consent; (3) making each field "selectable" with regard to consent; It is also pointed out that GDPR-compliant consent is still not defined, and that consent should be clear in any case. Those seeking information seek to (1) accelerate the Consent capability implementation (faster than commercially reasonable) and (2) that any contact within the Whois set of contacts and others can consent to disclosure. · Some limited use cases in which registrants have provided consent to share data - not a clear process yet for how to communicate this with the registry, or how consent is obtained from other contacts that have been listed. Consent is a complicated matter. · Consent has to be as easily withdrawn as given - tracking the status of the consent is a challenge and as such may not be reliable basis compared to some of the other legal basis. · What happens if consent is withdrawn? Issue Summary 7.3 - 7.4: This clause is generally acceptable but the Appendix G to which it refers is likely flawed as it denigrates the position / rights of the gaining registrar. The rest of the team looks forward to a briefing by registrars of this issue so there might be agreement that the revised transfer policy is GDPR compliant. Appendix B - Data Processing Requirements Issue Summary - 1: It is suggested that this Section should be struck as the data that is escrowed under the RAA is different that Whois data and so this specification does not apply. It is also suggested that ICANN be identified as the Data Controller here for imposing this requirement and recommended that the RySG suggests that the escrow providers and contracted parties are best placed to work out how to operate escrow services in accordance with the GDPR. Issue Summary - 2: There are parallels to be drawn between data escrow transfers between countries and Whois data transfers between countries - are they both subject to the safeguards listed in Chapter V and what are the implications of that to Whois access? Also, it was pointed out that data escrow is governed by a set of agreements among ICANN (a data controller), the contracted parties and the data escrow provider and might be better left for those parties to negotiate. · There are already contractual obligations in relation to data escrow - does this belong in a temporary specification? Issue Summary - 3: Most agree with this provision but those that do not state that the EPDP needs to clarify ICANN's approach to data escrow agreements and the relationships (i.e. controller / processor) between the parties. This issue highlights the greater need to clarify roles and responsibilities of parties and the structure data sharing agreements. The escrow providers and contracted parties are best placed to work out how to operate escrow services in accordance with the GDPR. Issue Summary - 4: This section is supported. It was pointed out that data escrow is governed by a set of agreements among ICANN (a data controller), the contracted parties and the data escrow provider and might be better left for those parties to negotiate. · Should establish for a fact that ICANN Org is the data controller for this part and contracted parties are carrying this out on ICANN Org's behalf. · Negotiation should not only be left to CP and ICANN. Appendix F: Bulk Registration Data Access to ICANN Issue Summary: This section is supported. It was pointed out that domain names themselves may also be personal information and so this processing activity needs to be analyzed for purpose and legal ground. · Does ICANN Org have a plan in place for storing of this information? Isn't personal data stripped out of bulk registration data? Not clear what process is currently used. · Not clear how a domain name registration can be personal information. · Need to make sure that the way reporting is done is legally compliant. · Need to assess whether there are things that ICANN as the processor needs to do to ensure it complies with GDPR. · Is this a problem for the EPDP Team to solve or is this for ICANN Org to solve? Shouldn't this be ICANN Org's determination to make? 5. Review action items and questions for ICANN Org, if any Questions for ICANN Org from the EPDP team: 1. Is there a list and summary of ICANN contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data? All Action items: · Staff to circulate proposed Communication Plan with EPDP Team for input and review · EPDP Team to review communications plan and provide feedback · Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting. · Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC. · Staff to share presentation that Becky Burr provided to GNSO Council with EPDP Team. · EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC 6. Wrap and confirm next meeting to be scheduled for Thursday 16 August at 13.00 UTC. (Part 3 Survey results due Wednesday, 15 August by 19:00 UTC.) 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<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Fwd: [Iwgdpt-list] Press Release of the Secretariat: Working Paper "Standards for data protection in cross-border data requests" released
by Stephanie Perrin Aug. 14, 2018

Aug. 14, 2018

Colleagues might be interested in this paper on cross border law enforcement issues and data protection standards. Stephanie Perrin -------- Weitergeleitete Nachricht -------- Betreff: [Internationale-presse-liste] Press Release / Working Paper "Data Protection in cross-border data requests" released Datum: Tue, 14 Aug 2018 12:10:38 +0200 Von: Presse <presse(a)datenschutz-berlin.de> An: internationale-presse-liste(a)datenschutz-berlin.de PRESS RELEASE Data protection in cross-border data requests for law enforcement purposes Berlin Group calls for standards The International Working Group on Data Protection in Telecommunications (so-called Berlin Group), chaired by the Berlin Commissioner for Data Protection and Freedom of Information, Maja Smoltczyk, has adopted the Working Paper ‘Standards for data protection and personal privacy in cross-border data requests for criminal law enforcement purposes’ at its 63 rd meeting in Budapest (Hungary) on 9 and 10 April 2018. Law enforcement has become an international undertaking. As data is more and more exchanged and stored around the world law enforcement authorities increasingly seek access to personal data held beyond their national borders in criminal investigations. In the light of this development transborder access to cloud data has been identified as high priority by governments and led them to take actions in this field. However, cross-border data requests present difficult questions of compliance with national and international data protection and privacy standards. Traditional arrangements to facilitate international coordination by law enforcement agencies as they work now are said to be overburdened by the increasing frequency and complexity of cross-border data requests. However, alternate arrangements for transferring data, like voluntary arrangements between providers and foreign governments, can be subject to varied or unknown standards, do not have force of law, and so provide little assurance of protection for the rights of data subjects. In its recently published Working Paper the Berlin Group urges that current and future legal frameworks must maintain strong data protection standards and makes recommendations for appropriate safeguards. The Working Group calls on governments and international organisations to preserve data protection and privacy interests while encouraging prompt and adequate processing of legitimate cross-border data requests. The Working Paper is available for download at http://www.berlin-privacy-group.org About the International Working Group on Data Protection in Telecommunications (“Berlin Group”) The International Working Group on Data Protection in Telecommunications (IWGDPT, a.k.a. “Berlin Group”) includes representatives from Data Protection Authorities and international organisations dealing with privacy matters from all over the world. It was founded in 1983 in the framework of the International Conference of Data Protection and Privacy Commissioners at the initiative of the Berlin Commissioner for Data Protection, who has since then been chairing the Group. The Group has adopted numerous recommendations (“Common Positions” and “Working Papers”) aimed at improving the protection of privacy in telecommunications. Since the beginning of the 90s the Group has focused particularly on the protection of privacy on the Internet. More information about the Work of the Group and the documents adopted by the Group are available for download on the website of the Group at http://www.berlin-privacy-group.org. -- International Working Group on Data Protection in Telecommunications - Secretariat - Berlin Commissioner for Data Protection and Freedom of Information (Germany) Berliner Beauftragter für Datenschutz und Informationsfreiheit An der Urania 4 - 10 D - 10787 Berlin Germany Phone: +49 30 13889 - 0 Fax: +49 30 215 50 50 E-Mail: IWGDPT(a)datenschutz-berlin.de http://www.berlin-privacy-group.org

1 0

Recordings, attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Tuesday, 14 August 2018
by Andrea Glandon Aug. 14, 2018

Aug. 14, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 14 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/oQtpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-14aug18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p62crjhwq48/<https://participate.icann.org/p62crjhwq48/?OWASP_CSRFTOKEN=e491c17805cccb72…> ** 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

Consensus: more granular approach needed
by Tatiana Tropina Aug. 14, 2018

Aug. 14, 2018

Dear all, My name is Tatiana Tropina, I'm an alternate for Milton Mueller for the next few days because he can't attend today's call. I would like to forward his comments (which I fully agree with) on the approach to consensus. Please see below. =================== In determining whether consensus exists on certain key elements of the temp spec, I think we are suffering from the way items were grouped. Some SG’s said “No” because they objected to one thing in the group, but a more granular approach might find wider agreement on certain elements within that grouping. My example here is the responses to Appendix A 2.4., 2.5., 2.5.1. - 2.5.1.3., 2.5.2., 2.6., which deals with how the temp spec redacts certain PII from public Whois. NCSG strongly supports those redactions, and in fact we think ICANN has little choice about it because of the GDPR. However, on the survey we see only 2 SGs supporting that question. If we look closer, however, there is actually not much disagreement with the redaction. Registrars support redaction “but questions whether this data should continue to be collected as they are not necessary, and do not comply with data minimization principle.” So the registrars are conflating the collection issue with the public display issue here. They do support redaction of the data elements listed in the temp spec. So do the Registries. Ry SG comments call attention to the litigation around collection of the redacted data and has some other comments unrelated to the question whether the temp spec’s redaction requirements are acceptable. So again we have a debate about collection rather than display. Even the GAC comments do not dispute that the data should be redacted. They call for changing “redacted for privacy” to “redacted for data protection” in the display, and call for additional text with instructions about how to get access to redacted data. Both SSAC and IPC also do not question that redaction is required for GDPR compliance but question the scope of the redaction, saying that it may not be necessary in cases where GDPR does not apply (however they overlook or ignore the existence of similar data protection laws in other jurisdictions). SSAC also make a somewhat irrelevant call for 2 years data retention (which the EDPB has already questioned). In short, a careful review of the comments shows that there is almost no opposition to the selection of data that the temp spec asks to be redacted. We are close to consensus on that vital issue. If it is lumped in with a bunch of other issues, however, more SGs and ACs can find something they don’t like. Since the redaction is fundamental to the temp spec, let’s pull that out and indicate something close to consensus on it. Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology ========= Warm regards, Tatiana

2 1

Request for Adobe Access (Read-only) for Alternates
by Rosette, Kristina Aug. 13, 2018

Aug. 13, 2018

All, On behalf of the RySG, I'm writing to request that EPDP Alternates be granted read-only access to the Adobe Connect room. We are finding that, without access to the Adobe room, it is difficult for the Alternates to follow the meeting fully, to assist Members during the meeting, and to prepare for direct participation (when doing so for a Member). If it would be possible for us to add this request to our agenda for tomorrow (as an AOB), the RySG would appreciate it. I apologize for the short notice, but I had drafted another version of this email on Friday, where it got stuck in my pre-vacation Outbox. Thank you. Kristina Kristina Rosette Senior Corporate Counsel, IP - Domains rosettek(a)amazon.com<mailto:rosettek@amazon.com> | 703.407.1354

1 0

Proposed Agenda for EPDP Tam Meeting #4 (Tuesday 14 August at 13.00 UTC)
by mail＠berrycobb.com Aug. 12, 2018

Aug. 12, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 14 August at 13.00 UTC. Best regards, Caitlin, Berry and Marika ==================== EPDP Meeting #4 Agenda Thursday, 14 August 2018 1. Roll Call & SOI Updates 2. Welcome and Updates from EPDP Team Chair 3. Summary of responses to EPDP Input Survey Part 2 a. Results for Sections 5-7 (Requirements Applicable to Registry Operators and Registrars) b. Appendices B (Supplemental Data Escrow Requirements) & F (Bulk Registration Data Access to ICANN) 4. Substantive Discussion of Temporary Specification (Sections 5-7 + Appendices B & F) a. Part 2 of the Survey can be found at https://www.surveymonkey.com/r/7BMRCNS b. Responses and issue summaries are in the Spreadsheet accompanying this agenda 5. Wrap and confirm next meeting to be scheduled for Thursday 16 August at 13.00 UTC. (Part 3 Survey results due Wednesday, 15 August by close of business.) Thank you. B Berry Cobb GNSO Policy Consultant

1 0

ICANN Org questions from 7 August EPDP meeting
by Caitlin Tubergen Aug. 10, 2018

Aug. 10, 2018

Dear All, Below, please find answers to the questions posed to ICANN Org from the Tuesday, 7 August EPDP Team meeting. Question: The Team seeks clarification on the exact expiry date of the Temporary Specification. In Section 3, the effective date of the Temporary Specification is 25 May 2018, but was adopted on 17 May 2018. Response: Per Section 3 of the Temporary Specification, the effective date of the Temporary Specification is 25 May 2018. Additionally, the ICANN Board resolution adopting the Temporary Specification states: “The Temporary Specification will be effective for a 90-day period beginning 25 May 2018. The Board will reaffirm its temporary adoption every 90 calendar days for a total period not to exceed one year.” Question: If the Board is considering any amendments to the Temporary Specification, it would be helpful if the EPDP Team can be made aware of any proposed changes in advance. Is the Board currently considering any amendments to the Temporary Specification? To address what requirement? Response: ICANN Org is not aware that any amendments are currently being considered. The Board is scheduled to meet in August to consider reaffirming the Temporary Specification according to the process in ICANN’s agreements for adopting temporary policies and specifications. Question: When ICANN refers to “security” as part of its mission - can ICANN describe what types of security are included?? Response: The word “security” appears 36 times in the ICANN Bylaws in relation to topics such as: the DNS, the Internet, the Internet’s system of unique identifiers, the Internet’s root server systems, the registry database, and Top Level Domains. Question: With regard to the term “content,” in Section 4.4.5 - can ICANN provide context for use of the term? Response: It is generally believed that ICANN does not see itself in the role of a content regulator but there are scenarios where use of the term “content” is appropriate in this section. Section 4.4.5 of the Temporary Specification provides a mechanism for third parties to contact Registered Name Holders to address “technical issues and/or errors with a Registered Name or any content or resources associated with such a Registered Name.” With regards to the question about ICANN being a “content regulator,” Section 1.1.c of ICANN’s Bylaws makes clear that ICANN does not regulate content. Thank you. Best regards, Marika, Berry, and Caitlin

1 0

Notes and action items from today's EPDP Team Meeting - 9 August 2018
by Caitlin Tubergen Aug. 9, 2018

Aug. 9, 2018

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 14 August, 13:00UTC. Best regards, Marika, Berry, and Caitlin High-level Notes/Actions: Confirmations regarding the face-to-face meeting are expected to be sent out shortly. The message will also include details on how to make travel arrangements. The leadership and support team is considering how to speed up the triage effort - for example, we might continue the triage effort off-line based on survey responses so that we can start substantive discussion sooner, as early as next week. An assessment will be made after today’s meeting. The EPDP Leadership Team compiled the survey results and prepared “issue summaries” to capture the themes within the rationale reported by the Team members. These summaries are a tool to facilitate the discussion and should not be viewed as authoritative; the Team may provide feedback on the issue summaries by responding to the list. The next meeting is Tuesday 14 August at 13.00 UTC. The deadline for submission of Part 2 of the survey is Friday, 10 August at 19:00 UTC; for part 3, the deadline is Wednesday, 15 August at 19:00 UTC. Questions for ICANN Org from the EPDP team: Regarding Temporary Specification section 4.4.8 - Supporting a framework to address issues involving domain name registrations: the team requests additional specificity. Does this mean that registrars and registries must support a uniform access mechanism when approved or is there some present requirement? Regarding Temporary Specification section 4.4.13 - Handling contractual monitoring requests: which data sets will be required to measure compliance against which contractual provisions? All Action items: EPDP Team members to complete survey part 2 by Friday, 10 August at 19:00 UTC EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC Question for Org Liaisons: what is the intention behind section 4.4.8? Staff to communicate details regarding EPDP Team meeting as soon as possible. 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/2IpHBQ. 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 Getting close on confirming location and timing of F2F meeting. Announcement is expected to be made later today, including information about how to arrange travel. Please note that third survey is due Wednesday 15 August at 19.00 UTC Leadership considering how to speed up triage effort - for example, continue triage effort off-line based on survey responses and dive into substantive discussion sooner, as early as next week. Will see how this meeting goes and write up thoughts about next steps to be shared with the EPDP Team for input. 3. Summary of responses to EPDP Input Survey Part 1 - Results for Appendix A – Registration Data Directory Services See summary of responses in slide deck Even though the green sections indicate agreement, it sometimes is more about the sentiment that is agreed with, but there are still edits suggested, so review still needed. 4. Substantive Discussion of Temporary Specification (beginning with Section 4.4.7 – 4.4.13, 4.5 and Appendix A - Registration Data Directory Services) – see updated spreadsheet attached. Part 1 of the Survey can be found at https://www.surveymonkey.com/r/CC6F9F8 4.4.7. Enabling the publication of technical and administrative points of contact administering the domain names at the request of the Registered Name Holder; Issue summary: Opinions not in favor of this section question the utility of this voluntary data submission and whether voluntary data submissions should be included in the temporary specification. RrSG: not so much questioning the voluntary nature but these technical and administrative contacts are a relic from a previous era and hard to justify collection in the context of data minimization principles as outlined under the GDPR. If the contacts are the same/duplicate, then it is not minimized data. If they are different, then how do we track consent between Registrant and the other (Admin/Tech) contacts? Admin/Tech does have utility in some instances - how do registrars establish that these are no longer in use? ICANN policies have different roles and responsibilities relating to those contacts, such as IRTP, WHOIS data reminder, UDRP. This is data that is used to satisfy ICANN policies. 90-95% are estimated to be duplicates between registrant / tech / admin / billing contact. Why collecting and sharing this duplicative information? Tracking consent is an issue when contacts are different. SAC044 specifies: Maintaining administrative and technical contacts plays a role in reducing single points of failure or attack. 4.4.8. Supporting a framework to address issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection; Issue summary: Explanation opposed to this section is not sufficiently detailed to adequately describe the issue. For example, what is the distinction among DNS Abuse, cybercrime and intellectual property theft? 4.4.9. Providing a framework to address appropriate law enforcement needs; Issue summary: There is a suggestion that LEA access to personal data needn't pass the balancing that data can be disclosed when legitimate and not overridden by fundamental rights. The preamble should refer to Art.6 of the GDPR. Must LEAs demonstrate the right to access data? GAC: Issue summary is correct on 4.4.8 and 4.4.9 - situation needs to be described better. NCSG: 4.4.8 do agree, but with a qualifier / suggestion. Detailing framework for access will come later but need to pinpoint who are the actors with legitimate interests. Also linked to the discussion on ICANN's mission. Put forward proposed replacement text. It seems to imply / create the impression that LEA are always legitimate, but there are plenty of arguments between DPAs and LEA concerning the proportionality. GAC: Article 2 of GDPR states that several categories/types of processing fall outside its scope and thus are NOT subject to the balancing test of Article 6(1)(f). This includes processing for criminal law enforcement and by competent authorities for safeguarding against and the prevention of threats to public security, which falls outside the scope of the GDPR and instead is subject to Directive (EU) 2016/680. Moreover, Article 6 of the GDPR provides for lawful processing in a number of circumstances as set forth in Article 6(1)(a) - (e), such as processing necessary for the performance of a task carried out in the public interest, that also are not subject to the balancing test of “overridden by the interest or fundamental rights” in (f). Finally, Article 6(1) also states that (f) “shall not apply to processing carried out by public authorities in the performance of their tasks.” RrSG: concern about going into content – so summary is correct on 4.4.8. Spec 11 / framework for registry operators to respond to security threats includes what is considered within scope for ICANN (phishing, malware distribution, botnets). May be worth reviewing in this context. Question for Org: what is the intention behind section 4.4.8? There is data that LEA can legally require of organizations - that is limited to the jurisdiction they’re in, work on cross-border transfer in EU being discussed. Tech industry have started recognizing requests for certain types of data from outside its jurisdiction as long as they are not breaking local privacy laws. This voluntary collaboration may not be supported in all jurisdictions. Not ICANN's role to fix MLATs. 4.4.10. Facilitating the provision of zone files of gTLDs to Internet users; Issue summary: Given the distinction between zone file data and registration data, whether zone file contains personal data, and the fact that zone file data is currently available - can this section remain? NCSG & RrSG: not clear on how registration data facilitates provision of zone files of gTLDs to Internet users. Does this belong in a WHOIS spec? There are other processes that support use cases requiring zone file data. Need to also consider other parts of processing, not only collection. May need to be more specific what applies in certain instances? For example, you may collect here for the purpose of safeguarding, but it is actually not shared. Part of the reason for focusing on collection is to think through all the steps that would follow, what processing would take place in addition to collection - if you cannot answer that it the affirmative, should you be collecting the data in the first place? 4.4.11. Providing mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure, or other unavailability of a Registrar or Registry Operator; Issue summary: Is it accurate to say there is general approval of this data use so long as ICANN does not have access to the registration data (which is thought to be the case)? RrSG: response to business failure of contracted party is handled by a separate mechanism than WHOIS so it is not relevant. Escrow system is used for that. Isn't escrow escrowing WHOIS data? It is escrowing a subset and a superset of WHOIS data. Some of the information is not published in WHOIS. Isn't it necessary to include it here as it is being used for purposes like escrow? Isn't that one of the reasons why that information is collected? There may be other ways in which the same purpose can be achieved. May need a graphic to describe different steps in detail. Should be clear about what our mission is - main goal is to go through the temp spec and determine whether it should become a consensus policy. Does the temp spec actually deal with everything so that it is compliant with GDPR? There may be some omissions that need to be addressed. If it is registration data it includes all the data that is submitted but also data that may be automatically generated as a result of the domain name registration, which may also become personal information. Need to make sure that we use the same terminology - WHOIS is a display mechanism, registration data itself can have other purposes. 4.4.12. Coordinating dispute resolution services for certain disputes concerning domain names; and Issue summary: Except for the standard registry response, there appears to be consensus support for this section. Recommendations for enhancement can occur in the next step. 4.4.13. Handling contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users. Issue summary: Where there is disagreement with this section, the disagreement focuses on those specific data needs, without which the compliance task would be impossible to accomplish. What are the reasons for compliance having access to this information? Broad array of uses for WHOIS as it relates to compliance activity of ICANN. Important to have access to effectively do their job. May need to ask for specification on what that job to assess if it is a legitimate purpose outweighing the privacy of individuals. 4.5. In considering whether Processing of Personal Data contained in Registration Data is consistent with Article 6(1)(f) of the GDPR, the GDPR requires ICANN to balance the legitimate interests described above with the interests, rights, and freedoms of the affected data subject. ICANN finds that the Processing is proportionate for the following reasons: see 4.5.1., 4.5.2. 4.5.3, 4.5.4, 4.5.5. Issue summary: Those not supporting this provision found the rationale in sections 4.5.1 et.seq. unconvincing. The alternative approach might be, as discussed earlier, to discuss the data collection and disclosure purposes recommended in 4.1.1 et.seq. and develop this section, if needed, after that. Significant disagreement with this section. May need to be updated / mapped to outcome on other sections such as 4.1.1. and 4.4. Some of the terms in this section may need further clarification such as 'limited' and 'unjustified'. APPENDIX A 1. Registration Data Directory Services 1.2 RDDS Search Capabilities 1.2. RDDS Search Capabilities 1.2.1. Where search capabilities are permitted and offered, Registry Operator and Registrar MUST: (1) ensure such search capability is in compliance with applicable privacy laws or policies; (2) only permit searches on data otherwise available to the querying user, based on whether the user only has access to data publicly available in RDDS or whether the user has access to non-public Registration Data; (3) only provide results otherwise available to the querying user based on whether the user only has access to data publicly available in RDDS or whether the user has access to non-public Registration Data; and (4) ensure such search capability is otherwise consistent with the requirements of this Temporary Specification regarding access to public and non-public Registration Data. 1.2.2. Where search capabilities are permitted and offered, Registry Operator and Registrar MUST offer search capabilities on the web-based Directory Service and the RDAP service (when implemented). Issue Summary: All parties agree that RDAP will be implemented regardless of the date provided in Section 1.1 (which should be removed). There is some uncertainty as to whether a search capability should be a contractual requirement, and whether such a provision such as Section 1 is required at all given the current contract, and also that the risks associated with the aggregation of data must be addressed. RySG: search capabilities are not required for all registries, but new gTLD contract does include language requiring support for search capability. In the base registry agreement there is already language included that should be sufficient as such language in temp spec is unnecessary and more burdensome to implement. For LEA this search ability is really important, even if it is anonymized and likely a redline. Also important for commercial entities who do reverse WHOIS look-ups or correlation analysis. This has been hampered after 25 May so some are of the view that the search capability should be required instead of optional. Does the Registry agreement require this functionality or just allow it? New gTLD RA allows it, but if applicant has said in application that it would offer searchable WHOIS, the applicant is required to include it in the RA. However, it is possible through RSEP to remove searchable WHOIS. RrSG does not support making this mandatory - questioning the legality of offering this as well as the scope of converting WHOIS in a pseudo surveillance system. 2.1 - 2.3 (when data is restricted) Requirements for Processing Personal Data in Public RDDS Where Processing is Subject to the GDPR 2.1. Registry Operator (except where Registry Operator operates a "thin" registry) and Registrar MUST apply the requirements in Sections 2 and 4 of this Appendix to Personal Data included in Registration Data where: the Registrar or Registry Operator is established in the European Economic Area (EEA) as provided in Article 3(1) GDPR and Process Personal Data included in Registration Data; the Registrar or Registry Operator is established outside the EEA and offers registration services to Registered Name Holders located in the EEA as contemplated by Article 3(2) GDPR that involves the Processing of Personal Data from registrants located in the EEA; or the Registrar or Registry Operator is located outside the EEA and Processes Personal Data included in Registration Data and where the Registry Operator or Registrar engages a Processor located within the EEA to Process such Personal Data. 2.2. For fields that Sections 2.3 and 2.4 of this Appendix requires to be "redacted", Registrar and Registry Operator MUST provide in the value section of the redacted field text substantially similar to the following: "REDACTED FOR PRIVACY". Prior to the required date of implementation of RDAP, Registrar and Registry Operator MAY: (i) provide no information in the value section of the redacted field; or (ii) not publish the redacted field. 2.3. In responses to domain name queries, Registrar and Registry Operator MUST treat the following Registrant fields as "redacted" unless the Registered Name Holder has provided Consent to publish the Registered Name Holder's data: Registry Registrant ID Registrant Name Registrant Street Registrant City Registrant Postal Code Registrant Phone Registrant Phone Ext Registrant Fax Registrant Fax Ext Issue Summary: Some parties believe that section 2.1 (coupled with sec. 3) is overly broad in that: GDPR data restrictions can be applied globally and include entities (registrars, registries, registrant) located outside the EEA, and data restrictions need not be applied to Legal persons where personal data is not included in the record. Others say that the legal/natural distinction cannot be made a priori and such a distinction is not implementable. Also, the privacy language prescribed (sec. 2.2) could be required prior to RDAP implementation. Some urge additional data be redacted as personal information can be gained from them: e.g., organization name, city, postal code. The Temporary Specification mentions "consent" without a requirement or specification for such. This group may take that up. Should thin registries should be required to move to thick as part of this Temporary Specification? Consider remaining sections at next meeting. Sharing of draft triage document with the EPDP Team will help in completing the triage effort. Leadership hopes to share this shortly with EPDP Team for review. 5. Wrap and confirm next meeting to be scheduled for Tuesday 14 August at 13.00 UTC. (Part 2 Survey results due Friday, 10 August by close of business.)

1 0

Recordings, attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Thursday, 09 August 2018
by Terri Agnew Aug. 9, 2018

Aug. 9, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Thursday, 09 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: <https://community.icann.org/x/nAtpBQ> https://community.icann.org/x/nAtpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-temp-spec-registration-data-09aug18-e n.mp3 AC Recording: <https://participate.icann.org/p2z1tx9n4wy/?OWASP_CSRFTOKEN=14dea907460b8fed 1934c6322f81020ab8465cb463a6521d925e42e825da8334> https://participate.icann.org/p2z1tx9n4wy/ ** 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/> https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: <https://community.icann.org/x/IYEpBQ> https://community.icann.org/x/IYEpBQ Thank you. With kind regards, Terri

1 0

Welcome - EPDP on the Temporary Specification for Registration Data
by Kurt Pritz Aug. 9, 2018

Aug. 9, 2018

Dear All: I am honored to be named chair of this EPDP team. I know many of you well and look forward to working with all of you. I’ve attached some thoughts about the operation of our team. These suggestions are intended to increase our effectiveness and facilitate the building of consensus. I appreciate your comments on any or all of them, either during the meeting or offline. The attached outline tracks to the meeting agenda, which is being sent out simultaneously with this email. If you have questions about the agenda items, please check the document attached here for some degree of explanation. Our first meeting (1 Aug 14:00UTC) will concern mainly process issues but I have reserved some time at the end for substantive discussion as we should get started in some small way. I look forward to seeing you all on Wednesday. Sincerely, Kurt

7 9