Dear EPDP Team:

Please find below the notes and action items from today’s EPDP Team meeting.

As a reminder, the next EPDP meeting will be Thursday, 24 October at 1400 UTC.

Best regards,

Marika, Berry, and Caitlin

--

Action Items

1. Amr to propose new text re: Building Block d, subpoint c on compatible purposes – for Building Block d based on today’s discussion by Thursday, 24 October.
2. Support Staff to review subpoint d and ensure relevant points are captured in the Auditing building block by Wednesday, 23 October.
3. Chris Lewis-Evans to work with colleagues to update Building Block h, subpoint h by Thursday, 24 October.
4. Support staff to review and revise Building Block h, subpoint i based on today’s discussion by Wednesday, 23 October.
5. EPDP Team to provide concerns and objections (if any) to the Priority 2 next steps proposal by Friday, 25 October.

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.

EPDP Phase 2 - Meeting #26

Tuesday, 22 October 2019 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)

      2.     Confirmation of agenda (Chair)

      3.     Welcome and housekeeping issues (Chair) (5 minutes)

1. Proposed outline for EPDP Plenary Session at ICANN66

• This plenary session, previously known as the Cross-Community session, was requested by the GAC and GNSO.
• EPDP Support Staff drafted questions to discuss in the plenary session. The EPDP Team is welcome to suggest targeted questions that could generate discussion during the plenary session.

2. Questions to ICANN Org (request to provide input by ICANN66)

• Questions originally raised by James and edited by the EPDP Team were shared informally with ICANN org
• Would the Team object to Janis asking ICANN org to respond to the questions that were already shared informally?
• Should these questions be asked to the Board in addition to Org?
• Janis will send these questions to Goran under his capacity as chair.

3. Status of building blocks

• The Team has not completed any additional building blocks since the last meeting.
• Encourage Team members to make an extra effort to provide input and follow through on action items.
• In the event any member is unable to complete homework by the deadline, please provide an update with an updated deadline.
• In the next agenda item, Janis has requested agreed items to be highlighted in green. Text highlighted in green should not be questioned unless there was a misunderstanding.
• Additionally, there are now two new building blocks for auditing and logging requests.
• Input is sometimes provided very close to the call, which does not give other team members time to provide feedback. Perhaps prior to the Montreal meeting, there will be a date where all documents are frozen so that everyone can work towards a specific deadline.
• IPC will provide input on the accreditation building block by EOD today.
• Marc A. and Hadia to include updated text for accreditation shortly.

4.      Acceptable use policy [docs.google.com] (building block D and H) – second reading continued

1. Overview of updates made
2. Feedback from EPDP Team

Subpoint c

• Still awaiting updated language from Margie and Amr for subpoint c
• Margie and Amr have not yet reached agreement on language; they did agree that a requestor could make a request for disclosure under more than one purpose
• Have difficulty in accepting that the disclosee could change the purpose. If the disclosee is going to state specific purposes, that needs to be the purpose under which they process the data. The requestor cannot make subtle changes to the purposes after receiving the data.
• If this language is in the law, please specify the problem.
• The data subject is going to be told that data will be given to people who have a specific standard and/or purpose(s) as stated. The controller/processor cannot say, “or other purposes as updated”. This dilutes the initial notice to the data subject. Also, the data subject will not know who the disclosee is until there is an access request.
• Article 5 of GDPR – data is not further processed in a matter that incompatible with the purposes for which the data was collected.
• Agree with the above suggestion, but for one issue. Prevent a situation where someone requests data under false pretenses. There needs to be a safeguard that prevents this.
• The purposes for which a requestor may request data is not the same as the original purposes for which the data is collected. The requestor has to seek permission from the primary controller on any further processing, and the determination as to whether further processing is incompatible needs to be made by the primary controller.
• The recipient of the data is now the controller; however, that recipient has no nexus with the registrant. Absent independent oversight, there is now a new controller with data. There are recent examples (like Equifax) to ensure there is a necessity test before release of data and that the recipient of the data will responsibly use the data.
• The theoretical nature of this discussion is blocking resolution.  When we have defined the language which will be presented to the registrant, and when we have discussed some examples of compatible/incompatible, this will be more clear.

• Action: Amr to revise the language of subpoint c and provide to the list for discussion by Thursday, 24 October.
• Margie and Amr do agree that multiple purposes can be submitted for each request. Trying to solve: if after the disclosure has taken place and the requestor comes up with a new purpose that was not disclosed, can the requestor process data for the purpose that was not disclosed?

Subpoint d

