2019-02-06 EPDP Team call #43

Notes/ Action Items

High-level Notes/Actions:

Action item #1: Staff support team to circulate the second set of legal questions that have been sent to Bird & Bird for EPDP Team information. (COMPLETED)

Action item #2: ICANN Org to respond to questions posed by RySG in relation to Controller Agreements (recommendation #13) and Contractual Compliance (Recommendation #7), as soon as possible. (COMPLETED)

Action item #3: Registrar team encouraged to review BC input on Recommendation 9 - Org field - and provide feedback on the mailing list.

Action item #4: EPDP Team to further review / consider Data Elements to be Transferred from Registrars to Registries (Rec 5) and put forward proposed language for the Final Report, factoring in today's discussion (that could also be in relation to Rec #22, Impact on Other Policies).

Action item #5: Staff Support Team to update Recommendation #5 (Data Elements to be Transferred from Registrars to Registries) in line with edits suggested by Ayden during the meeting. (COMPLETED)

Action item #6: Leadership to work with legal committee on possible question in relation to Thick WHOIS. Margie to provide initial question draft for Legal Team review.

Action item #7: In response to ICANN-raised issues, staff support team to circulate proposed language to address process for amendments to Registry - Registrar Agreements. (COMPLETED)

Action item #8: In response to ICANN-raised issues, RySG reps to work with ICANN Org on proposed path forward in relation to bulk registration data access to ICANN.

Action item #9: EPDP Team to continue discussion on the mailing list in relation to recommendation #12 (Reasonable Access) in view of coming to agreement by tomorrow's meeting.

Questions for ICANN Org from the EPDP Team: None

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

Proposed Agenda:

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

• Target to end this meeting in 1 hour and 15 minutes to avoid conflicts with other meetings
• Set of legal questions have been sent to Bird & Bird, addressing city field / redaction, meaning of accuracy with regards to GDPR, geographic implications / stable establishments.

Action item #1: Staff support team to circulate the second set of legal questions that have been sent to Bird & Bird for EPDP Team information.

• Encourage continued mailing list deliberations. See input / questions in relation to recommendation #13 - ICANN Org requested to respond to questions posed by RySG as well as rec #7 (compliance) questions from James. Note also issues flagged in relation to Rec #9 - Org field.

Action item #2:  ICANN Org to respond to questions posed by RySG in relation to Controller Agreements (recommendation #13) and Contractual Compliance (Recommendation #7), as soon as possible.

Action item #3: Registrar team encouraged to review BC input on Recommendation 9 - Org field - and provide feedback on the mailing list.

3. Recommendation #5 – Transmission of Registration data from Registrar to Registry (30 minutes)

   a. RySG to present updated language proposal

   b. Discuss proposal

   c. Confirmation of agreement reached or next steps to come to agreement

• See updated language circulated by RySG - two-pronged approach taken. Concept of the workbooks, although vital to provide the context, are specifically as an annex as work done to come to a conclusion, not the policy recommendation itself. Bullet two, in relation to purpose 1B - depending on the individual registry and controllership, they might not need the transfer of registrant data to fulfil their purposes. As such, proposed rewritten bullet 2 - explaining this concept of "mean data set" - each purpose has its own minimum data set. Collection can be unique, but it is for each one of the purposes / processing set. Need to figure out what is the common data set collected across all purposes - would be mean data set. This also includes data elements that may not be transmitted to each registry as certain registries may not need it for its purposes. Don't want to push registries to take data that they don't want and need. At the same time, there can be a departure from the minimum data set for registries that do need this additional data. Took out reference to rec 22 - it will still serve its purpose, which will also include consideration of Thick Whois policy. No need to complicate it here by referencing to rec 22.
• Consider using "aggregate minimum data set", instead of 'mean' data set.
• How can this EPDP overwrite another Consensus Policy? Need further analysis of the impact. Consider referring this to the GNSO Council.
• What happens if a registrar doesn't think a registry needs the data, but the registry does need the data? Could create an untenable situation. Seems to remove ICANN's role in this decision of what information is required to be sent to registry.  
• This group would not be deleting the Thick Whois policy but is saying that the GNSO Council has to look as this and other policies because Compliance with GDPR , as is our mandate, requires it.
• EPDP Team has been working on this for a long time now and did not find a justification for transferring all data, but just for a subset / mean data set. Additional data requires additional justification, which can, for some be 6 I b and for some 6 I f. Remember, for 6 I f, a party needs to claim to have a legitimate interest. You cannot force someone to have an interest.
• Each purpose has its own data set and its own minimum data set - in this recommendation trying to figure out which data has to be transferred to registries across all purposes (mean data set).
• The "Thick" Whois Consensus Policy requires itself to be revised, should conflicts with privacy/data protection law become apparent anyway. So recommendation 5 seems perfectly compatible with it. It should be seen to be helpful to its implementation.
• Balancing in relation to thick WHOIS may need to be reconsidered - did not factor in GDPR at the time - not for this team, has to be done somewhere else. Covered by recommendation #22.
• Consider better defining or naming the concept of mean data set - aggregate minimum data set.
• Not often that the work in one PDP that conflicts with the work of another PDP. No way to reconcile those two.
• "Provided an appropriate legal basis exists" that is the work that went into the data elements workbooks.
• Important to recognize in the report that the EPDP Team has gone through the details of mapping all the processing activities and legal basis.
• Consider posing question to Ruth whether there is a legal basis for transfer from data from registrar to registry under 6(1)b.
• Possible rewording: "As part of this analysis, the EPDP Team has identified a set of data elements that are required to be transferred from the registrar to the registry in order to fulfill the Purposes for Processing Registration Data. This set of data elements constitutes an “aggregate minimum data set.” This is an aggregate minimum data set of all identified Purposes that registrars will be required to transfer to registries. This aggregate minimum data set also includes those data elements that MAY NOT be transferred from the registrar to the registry, where such a registry does not require such a transfer (with due regard to that registry’s terms, conditions, and policies)."

