Dear EPDP Team,

Below, please find notes and action items from today’s EPDP team meeting. As a reminder, any comments or concerns on the draft Initial Report are due COB TODAY, 15 November.

Thank you.

Best regards,

Marika, Berry and Caitlin

EPDP Team Meeting #26

15 November 2018

High-Level Action Items:

1. EPDP Team to review Thomas’ proposed language concerning the responsibilities of the parties in processing data in advance of tomorrow’s meeting.
2. EPDP Team to note any additional concerns with draft preliminary recommendations by COB today.
3. Support Staff to map preliminary recommendation to meeting dates so the EPDP Team can trace the origin of specific recommendations.
4. Support Staff to redraft language for third party beneficiary recommendation indicating there is a diversity of opinion on that issue..

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/uQXVBQ

Proposed Agenda:

1. Roll Call & SOI Updates (5 minutes)

• 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 (5 minutes)

                a. Review of outstanding action items

                b. Other updates, if applicable

• The Leadership Team is meeting with the PCST Team today, and the meeting location should decided at that meeting. Results of this discussion will be communicated to the EPDP Team as soon as available.
• The Leadership Team is looking into using a different tool for public comment submission in an effort to organize and analyze comments more efficiently.
• Regarding Charter questions k, l, and m about data processing terms - no volunteers came forward to draft text, but Support Staff sent draft language for review to the list yesterday.

Feedback from EPDP Team:

• If the team recommends ICANN and CPH to enter into joint controller agreements, the schedule of responsibilities could be included in the JCA and could be left to implementation.
• This Team does not need to specify that CPH needs to comply with GDPR. The Team is tasked with addressing potential inconsistencies with the Temp Spec and the law.
• Regarding Amr's recommendation with respect to legal vs. natural, Amr has amended the Initial Report language.
• Benedict's proposal requires Rrs to allow registrants to make a declaration of if they are a legal or natural person.
• The CPH position - distinction b/w natural and legal persons is not necessary for GDPR compliance and as such, is not appropriate for this time.
• How can the team resolve this issue equitably?
• Perhaps Benedict's recommendations can be included in the report, noting disagreement.

3. Thomas Rickert to review proposed language for Responsible Parties for inclusion in the Initial Report.

• The google doc shows previous language with some amendments based on recent discussions.
• In confirming the team is aligned on responsible parties language:
• First question - can the team speak to the legal question of responsible parties classification? Based on our last call, there appeared to be consensus that the team can make this classification.

Feedback:

• It's unclear how to move this recommendation to policy language. In the triage phase, the team noted ICANN and CPH need to have GDPR compliant contracts in place.

• Second question - what language should be included in the Initial Report to reflect the current state of deliberations?
• The Team could consider leaving the language vague until we receive ICANN's reasoning as to why it thinks it is not a joint controller.
• If the Team is convinced a joint controller situation is present, it should draft recommendations accordingly.
• The EPDP Team's classification of joint controllership is not new and has been discussed on multiple occasions.
• The necessary piece is that contracted parties enter into negotiation with ICANN, but the specificity should be left to the negotiating parties.
• First, the principle question is whether the joint controllership situation is applicable or not?
• Consider adding language - enter into written agreements as set out below (rather than using the term joint controller agreement)
• The Team did a lot of work to complete the worksheets, and responsible parties seems to be the one area where the team achieved consensus. It seems that the work the team did led to joint controller agreements, and the results of this work should be documented in the Initial Report.
• A joint controller agreement does not mean a joint controllership for every single purpose - the agreement would break down the roles and responsibilities. The missing piece in this memo is the joint controllership will reflect the work done in the workbooks and will apportion roles and responsibilities according to the EPDP Team's work.
• Proposed revision regarding the first sentence is in the chat - The EPDP Team recommends that ICANN and CPH enter into an appropriate data processing agreement which may be a joint controller agreement.
• Based on the information and the deliberations the EPDP Team had on this topic and pending further input and legal advice, the EPDP Team recommends that ICANN negotiates and enters into a JCA with the contracted parties.
• The table defines the term ICANN purpose.
• There is a reference to a single JCA - is that a single JCA b/w ICANN, all registries and registrars?
• That is a question for the Team to decide. Thomas recommends basic parameters are in all JCAs or a standard JCA, but there would be exceptions to reflect special scenarios.
• The definition of ICANN purposes should not reference billing.
• Billing was referenced as this is a processing activity that is b/w a contracted party and its customer, and ICANN is not involved.
• Surprised by ICANN's forthcoming reasoning about joint controllership, especially in reference to publication of WHOIS data.
• This language needs to be taken back to the RySG.
• The red herring of billing information should be removed as this data is not published in WHOIS. If the purposes are solely for ICANN, is ICANN the sole controller as opposed to the joint controller?
• Billing could be taken out. The reason it was included was because this purpose is included in the Temp Spec, but the Team agreed to remove it as registrars do not use this information for this purpose.
• How would the processing look different if one of the parties was removed - if it would be different, this would support a joint controllership.
• It may be helpful to have a webinar specifically on this issue early in the public comment period.
• How do resellers fit into the joint controllership scenario?
• Under some purposes, contracted parties are processors - escrow, RPMs
• Please read through the tables regarding the allocation of responsibilities. Give everyone 24 hours to provide feedback in advance of tomorrow's call.
• Some of the arguments and rationale are a bit confusing. Some of the language may indicate that back-end ROs are also controllers, but they are processors.

                a. EPDP Team to discuss approach and bring up concerns, if any

                b. Confirm next steps, if any

