Dear All, Below, please find the notes and action items from today’s EPDP Team meeting. As a reminder, our next meeting will be Monday, 19 November at 14.00 UTC. Best regards, Marika, Berry and Caitlin EPDP Team Meeting #27 16 November 2018 High-level Action Items Margie to suggest modifications to the UDRP/URS paragraph re: complainant access to registration data pre-filing to the list by COB today so other team members may opine on it. Support staff to note the issue of WHOIS accuracy to be discussed in Phase 2. Thomas to add language to the responsible parties text to recognize recent ICANN memo on the joint controllership topic. Support staff to send updated initial report draft with all relevant supporting documentation and relevant links. Notes & 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/uQXVBQ 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 b. Other updates, if applicable Today's goal is to continue going through the outstanding items for the Initial Report. Thomas will also have an opportunity to finish discussing his memo. ICANN Org liaisons may be asked to give a high-level overview of the memo. Benedict delivered Purpose O last night, so this will also be added to the agenda. The PCST (budget committee) decided to hold the third F2F in Toronto, Canada from 16 January - 18 January. Additionally, the team began a discussion about reengaging CBI. 3. Continue review & discussion of comments / input received on Initial Report Objective of discussion: (1) Review proposed changes / comments on the Initial Report that require EPDP Team consideration (2) Agree on if/how these proposed changes / comments are to be applied to the Initial Report a. Commence review of proposed changes / comments on the Initial Report The RrSG is meeting today to further discuss their comments, so for the Team's purposes today, we will not be discussing the Registrar issues at this time. Issues highlighted in green were dealt with yesterday. Beginning with Issue k, staff noted that per the PDP manual, recommendations to the GNSO Council can take many shapes or forms, including requests / advice to the GNSO Council. The recommendations, after adoption, are generally segregated to see who is responsible for carrying out the recommendation. If there is not a problem with asking the GNSO Council to do something, there may not be a problem. It would be helpful to go back to Kristina to better understand the issue. It will be important to specifically note when this group's work may impact other policies, including GNSO policies. Under letter m, what is the BC proposing to change? The BC notes problems with the functioning of the URS/UDRP since Complainants no longer have access to data prior to filing UDRP/URS complaints. This issue was highlighted on this list, so Support Staff added some language to the Initial Report to reflect the expressed issues, noting there is not currently consensus whether this should be a recommendation or not. If further clarification is needed, please write to the list. The Team does need to address the concern of unlimited access to non-public data under the guise of filing a UDRP. Action Item: Margie to suggest modifications to the UDRP/URS paragraph to the list so other team members may opine on it. Issue j: this was discussed early on in the context of the triage report. There was confusion regarding what "in another mechanism" means, so the text "determined by the EPDP Team" was added for further clarification. The mechanism may refer to future work in relation to access to full registration data. The team did speak at length about future work regarding standard access framework; however, why is there a mechanism for access to full registration data from the registry operator? If this language is confusing, it could be deleted. Do not see the value this bullet point provides - suggest removing. No disagreement to removing. This work is being addressed, just not at this stage. Preliminary recommendation 24 (letter n) - waiting for Kristina to provide further guidance. Going back to Issue n, it seems that agreement was reached to remove preliminary recommendation 24. (Note: this is now recommendation 21 in the updated report, so searching for exact language is better here.) Because this is confusing, can we discuss very deliberately what changes are proposed? On 14 November, ICANN published a report on the Transfer Policy. Any review of any policy that ICANN undertakes should look at the implications of GDPR. This recommendation may be unnecessary. Is there a way to inform the GNSO they should do this now? There is no value in the recommendation as its written now. The Team needs to consider accurate data and this should not be pushed further down the road and never dealt with. A recommendation, noting the question, is useful. Items T and U - accuracy of registration data. Coming out of the meeting in Los Angeles, we noted we would not diminish the accuracy recommendations. This is a parking lot issue. Registrar proposal - minor wording change, but this small change does not affect the meaning one way or the other, so it's OK to keep the previously-agreed to language. In that spirit, Rrs oppose the BC addition. All attempts to ensure accuracy have to be weighed, including the cost impact. How is accuracy defined here? It may be helpful to describe it here. The accuracy provision says that the data subject must be able to correct data. If the controller believes there are inaccuracies, the controller has the obligation to try to fix it. This is a parking lot issue so does not need to be discussed right now, so long as the report mentions it, that is sufficient. Action item: Support staff to note the issue of WHOIS accuracy will be considered further in Phase 2. Regarding issue v, this is an example of the team deliberating on the issue. The third sentence regarding other relevant parties is ambiguous and seems confusing to implement. b. Confirm approach for addressing these c. Confirm next steps, if any 4. Confirm / discuss any input on the Thomas’s Responsibilities text (if any) ICANN's summary of response to Thomas's memo: Instead of redlining, ICANN org thought it would be easier to read via a separate document. The Team's recommendation for joint controllership is different from what is currently in the Temp Spec. ICANN org's role is to provide information and implementation-related issues and concerns. Question: are there joint controllers or are they sole controllers? The examples the Art. 29 WP gives with respect to joint controllers are usually companies that operate on the same platform. How should the team work together going forward? ICANN org liaisons are flexible and are at the team's disposal to address this both in the initial report and after. The Team needs to get to a defendable solution to put in its Initial Report. Do any changes need to be made to the report at this time? There is a risk that ICANN org liaisons will go back into listening mode, and unless ICANN org liaisons are an active participant in the process, this Team cannot make progress. Who are the authors of the memo so that the Team can make direct contact with the authors? It would be helpful to offer concrete proposals to the community. Despite the Hamilton memo suggesting joint controllership, ICANN, in its cookbook suggests independent controllership. If this memo is not a position paper, what is it? Why did ICANN come to the conclusion that an independent controllership is present? If more analysis is necessary, how can ICANN come to the conclusion that a joint controllership is not present? ICANN memo has one primary driver - there is a fear that we move to a certain construction without knowing to the full extent what the liability could be. Art. 26 was established for scenarios where the data subject is confronted with complex data processing schemes with multiple parties. The Team should set up a dedicated group, including contracted parties, to set up a road map for items that need to be considered in a JCA. The alternatives are joint controllership or sole controllership for ICANN's purposes. There has been factual analysis to support joint controllership. The GDPR does not specify a joint controller agreement is necessary, but rather, a joint controller arrangement is necessary. In this instance, the RA, the RAA, and the RRA is the arrangement. This is something that should have been sorted out in 2017. While this memo is welcome, how can this report be released absent a balanced discussion of the controllership issue? If ICANN has issues with it, what will ICANN add to counter that and how can this be denoted in the report? The frustration is that this memo is coming so late in the day. While a written question may not have been directed to ICANN org, ICANN org was aware of the responsible parties analysis before the specific question was directed. If the Team manages to get to the finish line, we need assurance that this isn't going to be frustrated by an ICANN org determination that opposes the EPDP Team's conclusions. Where everyone agrees is that contracted parties and ICANN all need to sit down and work on a GDPR compliant arrangement. When ICANN says independent controller, is ICANN comfortable with co-controller instead? It's not a matter of what ICANN org is comfortable with, but rather - what is the correct classification under GDPR. If ICANN has any documentation that went into the cookbook regarding sole controllership, please share with the EPDP team. While the implementation may be difficult, the factual determination comes first. It may be best to list all of the places we agree and note the places we do not agree. When making edits on the google doc, please make it clear what line number you are referring to. 5. Wrap and confirm next meeting to be scheduled for Monday 19 November at 14.00 UTC. a. Confirm action items b. Confirm questions for ICANN Org, if any