Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Monday, 24 September, 15:30 UTC. Best regards, Marika, Berry and Caitlin =============== EPDP Meeting #15 Notes Thursday, 20 September 2018 High-level Notes/Actions Action Item 1: ICANN support staff to distribute Thomas and Farzaneh’s matrix following this call. Action Item 2: ICANN support staff to capture Alex's proposed methodology for discussion of Purposes for Processing Registrations Data and distribute via email. Action item 2a: Alex proposed to include registrar-drafted purposes language for the columns marked as a registrar purpose, and, as an action, for registries to propose draft purposes language for columns marked as registry purposes for §4.4. Action item 2b: ICANN org to provide representation in the Los Angeles F2F meeting, specifically to provide or contribute to ICANN’s purposes for §4.4. Action Item 3: ICANN support staff to reach out to ICANN org and note the EPDP Team’s request for active participation from ICANN org EPDP liaisons and ICANN compliance during the F2F in order to achieve action 2a above and more broadly participate. Action Item 4: Leadership team to further refine the F2F agenda based on today’s feedback, specifically with an approach for discussing data elements, the legal bases for including them, and taking into account different data processing steps. In addition, a column will be added to the agenda for UTC times. Action Item 5: Leadership team to draft §4.4.12 based on today’s EPDP team feedback for the need for specificity. The team will also consider language to “future-proof” sections of the new policy. Action item 6: ICANN support staff to create an index of all of the google docs used to date. Notes and Action Items 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 minutes) Attendance will be taken from Adobe Connect Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) 3. Review and discuss draft agenda for EPDP meeting in Los Angeles (30 min) Objective: To obtain input on the agenda and a common understanding of the objectives of the meeting. To discuss a routinized way of discussing topics since there will be elements of repetition in discussing many “purposes,” many data elements, and so on. EPDP Team feedback on agenda: We need to work through the various processing steps and assess the legality of each. The bullet points and agenda need more granularity. Farzaneh and Thomas put together a data processing/lifecycle matrix that could be helpful in this regard. Should accuracy of data be added to the discussion? Instead of deciding if an "x" should be placed on a purpose, we should use the updated registrar text on purposes for the registrar column and give homework to the registries to draft purposes text for their columns for processing. For ICANN purposes, it was suggested that Dan assist with the ICANN purposes. Important to have Dan Halloran or others from ICANN org as a vocal participant in the meeting. Is it possible to discuss what victory for the EPDP Team would look like on today's call rather than at the F2F? We have to first do legitimate purposes, then we have to relate them to data elements, then we have to agree on redaction and retention. If we include these in the initial report, would anyone disagree that these required components would be victory? Can processing activities be added to these bullets so they are not forgotten during the discussion? Concerns about using CBI. Action Item 1: ICANN support staff to distribute Thomas and Farzaneh's matrix. Action Item 2: Capture Alex's methodology and distribute via email. Action Item 3: Reach out to ICANN org and note the request for active participation from EPDP ICANN Org liaisons and ICANN compliance staff during the F2F. Action Item 4: Leadership team to further refine the F2F agenda based on today’s feedback, including adding a column for UTC times. 4. Continue with purposes matrix to complete discussion of purposes §§4.4.11 – 4.4.13. (30 min) During Tuesday’s meeting, the team reviewed the subsections where team comments added parties to be included for each purpose. The team ended with §4.4.10, having to do with the zone file. The goal today is to finish off the remaining subsections asking each newly added party to explain why this is a legitimate and lawful purpose. Beginning with §4.4.11, x's were added by registrars and registries. If someone added these, please provide a rationale. Re: §4.4.11, this concept of safeguarding could be a registry and registrar purpose and it may be useful to get additional input from the team on that. The registry purpose goes to EBERO and escrow, so as a purpose goes, yes - this is a registry purpose. For registrars: with regard to 4.4.11, that is covered under the escrow requirements so not necessary to be listed as a registrar purpose here. There should be other DRPs included in §4.4.12 and not just UDRP and URS. Question - there are plenty of places in 4.4 where the original Temp Spec wording is broad. The word choice in our work product will be extraordinarily important. With that in mind, what does "coordinating" mean in §4.4.12? Coordinating may not be the right word. Coordinating could mean enabling this procedure so that it works properly. Coordinating could become more clear when the team talks about processing. This discussion is looking at generality vs. specificity - it's best to use specificity so that it is clear why data is collected, and that the team identifies specific purposes for collecting. §4.4.12 needs more specificity. If ICANN adds another DRP, ICANN will have to update its policy accordingly. What if ICANN adds a DRP in the future, how can the policy be dynamic if the policy needs to change? The team could consider listing the acronyms of the relevant dispute process and add language that would cover additional dispute processes developed in the future that are the subject of ICANN consensus policy? Is a data privacy impact assessment necessary for this? It is important to show transparency and go through the process. Would all registrants need to be notified about future changes if ICANN invents or discovers a new, valid use of data? This is the reason why the EPDP feels so high stakes all the time b/c policy is very hard to change. There is no necessity to spelling out the current DRP mechanisms here. To make this more GDPR compliant, it is important to be specific in the discussion of purposes and map out the relevant data processing - more granularity is needed here. The registrars proposed alternative language for §4.4.12 was going in the right direction. There may have been other DRPs referenced in the chat that may need to be added. In discussing the potential of future proofing – it is suggested that PDP activities going forward with respect to any data privacy have a built-in data privacy impact assessment. Action Item 5: Leadership team to draft §4.4.12 based on today’s EPDP team feedback. §4.4.13 - contractual compliance monitoring request. In order to process a WHOIS inaccuracy complaint, ICANN sends the complaint to registrars to confirm the accuracy. With any other complaint that relates to contact data (for example, the audit), the registrar and registry would be involved in that, so this is a registry/registrar purpose. This function is b/w contracted parties and ICANN, a registrar receiving a compliance inquiry – the registrar’s function is to resolve that with ICANN, not with a third party. Struggling to see the nexus here. Registrars and registries may need access to the data, but compliance as an ICANN purpose. The purpose is who is creating the need for the data being available . There is a tendency to put all things WHOIS into this conversation. There is already a WHOIS accuracy policy. The temp spec does not affect any existing accuracy policies. §4.4.13 is a very narrow and specific type of access. For our next rounds of discussion, think about a way to make it more specific. Action Item 5: Leadership team to draft §4.4.12 based on today’s EPDP team feedback. 5. Introduction to Appendix A (30 minutes) Elements of Appendix A are on the agenda for the Los Angeles meeting, so an introduction of the key areas is required. Background: a) Relevant charter questions: f1) Should there be any changes made to registrant data that is required to be redacted? If so, what data should be published in a freely accessible directory? f2) Should standardized requirements on registrant contact mechanism be developed? f3) Under what circumstances should third parties be permitted to contact the registrant, and how should contact be facilitated in those circumstances? b) Key topics are Appendix A §§2-4. The team needs to identify data elements before it talks about redaction. Reasonable access is a term discussed in the temp spec and it can be discussed in a way that is not gated by the charter. The team needs to flag this and move on - this is perhaps why the GNSO Council designed the charter in the way that they did. Action item 6: ICANN Support Team to make an index of all of the google docs the team is using. c) Note feedback already received on Appendix A input document 6. Confirm action items and questions for ICANN Org, if any (5 minutes) 7. Wrap and confirm next meeting to be scheduled for Monday, 23 September at 15.30 UTC at ICANN Los Angeles.