• This should be further explained in the auditing section
• What is the purpose for the requestor to submit the lawful basis for the processing to take place? The controller has to have a lawful basis. The requestor can provide a lawful basis they think the controller may use, but not sure why this is included.

Building Block H

Subpoint h

• This has not yet been agreed, so James and Chris L-E are working to update this in advance of Thursday’s call

Subpoint i

• The use of double negatives in not ideal
• There is one issue of releasing a name and another about releasing identity of a person that may be harmed. It is difficult for a registrar to respond to requests by local law enforcement authorities. This point should be split. How to handle human rights defenders is a difficult problem.
• Local laws justify sanctions that may be disproportionate to an offense that has taken place. Disclosure requests must not go further than where MLATs are in place.

Subpoint a

• No disagreements from the Team to remove the word “necessary”

3. Confirm next steps

     5.       Query Policy [docs.google.com] (building block i and l) – second reading continued

1. Overview of updates made
2. Feedback from EPDP Team

Subpoint a and accompanying list

• This is too subjective – what is high-volume to one registrar may be low-volume to another. How can this be implemented to get something that is less subjective.
• Bullet point six is troublesome – there are undefined terms “mine” and “harvest” are very subjective.
• Third bullet point notes quotas – this inclusion is problematic. Additionally, rate limiting is also problematic. If someone is submitting a legitimate request, this needs to be accepted and considered. The third bullet should be deleted.
• Receivers of queries now decide what frequency or number of requests they want to receive unilaterally, but that may not work in the new system. Accordingly, bullet 3 and 6 are problematic.
• This list includes terms that are present in the 2013 RAA. There are two ways to resolve this: be specific as possible or secondly, roll them all up to commercially reasonable efforts to prevent abuse. Team members need to appreciate that there are bad actors, and the SSAD will be a big target. There needs to be mechanisms to safeguard this system – specific safeguards will allow for bad actors to abuse the system. The system should not handcuff providers to burdensome obligations – a small registrar may not be able to handle this, for example.
• GDPR requires adequate and technical measures in place to protect data. In the legal world, the measures would not be published. There needs to be volume control. It may be helpful to look how registries did this.
• One key issue here – there needs to be some reference to proportionality. Registrars range in size radically - what is high-volume to one registrar may be low-volume to another.
• Just as the Team considers bad acting requestors, the Team also needs to consider bad acting registrars.
• Users of data and suppliers of data need to have a common understanding.
• Enumerating abuse may be problematic – perhaps the commercially reasonable approach should be used to give flexibility to the providers.
• The Team needs to find middle ground so that compliance can take action against bad actors.
• The commercially reasonable approach is a nonstarter.
• Support Staff to determine where the “proportionate” idea can be placed.

3. Confirm next steps

     6.       Priority 2 items – proposed next steps (see attached)

1. Overview of leadership team proposed next steps

• This document was shared with the agenda.
• Recommendations factored in the small team’s proposals

Privacy/Proxy

• Questions around how this issue may already be addressed by the PPSAI policy
• This implementation is currently on hold, but perhaps the implementation review team has taken into account this issue – proposal for support staff to reach out to colleagues on PPSAI for further information

Legal vs. Natural

• Confirm with colleagues re: status of the study and associated timeline.
• In parallel to study being undertaken, Legal Committee could review what questions (if any) should be submitted prior to the completion of the study.

City Field

• Legal advice came in at the end of Phase 1
• Legal committee to review and analyze the legal advice and review additional legal questions that have been proposed

Data Retention

• Staff to confirm what the status of ICANN org’s work to review data retention procedures and see if the retention period recommended in Phase 1 needs to be updated.

OCTO

• Follow up with OCTO colleagues – and see if the position during Phase 1 has changed. Based on feedback received, Team would consider what the appropriate next steps are

Uniform Anonymization

• Legal Committee to review the questions received thus far for the Team to have an informed discussion on this

WHOIS Accuracy and ARS

• This is a topic b/w ICANN org and the GNSO Council – trying to review scope of this work – await further guidance on this before proceeding further.

2. Feedback from EPDP Team

• Staff should proceed with the next steps
• The legal vs. natural study is not dependent on the implementation of Phase 1 recommendations.
• Would Team agree to a lunchtime presentation of the terms of reference to the legal vs. natural study.
• EPDP Team to provide objections to the Priority 2 proposal by Friday, 25 October.

3. Confirm next steps

     7.       Wrap and confirm next EPDP Team meeting (5 minutes):

1. Thursday 24 October 2019 at 14.00 UTC
2. Confirm action items
3. Confirm questions for ICANN Org, if any