PROPOSED AGENDA

1. Roll Call & SOI Updates
2. Welcome and Updates from EPDP Team Chair
3. Summary of responses to EPDP Input Survey Part 4 - Results for Section 8: Miscellaneous; Appendix C: Data Processing Requirements
4. Substantive Discussion of Temporary Specification:

• Part 4 of the Survey can be found at https://www.surveymonkey.com/r/9KD5K79
• Section 8: Miscellaneous
• Appendix C: Data Processing Requirements

5.Overview of triage report, including timeline for review

6. Discussion of next steps

7. Confirm action items and questions for ICANN org (if any)

8. Wrap and confirm next meeting to be scheduled for Thursday 23 August at 13.00 UTC. (Initial comments on Triage Report due Friday, 25 August by 19.00 UTC)     

BACKGROUND DOCUMENTS

EPDP Team Meeting 21Aug18v2.pdf

EPDP Team - Temp Spec Input Part 4v2.xlsx

AUDIO CAST INFORMATION AND VIEW ONLY ADOBE CONNECT FOR ALTERNATES AND OBSERVERS

To join the event, click on the link: 

Listen in browser: http://stream.icann.org:8000/stream01

Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u

View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers

Mp3

Adobe Connect Recording

GNSO transcripts are located on the GNSO Calendar

Attendance and AC chat         

Apologies: Amr Elsadr (NCSG), Esteban Lescano (ISPCP)

Alternates: Collin Kurre (NCSG)

Notes/ Action Items

Notes and Action Items 

High-level Notes/Actions:

• Triage Report is first deliverable of the EPDP Team. Please review the latest version but keep in mind that this is intended to reflect the outcome of triage – it does not include any recommendations or agreements, nor is it intended to prejudice future deliberations.

Questions for ICANN Org from the EPDP Team:

1. Can an update be provided on the status of the reconfirmation of the Temporary Specification by the ICANN Board? Response: There is a board meeting planned for later today (21 August). No changes to the Temporary Specification are being proposed.
2. Has the WHOIS Conflicts with local laws procedure been used and successfully used to date? Please indicate the instances where the procedure was invoked and the outcome. Were any specific issues identified with the use of this procedure?
3. Regarding data disclosures concerning LEA requests: does GDPR compel a report of those disclosures to be made to the data subject? Please provide analysis of “in-jurisdiction” and “out-of-jurisdiction” requests.

All Action items:

• Action item #1: Kurt to follow up with an email outlining the plan for attendees at the F2F meeting.
• Action item #2: EPDP Team to review the draft triage report and provide any initial feedback by Friday, 24 August at 19:00 UTC. (Earlier feedback strongly encouraged.)
• Action item #3 - Team Support to send to the Team information concerning the PDP that was the basis for the WHOIS Conflicts with Local Law Procedure.
• Action item #4 - Thomas and Emily to work on a framework to outlines the controller designations between ICANN and Contracted Parties for EPDP Team review / consideration.

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://icann-community.atlassian.net/wiki/x/-ILkBg.

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

• The hope is to wrap up discussions on triage effort during today's meeting. Appreciate all the work that has gone into this, recognizing the short turnaround time. Triage document aims to capture outcome of triage effort.
• F2F Meeting - set for 24 - 26 of September. See proposal circulated by Kurt to the mailing list for how to deal with alternates. Recommend working in accordance with the first proposal:

1. Members are invited and will be provided travel support.
2. If a member cannot attend in person, an alternate can attend and be provided travel support. If this is the case, the alternate should be designated to the Support Team as soon as possible. 
3. In example (2) above, if the absent member wished to participate remotely of a portion of the meeting, then she can do that and the alternate can only participate when the member is unavailable to participate.
4. If an attending member is, in good faith, reasonably certain that s/he will be absent for a period of time where attendance by an alternate is desired, then:
   1. that member and the alternate can attend the full meeting but only one will be designated as a participant at any one time
   2. the alternate will not be given travel support