4. Commence review & discussion of comments / input received on Initial Report

• The Support Team has captured the Initial Report comments (from the Google Doc) Some comments are cosmetic/grammatical changes, so those changes have been applied. In cases of uncertainty of substance changes, those comments were included for further discussion. For purposes of this discussion, if the commenter can explain their rationale and proposed change, we will open it up for discussion.
• Is it still our intention to publish the report on 19 November.
• The answer is yes.
• The fact that we're still discussing substantive edits is a cause for concern. What is the process for the Team to agree on what ends up getting included and what doesn't?
• Where there is agreement - the recommendation will be included (noting disagreement).
• The proposed changes from the RrSG: this was not discussed within the context of if these comments need to be included before the report can be published. The RrSG members need to consult with their group to see if these could be included in the submitted public comments or if they can be dealt with now.
• On behalf of the registries, Kristina put in a request to include the particular meeting reference when something was agreed upon. The effort to go through where the EBERO recommendation, for example, came from. What may be in notes and recollection may not match the words of the recommendation.
• In the interest of getting you what you need, is there a way to highlight the recommendations you need further information on?
• No, it is all of the recommendations.
• Item O on this list does show where the recommendations came from. Some recommendations resulting from Small Team efforts or are derivatives of several calls; accordingly, it may be difficult to pinpoint the exact meeting where the recommendation derived.
• There may not be agreement on recommendation 7.
• Some recommendations in the report seem to have come out of nowhere.
• It would be helpful to flag any recommendation issues specifically by tomorrow.
• Recommendation regarding third party beneficiaries - any objection to taking this out of the initial report?
• This language does serve a purpose within the contract - do not support removing the language, even though it is poorly worded.  This may need to be revisited to clean up the language.
• There should not be third party beneficiary restrictions in consensus policies
• Action item: Staff to propose language for third party beneficiary recommendation
• There should be a distinction b/w recommendations agreed to in plenary vs. small teams
• RPM WG confirmed it is expected to review UDRP in its next phase of work. If the EPDP Team notes anything in relation to data processing activities with respect to RPMs, it would be helpful to share with the RPM WG.
• There does not seem to be agreement about what optional means, so the Team is asking for clarification with respect to liability with the EPDB. Agreement to leave language as is.
• Recommendation 7 – should this be deleted? Should the first sentence be added, or should the whole recommendation be deleted?
• The discussions have not risen to the level of a consensus policy recommendation, but the language could be included in the report.
• The Team is not limited making recommendations about contractual requirements.

 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

                b. Confirm approach for addressing these

                c. Confirm next steps, if any

5. Wrap and confirm next meeting to be scheduled for Thursday 15 November at 14.00 UTC.

                a. Confirm action items

                b. Confirm questions for ICANN Org, if any