Action item #4: EPDP Team to further review / consider Data Elements to be Transferred from Registrars to Registries (Rec 5) and put forward proposed language for the Final Report, factoring in today's discussion (that could also be in relation to Rec #22, Impact on Other Policies).

Action item #5:  Staff Support Team to update Recommendation #5 (Data Elements to be Transferred from Registrars to Registries) in line with edits suggested by Ayden during the meeting.

Action item #6: Leadership to work with legal committee on possible question in relation to Thick WHOIS. Margie to provide initial question draft for Legal Team review.

4. ICANN Org Questions (30 minutes)

Per last week’s action item, EPDP Team to review additional ICANN org questions and indicate on the email list if any of these need to be addressed in the Final Report

a. Consider topics flagged

b. Discuss proposed approach (‘what happens if these topics are not addressed / covered in the Final Report?’)

c. Confirmation of agreement reached or next steps to come to agreement

• Process for amendments to Registry - Registrar Agreements: objective of this provision was to streamline process for RRA amendments. Might be beneficial to have included in the policy recommendations? Consider addressing this in implementation. Consider adding a general recommendation that would state something like: "policy should include a predictable and transparent process for RRA amendments". Or include under the implementation section language such as: "as part of the implementation, a process for amendments to Registry - Registrar agreements needed to implement EPDP recommendations should be considered".

Action item #7: In response to ICANN-raised issues, staff support team to circulate proposed language to address process for amendments to Registry - Registrar Agreements.

• Notices to Registered Name Holders Regarding Data Processing - already covered by GDPR, this is too prescriptive, not necessary. Work through in implementation - too specific here. Some of it may still be covered, but to be considered in implementation. No need for policy language that duplicates legal obligations.
• Bulk Registration Data Access to ICANN - many registries transferred data that included personal data, this appendix is aimed to clarify that no personal data is to be transferred. Does this rise up to a recommendation level, or is this an action that ICANN could take to notify registries or is this a contract amendment? Better addressed as a contract amendment. Current agreement says that Registry MAY sent a full escrow deposit - now they have to strip it as a result of this provision. ICANN Org does not want to receive a full escrow deposit. What would happen if this provision is not continued.

Action item #8: In response to ICANN-raised issues, RySG reps to work with ICANN Org on proposed path forward in relation to bulk registration data access to ICANN.

5. Recommendation #12 – Reasonable Access (30 minutes)

   a. Review revised proposal

   b. Discuss revised proposal

   c. Confirmation of agreement reached or next steps to come to agreement

Action item #9: EPDP Team to continue discussion on the mailing list in relation to recommendation #12 (Reasonable Access) in view of coming to agreement by tomorrow's meeting.

6. Review of additional topics raised (if time allows)

7. Wrap and confirm next meeting to be scheduled for Thursday, 7 February 2019 at 14.00 UTC (5 minutes)

   a. Confirm action items

   b. Confirm questions for ICANN Org, if any