2018-12-13 EPDP Team call #34

High-level Notes/Actions

1. Kurt to work with Support Staff to capture the geographic differentiation discussion and draft a policy recommendation for the EPDP Team to review.
2. The draft recommendation will provide that research should be explored on the feasibility of a rules engine and following the delivery and outcome of the research, the EPDP Team may recommend further work (perhaps by another PDP WG).

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

1.            Roll Call & SOI Updates

• 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)

   a. Review of outstanding action items

   b. Other updates, if applicable

• Due to the potentially large expense of retaining external legal counsel, the Leadership Team met with the Project Cost Support Team (PCST) to discuss options for legal counsel.
• The proposed approach was used by the CCWG - WS2
• The approach is to establish a sub-team, called the EPDP Legal Committee (LC), that will act as an intermediary b/w the EPDP Team and external/internal legal counsel
• The LC will filter, analyze, refine, and approve requests for legal advice
• Members would be practicing lawyers or individuals with legal training - preferably one member per team
• The rationale for the approach is previous success with CCWG-WS2, stewardship of budget, streamlined process
• Within the SOW, Kurt requested a certain number of business days SLA be included to ensure we get answers as soon as possible

EPDP Feedback

• Concerns about approach - it is difficult for attorneys to be instructed by groups with divergent interests. This may involve a lot of time and money with little gain.
• Response: we plan to use this approach, but if it is not working, we will reassess.
• Can we get a degree of assurance that the group will actually take the legal advice received on board?
• Are the stakeholder groups willing to follow advice that may be against the stakeholder group's position?
• Response: we hope the Team will respect any guidance received and use it constructively
• Rather than asking questions, we could describe detailed scenarios and ask if the scenario is compliant with the GDPR.
• Use cases with proposed solutions would be ideal - is this proposed solution GDPR compliant? General questions may not result in helpful answers.

3. Continue review of list of topics for further discussion

Geographic basis

• Amr recently forwarded recent EDPB guidance to the list - does this memo provide clarity to our discussion?
• These guidelines were shared by the EDPB a few weeks ago and are available for a public comment process now.
• A small team discussed the geographic differentiation issue, and the divergent viewpoints were captured in the Initial Report.
• Targeting criteria - just b/c a data subject is located within the EEA does not mean processing of data falls within GDPR. One criterion is the data subject is targeted by a controller.
• Geo localization activities may be relevant - also, online tracking (cookies) or personalized targeting.
• Establishment criteria - main establishment is not the only factor that applies
• Reading this document highlights additional questions
• Reading the guidelines shows there are a lot of areas where the GDPR does not apply
• This guidance is helpful in two ways: (1) putting responsibility on the controller, and the processing activity is not the controlling factor; (2) the guidance also provides some clarity regarding the location of the data subject
• The guidance pivots on the definition of roles. This introduces complexity for contracted parties, and this only applies to GDPR.
• This may be an area where we get very targeted legal advice
• The rules engine approach/chart could be helpful in this context - the guidelines narrow the questions we could ask
• Scenario-based questions are likely to be responded to with pro forma advice such as analysis would need to be done on a case-by-case basis
• If the guidance helps the team draw a box around data subjects, it will still be difficult to draw up 50+ rule sets. The guidance demonstrates that this is a complicated issue and shows the difficulty of digital vs. political borders.
• This appears to be a policy question, not a legal question - does the team want to create a policy where compliance can be enforced?
• While this looks like a legal question, it is not. This is really a question of dealing with requirements that transcend jurisdiction and gets into challenges that global technology firms are dealing with now.
• The team should get more legal advice and come to consensus on what is the lowest risk and practical application from a policy perspective
• The team is ignoring the cost to third parties that access WHOIS data. The EWG report was commissioned by the ICANN Board - once the Board received the report, it initiated the next generation RDS PDP, which was terminated after GDPR/initiation of EPDP.
• The Team does not have time to work through all of this right now, but needs to not just focus on costs to contracted parties
• The Team should also consider potential gaming, i.e. targeting customers in the EEA just to avoid publishing data
• Before the Team agrees to research a rules engine, we should be clear if it would be viable - the team needs to think this through more
• Ultimately, we will need a rules engine to apply multiple laws, but that is outside of our scope and should not be on our critical path. We need something simple that does not require elaborate rules.
• Researching does not necessarily mean the team will make this a policy - however analysis would be helpful, and the team could make recommendations to further explore this in a later phase
• Action: Kurt to summarize this discussion as a policy recommendation for the group to review and ultimately be included in the final report
• Why does the EPDP Team need to research this - shouldn't this be conducted by a different PDP? Perhaps this could be worked on in the future.
• This Team is talking about a policy that is not just GDPR compliant - that is why a rules engine is important - we should recommend that the work begin immediately
• The other thing the group has not yet discussed is the ICANN hub and spoke model

Policy Change Impact Analysis

• Per the charter, there is a need to include a policy impact analysis. The analysis is meant to include metrics to be able to measure the effectiveness of the policy. If the team has ideas for what needs to be captured here, or if anyone wants to volunteer, that would be very helpful.
• During the charter drafting phase, Stephanie had a particular interest in this section, so she could be a starting point.
• The bullet points within the Initial Report show what the team is expected to produce
• It may be premature to determine if the policy achieved its goals given the stage we are in
• An action item could be to review this after policy recommendations are submitted and submit proposed metrics to the Council.
• It's difficult to conduct an analysis before we have specific policy recommendations
• Kurt may consider collaborating with staff to see if an independent resource could be tapped for this exercise.
• It's hard to dedicate time to this effort if something changes as a result of public comment

Our next meeting to be scheduled for Tuesday 18 December 2018 at 14.00 UTC.