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)