• Comments: 3) may be difficult to enforce. Suggest making it either / or. If it is not enforced properly it could give some groups more voices. The scenario envisioned here is that a member could attend for 2 days but not 3 so alternate would come in for one day, or for half a day. It shouldn't be a case of people walking in and out every 5 minutes.
• Some expressed support for option 2 - trust that alternates understand their role.
• Need to factor in the distinction between members and alternates as outlined in the charter. See proposed modification sent to the list by Ayden to ensure balance in the room.  
• Remote participation will be available, that is not in question.
• Leadership to further consider input received but is leaning towards going with option 1.

Action item #1: Kurt to follow up with an email outlining the path forward for the F2F meeting.

Triage document

• See updated version shared with the mailing list, including proposed annexes.
• Triage Report, per the Charter, is EPDP Team’s first deliverable
• The report represents the results from the triage surveys, Part 1 - 4
• Report includes:
• an executive summary
• operating methodology
• the summary table of inputs
• the issue summaries that were created for each section
• an appendix with all written comments
  • The report does not represent any group’s final opinion on any issue - all groups should feel free to revise their input during the course of the EPDP Team’s work

Action item #2: EPDP Team to review the draft triage report and provide any initial feedback by Friday, 24 August at 19:00UTC.

3.  Summary of responses to EPDP Input Survey Part 4 - Results for Section 8: Miscellaneous; Appendix C: Data Processing Requirements

• See high level summary 'heat map' in the presentation
• As before, green sometimes means conditional support, while red sometimes means objection to only certain parts but not the whole section, so the 'heat map' should be taken with a grain of salt.

4. Substantive Discussion of Temporary Specification:

Part 4 of the Survey can be found at https://www.surveymonkey.com/r/9KD5K79 [surveymonkey.com]

Section 8: Miscellaneous

Appendix C: Data Processing Requirements

Issue Summary:

The following questions and issues were raised with respect to Section 8:

1. As Sections 8.2 and 8.3 are relevant to the Temp Spec only, will this language need to be amended or removed in the next iteration?

2. Regarding Section 8.2, should the next iteration reference GNSO processes for any subsequent modifications (or just removed entirely)?

3. Should the text be modified to reflect the relevant relationships, e.g., Joint Controller, Controller, Processor, and relevant flows of registration data, once the EPDP Team discusses these topics?

4. In reference to the referral of GAC advice in Section 8.2, should the language:  (1) be modified to include all relevant GAC advice or (2) require further clarification?

5. In reference to Section 8.1, should the text be amended to reflect

(a) that third party obligations will not be created outside of what is required for minimum GDPR compliance?

(b) the other third-party obligations will arise?

• Is dynamic modification possible? Are any one off modifications foreseen? If so, what impact would this have on the effective date? Board meets periodically so changes could only be taken up then. Is within remit to make changes - out of hands of EPDP Team. How to convert Temporary Specification into GNSO policy recommendations that is the role of the EPDP Team. Once that has happened, any changes would go through the GNSO rules so this section on changes may no longer be relevant. Note that there is also the WHOIS conflicts with local law procedure that could be used for any potential changes, once the temporary specification is converted into a consensus policy.   
• No third-party beneficiaries is part of most ICANN agreements.
• Should the text be modified to reflect the relevant relationships, e.g., Joint Controller, Controller, Processor, and relevant flows of registration data, once the EPDP Team discusses these topics? There are different flows of registration data some of which have a data processing relationship others have a joint-controller relationship. Different agreements need to be in place depending on the relationship.

Action item #3 - Staff to send to the mailing list information concerning the PDP that was the basis for the WHOIS Conflicts with Local Law Procedure.

Action item #4 - Thomas and Emily to work on a framework to outlines the controller designations between ICANN and Contracted Parties or EPDP Team review / consideration.  

Appendix C - Preamble

The following questions and issues were raised with respect to the preamble of Appendix C:

1. Is this inclusion of language, which is based on but not exactly the same as articles of the GDPR, strictly necessary?

2. Should this language be amended to broadly refer to general data protection principles instead of specific references to the GDPR?

