Dear All, Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Marika, Berry and Caitlin EPDP Team Meeting #24 8 November 2018 High-level Notes/Action Items 1. Any EPDP Team members wishing to work with Thomas and the small group on the responsible parties/joint controllership discussion, should reach out to Thomas and complete the small group doodle poll as soon as possible. 2. Support Staff will the rework language for natural vs. legal persons to the mailing list so that EPDP Team members can include and/or correct their own viewpoints. Please propose edits by tomorrow, Friday, 9 November. 3. Berry Cobb described inconsistencies in the data matrices and proposed changes to resolve the consistencies. After receiving feedback in today’s meeting, Berry will summarize the revised changes made to the data elements matrix as a result of this discussion and send the summary of proposed changes to the mailing list shortly. Question to ICANN Org: Is making the natural vs. legal persons distinction in WHOIS within the picket fence, i.e., a suitable topic for policy discussion? Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Please 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 a. Review of outstanding action items Thank you for timely completing all action items from Tuesday’s meeting. Support staff will send open administrative issues within the Initial Report today. Please provide feedback via the Initial Report Input Google Doc by Tuesday, 13 November. b. Other updates, if applicable The Team will announce the F2F location as details become available. Please refer to the Initial Report Input Google Doc to submit any comments or concerns with respect to the draft Initial Report. Support Staff will send an email with outstanding items following this meeting. Please review and note questions or concerns (if any). 3. Review of Responsible Parties Recommendations (Thomas) a. Review and discuss draft recommendations During the last call, Thomas noted there may need to be revisions to the references to responsible parties for the Initial Report. The suggested changes begin on line 900 of the draft Initial Report. The draft recommendation is for ICANN to enter into Joint Controller Agreements (JCA) with the contracted parties. The attachment to Thomas’s email provides more detail about the definitions and the relevant liabilities. Based on this attachment, the table appearing on line 988 would need be be updated to reflect the text in the attachment. The EPDP Team will need to confirm the draft text, the current allocation of responsible parties, and confirm if the EPDP Team would like to liaise with ICANN as to whether ICANN org has concerns about entering into JCAs with contracted parties. Question for EPDP Team: should the EPDP Team assist in the drafting of an JCA or drafting the framework of the JCA? Does the team believe a policy recommendation regarding ICANN and Contracted Parties being joint controllers should be added to the report? EPDP Team Feedback The primary purpose of a JCA is the apportioning of liability. The Team needs to recognize it is apportioning liability, and the utmost care needs to be taken with respect to this. It may be inappropriate for the EPDP Team to draft a specific legal agreement; however, recommending a negotiation b/w ICANN and contracted parties could be an appropriate recommendation. There are parts of this agreement that may be outside the picket fence; however, multi-party negotiations often take a long time, and the extent the Team could provide language or a sample agreement as a starting point could be helpful in this instance. The Team could specify the objectives or guiding principles of the JCA. The Team should not negotiate contract language at this time; the Team's current focus should be on answering the charter questions. The JCA negotiation is best left to attorneys. However, the previous suggestion regarding adding principles or the objective of the JCA into the Initial Report makes sense. With respect to the workbooks, how should the team proceed? The group needs to take one of two approaches: the (1) Thomas approach (adding proposed language to body of Initial report) or (2) ensuring consistency in the workbooks with respect to responsible parties. Joint controller agreements are similar to data processing agreements - if the Team provides a draft it would lay out the processing activities and responsible parties and it could help ICANN apply the Team's policy work. Defining roles and responsibilities is within the Team's charter, and the answers to the relevant charter questions could help inform the eventual JCA. Question to the Team: does the Team support Thomas, Diane and ICANN org fleshing out the memo to draft a policy recommendation? The Team has resistance to drafting a JCA, so perhaps the drafting should be put aside. The question that needs to be answered first and foremost, how far does the question on responsibilities go? Does it end with who should be responsible for what? It may be helpful for the community to have more context within the Initial Report. The Team needs to look at the responsibilities in the workbooks. Regardless to what extent the team may draft a JCA, this would not be a policy recommendation - it will just be an aid to those implementing the policy recommendations. Encourage the team to reread the relevant charter questions and make sure the questions are answered in the Initial Report. b. Confirm next steps, if any Those who would like to assist with the JCA recommendation should send an email to Thomas Rickert and respond to the doodle poll referenced above. 4. Review proposed updates to staff-suggested Natural vs. Legal persons text a. Review and discuss draft approach Support Staff has been rapidly updating this language as suggestions come in. For the next iteration, the language will include direct quotes from both sides. The request for research was agreed to by the small team. This did not suggest contract updates, so the Team may be overthinking this. Rather than declaring where the consensus is, it is clear that some positions will not obtain consensus. In other words, presenting an option that many are not considering should not be included in the Initial Report. Minority opinions should be represented in the discussion, but it should be made clear that some positions may not obtain consensus. The Team should be very clear in the Final Report on what are consensus recommendations and what are not. In order to get the best responses in the public comment period, the views need to be clear. There does not have to be a formal consensus call before the Initial Report is published. Team Members can continue to write their views to the list for inclusion in the Initial Report language. It is inappropriate to make statements regarding consensus at this time. Also, this is within the picket fence as it relates to WHOIS. Question to ICANN: is making natural vs. legal persons distinction in WHOIS within the picket fence? Sweeping statements about issues never reaching consensus is inappropriate. Perhaps we can come to consensus on research the natural vs. legal. More research especially on who bears liability when data subjects identify themselves as legal persons seems logical - especially in posing this question to the EPDB. This policy recommendation could send the group backwards. The CPH is saying this is not currently possible, why do some EPDP members continue to say this distinction is necessary? b. Confirm next steps, if any EPDP Team Members to provide additional feedback on this by tomorrow (Friday, 9 Nov) 5. Review of Consolidated Data Elements Matrix Please refer to the attachments from Berry's email of 7 November. The consolidated matrix combines the similar processing activities, e.g., collection, transfer, disclosure, into one document. The first page shows the processing activities where registrars are asked to collect data. The second page shows the processing activities where registrars are asked to transfer data to registries. This matrix shows what is currently denoted in the workbooks. On the far right, there is a column listed as transmission logic - this analyzes all of the columns to the left. If the item is optional, it is denoted in yellow. If an item is required, it is denoted in green. Data elements that are not required or optional are denoted in red. In reviewing registry escrow, the Team agreed that registries would only escrow the data elements that are transferred to them - in other words, the green and yellow elements in this matrix. Within the current workbook for purpose M, there are many data elements that are requested to go from the registrar to the registry. In the macro sense - this brings up three questions: 1. Post GDPR, is the compliance team's assessment correct that registrars do not need to transfer data to registries for this purpose? 2. At any point when a provider needs to have the registration data revealed, in all cases, the Provider contacts the registrar to acquire that data, so does that mean transfer of certain data elements from registrar to registry is not warranted under Purpose M? 3. In looking at the PDDRP and RRDRP, if one of these RPMs is invoked, does data need to be transferred from the registrar to the registry? Feedback from EPDP Team: For the URS, there is a justified transfer for purposes of the URS. In pre-GDPR complaints, wouldn't the Provider have to go to the registrar for underlying data in a privacy/proxy case? This issue may need to be flagged for the RPMs working group. The matrix may not translate for Initial Report purposes, so a more concise summary could be helpful here. This is done on p. 3. The main intent of these charts to to cross-check and test the logic of the content of the workbooks. In a post-GDPR world, there are cases where the providers are requesting registration data from registries and not registrars, so a draft recommendation for the RPM WG or another PDP to streamline that process. The proposed approach we have listed here is not accurate, so the processing activity of transferring data from a registrar to a registry is correct. It may be reasonable to update the UDRP, and we could include a recommendation that the UDRP be updated to reflect the current realities. For Issue 2, under Purpose A the only two data elements that are transferred are domain name and name servers under 6(1)(b). For the transfer of other data elements, they could be transferred under 6(1)(f). DNSSEC and glue records should be a 6(1)(b). Elements not provided by the registrant are also included in the list elements and should fall into a separate category. For Issue 4, for items flagged as red, we want to confirm some of these may still be necessary – such as registry/registrant ID. There is a notion that the data elements we’re looking at – some are collected by the data subject, while some are generated via the EPP server at the registrar or registry. We are acknowledging that this is the case and some fields marked in red cannot die on the vine as they are used for other policies or inner workings of the DNS. For Issue 3, there are some small inconsistencies for optional data elements. For collection of data by the registrar, for purposes B and C, the Team has identified three optional fields for the tech contact. The tech email is not currently marked as optional, so support staff is suggesting to mark it as optional to ensure consistency across the workbooks. 6. Wrap and confirm next meeting to be scheduled for Tuesday 13 November at 14.00 UTC. a. Confirm action items b. Confirm questions for ICANN Org, if any