3. Should language be examined using the domain name lifecycle as a reference, i.e., should the EPDP team examine all of the processes at different stages by different parties for collection, updating, publication, access and retention, for both purpose and conformity to the GDPR?

4. Should this language be modified as it currently only references some, but not all, of the bases for processing personal data?

5. Should we replace “...such access will at all times comply with the requirements of the GDPR.” with “...such access will comply with the requirements of the GDPR, as applicable”?

6. Should "EBERO" be a party instead of an activity?

7. Within the table, for Public RDDS/WHOIS field, should the language "performance of a contract" be added as a legal justification for Registrar/Registry/ICANN?

• Is the intention of the table to be all-inclusive, or not? If it is, the row specific to "Public RDDS/WHOIS" needs to show specifically as a "Performance of a Contract" as this must be done and the publicly available WHOIS is not based on legitimate interest. If it is not all-inclusive, maybe there should be a clarification included?
• Is contractual obligation a legal justification?
• There may not be as much dissent as reflected in the chart - CPs need to abide by the law. This is very GDPR specific - there are also privacy laws in the works in other countries that may have an impact. Not ideal to quote a summary of legal obligations, better to reference it directly.
• All obligations are subject to applicable law. Concern that the language in this section seems to circumvent requirements and create uncertainty. Nullifying consensus policy should be done elsewhere. Need an effective conflicts with local laws procedure. It is a strange concept for CPs to ask ICANN for permission to comply with applicable laws. Could a strengthened version of the procedure serve as a safety valve? Note that the GNSO Council has already agreed to commence a review of the procedure.

The following questions and issues were raised in reference to Appendix C, Section 1:

1. Should the reference to "obligations to applicable laws and regulation" be deleted in deference to providing certainty and the already existing, WHOIS conflicts with local laws policy?

2. Should the language be amended as it may be misleading since Art.6 of the GDPR is not the only legal basis that can be applied to processing?

3. Is this paragraph describing principles useful as it does not describe specific data handling practices, or their monitoring?

4. Should Section 1 be modified to reference data protection principles more broadly, noting that if the GDPR is updated or amended, the language would need to change?

The following questions and issues were raised in reference to Appendix C, Section 2:

1. Does the term "legitimate interest" require further clarity?

2. Does the clause "except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of Personal Data" need further qualification, as not all data disclosures (e.g., to LEA) are subject to this balancing test?

3. Should the EPDP consider submitting the group's agreed-upon legitimate interests (when agreed) as part of an Article 40 Code of Conduct referral to ensure a greater degree of certainty?

4. Should this language be modified since it only references some, but not all, of the bases for processing personal data? Should the singular reference to children be deleted as it is not possible to tell whether a data subject is a child in current registration data?

5. Does this paragraph add value or should it be deleted?

6. Should the identity of the data controller for WHOIS be identified?

• Need a clear definition of legitimate purpose
• What is a code of conduct referral? Need to outline what would be the basis for our processing? Our state in legitimate interest, the legal basis, etc. could be outlined by the DNS industry which could then be referred to the EDPB to review it as a code of conduct per the GDPR. Code of Conduct should be considered but is not easily achieved. However, if EPDP Team wants to bend what is possible under GDPR, it should get that approval via a Code of Conduct. Should this be part of the discussion of UAM instead of here?
• Are legitimate interests not overridden by privacy rights lawful? Some have now been overridden by privacy rights and as such and no longer considered lawful? It is not only LEAs that have legitimate interests. Also need to further consider ICANN's mission in this regard - fundamental difference in perspectives of what the purpose for collecting data in the first place is.
• Is this group able to determine what is legitimate? Is input from an external authority needed such as EDPB or court cases to provide clarity? Not for ICANN either to make this determination.

The following issues and questions were raised in reference to Appendix C, Section 3.1:

1. Are all parties included in this section about informing data subjects about processing, e.g., ICANN, data escrow agents, and emergency backend registry operators?

2. Should the text be modified to reflect the relevant relationships, e.g., Joint Controller, Controller, Processor, and relevant flows of registration data, once the EPDP Team discusses these topics?

3. With respect to Section 3.1.2, do the terms "necessary and appropriate" require further clarity?

4. With respect to Section 3.1.5, how is this testing to be achieved?

5. Should Section 1, et.seq. be modified to reference data protection principles more broadly, to address changes in GDPR or introduction of other privacy regimes?

The following issues and questions were raised in reference to Appendix C, Section 3.2 - 3.7:

1. Are all parties included in this section about informing data subjects about processing, e.g., ICANN, data escrow agents, and emergency backend registry operators?

2. Should the text be modified to reflect the relevant relationships, e.g., Joint Controller, Controller, Processor, and relevant flows of registration data, once the EPDP Team discusses these topics?

3. In reference to Section 3.7, does the language require more detail in terms of how privacy-by-design should be implemented?

• What is some of this language intended for. For example, 3.5 - is this relates to the initial communication to the registrant? Not related to disclosure for LE? This is just related to general privacy notice, not day to day requests.
• LE - how is LE defined, by whom are they recognised? Premature to discuss this here, but currently focused on local law enforcement. Different scenarios will need to be considered, for example what if request is made from LE in another EU country? Depending on outcome of those discussions, information requirements may need to be updated accordingly.   

The following issues and questions were raised in reference to Appendix C, Section 3.8 - 3.11:

1. Are all parties included in this section about informing data subjects about processing, e.g., ICANN, data escrow agents, and emergency backend registry operators?

2. Should the text be modified to reflect the relevant relationships, e.g., Joint Controller, Controller, Processor, and relevant flows of registration data, once the EPDP Team discusses these topics?

3. Should the EPDP Team further discuss the requirements for security measures to ensure the measures fit the sensitivity of the data?

4. In reference to Section 3.8, should the term "natural persons" be changed to "data subjects"?

4. Should the specific examples in Sec. 3.8.1-3.8.8 be deleted as: (1) they are not mandatory, and (2) they are overly specific and may become outdated?

5. In reference to Section 3.9, is further detail needed with respect to the roles of ICANN, the registrar, the reseller, and/or other data processors as well as the GDRP-mandated 72 notice in the event of a breach?

6. In reference to Section 3.10, does the term "international organizations" require further clarity?

Other Comments

• BC strongly supports the inclusion of each of the issues identified in 1-7 to be addressed in the EPDP, with the exception of the accreditation model, since that work is being pursued on a separate track.  As discussed earlier, providing definition to what is meant by “continued [and]public access” falls squarely within this PDP and must be explored. For example, difference between legal and natural persons, volume limitations, anonymized email. Time should be found for talking about these issues.
• RySG: These issues are not being considered in the Triage exercise. Please note specifically the Objectives & Goals of the GNSO scope document for the EPDP note that these matters are not for initial consideration and the focus of the EPDP team should remain on the Primary queries at this juncture.
• IPC: Apart from the issue identified in point #1 of the annex (related to an accreditation model) which  IPC supports continued discussion of the important issues enumerated in the Annex by the EPDP team.  We understand that the issued address in #1 is subject to the gating questions defined in the charter.

• Need to define 'reasonable' in the context of reasonable access and/or reinventing the term.

5. Overview of triage report, including timeline for review

• See notes above
• Nothing in the triage report should prejudice future discussions of the EPDP Team.

6. Discussion of next steps

• Triage effort has provided insight into the different issues as well as suggestions made.
• Issue summaries and individual comments will be used as a guide.
• Leadership team working on proposed approach for discussion during Thursday's meeting

Homework for next meeting

• Review triage report
• Review input provided on URS/UDRP/Transfer sections - possible topics for next meetings
• Consider comments made in relation to redaction of data elements and further rationale that should be considered for not redacting certain data elements.

7. Confirm action items and questions for ICANN org (if any)

8. Wrap and confirm next meeting to be scheduled for Thursday 23 August at 13.00 UTC. (Initial comments on Triage Report due Friday, 25 August by 19.00 UTC)