- Gnso-epdp-team - lists.icann.org

redacted data
by Mueller, Milton L Aug. 23, 2018

Aug. 23, 2018

I have raised this point several times and I see it being avoided. The redacted data elements are one of the most important aspects of the temp spec. It is imperative that this group identify specifically which redactions we agree with and which ones certain stakeholders don't agree with. This should be very simple to do. I would propose that we add to the Triage report a simple list of each redacted data element, and then list who agrees and disagrees with its redaction. Those opposing a redaction must explain why they think publishing that data is consistent with GDPR and other privacy laws that may apply. My understanding is that the NCSG, RySG, RrSG, ALAC and ISPC all are ok with the current set of redactions under the temp spec. It is therefore incumbent upon the BC, IPC, and GAC to specify which data elements they think should be published and which they are ok with redacting. Again, this seems like a very simple thing to do and as a form of "triage" would be most helpful for the group's progress Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology

2 4

FW: Responses to outstanding questions from the EPDP
by Marika Konings Aug. 23, 2018

Aug. 23, 2018

Dear All, Please find below the input from ICANN Org on the questions that were raised by the EPDP meeting on the 9th, 13th, and 16th. The responses will get posted shortly here: https://community.icann.org/x/ahppBQ. Best regards, Caitlin, Berry and Marika ** 1. Regarding Temporary Specification section 4.4.8 - Supporting a framework to address issues involving domain name registrations: the team requests additional specificity. Does this mean that registrars and registries must support a uniform access mechanism when approved or is there some present requirement? RESPONSE: Section 4.4.8 identifies that addressing issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection using a framework to be developed is a legitimate purpose for the processing of registration data. With regard to the second question, section 4.4.8 does not by itself require that registrars and registries must support a uniform access mechanism when approved. Please note however that section 4.1 of Appendix A does have a requirement for registrars and registries to “provide reasonable access to Personal Data in Registration Data to third parties on the basis of legitimate interests pursued by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.” Separately, section 4.2 of Appendix A requires registrars and registries to “provide reasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful.” Section 4.2 of Appendix A further requires that registrars and registries “provide such reasonable access within 90 days of the date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlier implementation.” 1. Regarding Temporary Specification section 4.4.13 - Handling contractual monitoring requests: which data sets will be required to measure compliance against which contractual provisions? RESPONSE: The data requested by ICANN Contractual Compliance will vary depending on the particular compliance issue. For example, for a registrant’s complaint that a renewal reminder email was not received, ICANN Contractual Compliance may request from the registrar of record a copy of the communication to the Registered Name Holder. 1. Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data? RESPONSE: ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition, we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled list of correspondence received and blogs published thus far, including the topic of each correspondence/blog. 1. In section 5.7 of the Temporary Specification (and other sections), what is the meaning of “reasonable access”? Is it access to personal data reasonably provided? Does “reasonably” relate to the effort necessary to retrieve it? Does it mean how criteria for releasing it are applied, i.e., legitimate and not overcome by the rights of others? Should it just be “access”? RESPONSE: “Reasonable access” is not defined in the Temporary Specification. Generally, compliance with the requirement for registrars and registries to provide reasonable access to non-public registration data is evaluated on a case-by-case basis, based on evidence provided by the requestor, including its request for access to non-public registration data, evidence of the requestor’s legitimate purpose for accessing the non-public registration data, the timing and content of the contracted party’s response to the request (if any), and any other information or evidence relevant to assessing the request and response. 1. Believing that ICANN org has its own GDPR implementation plan in place, it would be helpful for our group to understand the elements and implementation status of the plan so that the Team can draw comparisons to the EPDP Team’s work. RESPONSE: ICANN org has been open and transparent about its work to get ready for GDPR both in terms of domain registration data collected and processed by registrars and registries (which we refer to as “external” GDPR readiness), and personal data processed by ICANN org in the ordinary course of the organization’s operations such as finance, meetings, and human resources (which we refer to as “internal” GDPR readiness). ICANN org’s plans and activities regarding “external” (domain registration data) GDPR compliance have been openly and transparently blogged and posted on the ICANN Data Protection page at <https://www.icann.org/dataprotectionprivacy>. On 5 June 2018, ICANN’s CEO and President, Göran Marby, shared information about ICANN org’s “internal” efforts to be GDPR compliant via a blog. In the blog, Göran shared that several of ICANN’s policies have been updated. These include an updated online Privacy Policy<https://www.icann.org/privacy/policy>, a revised Terms of Service<https://www.icann.org/privacy/tos>, a revised Cookies Policy<https://www.icann.org/privacy/cookies>, a new Notice of Applicant Privacy<https://www.icann.org/privacy/applicantnotice> (relating to data processed for employment applications), and a revised New gTLD Program Personal Data Privacy Statement<https://newgtlds.icann.org/en/applicants/agb/program-privacy>. Additionally, ICANN org has also rolled out internal changes to the way we handle personal data, from data processing arrangements with vendors to our various personnel policies. Read the full blog here<https://www.icann.org/news/blog/data-protection-privacy-update-icann-s-gdpr…>. 1. The Council envisioned, via the EPDP Charter, to have direct participation of ICANN org liaisons, within the EPDP Team. As we leave the Triage and head into substantive detail, do the ICANN liaisons see a role or specific set of actions for ICANN supporting the team? RESPONSE: Section III of the EPDP Charter describes the role of ICANN org liaisons as “ICANN Staff Liaison: The ICANN Org GDD and Legal Liaisons are expected to provide timely input on issues that may require ICANN Org input such as implementation-related queries. The ICANN Staff Liaisons are not expected to advocate for any position and/or participate in any EPDP Team consensus calls.” In line with this description of ICANN org liaisons’ role, Göran Marby’s response<https://www.icann.org/en/system/files/correspondence/marby-to-forrest-et-al…> to the GNSO Council regarding a request for appointment of ICANN org liaisons confirmed the scope of participation of the ICANN org liaisons as “Trang Nguyen from ICANN organization’s Global Domains Division and Dan Halloran from ICANN’s legal team will join the working group’s mailing list and the group’s calls to coordinate responses to requests for GDD or legal input as needed to support the working group’s deliberations. Such requests will ordinarily be responded to in writing, following consultation with internal and external experts as appropriate.”

2 2

proposed modification to triage report
by Mueller, Milton L Aug. 23, 2018

Aug. 23, 2018

A simple one. Point #8: Current wording: 8. ICANN relies on its mission and bylaws to justify the requirement that registration data be disclosed in certain circumstances, but the EPDP team seeks supplemental information from ICANN to make it clear why the mission and bylaws make such disclosures necessary. 8. ICANN relies on its mission and bylaws to justify the requirement that registration data be disclosed in certain circumstances, but the EPDP team seeks supplemental information from ICANN to determine whether or not the mission and bylaws make such disclosures necessary. Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology

1 0

Proposed agenda + accompanying materials for EPDP Team Meeting - 23 August 2018
by mail＠berrycobb.com Aug. 23, 2018

Aug. 23, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting, which is scheduled for Tuesday, 23 August at 13.00 UTC. Accompanying materials are also attached. Best regards, Marika, Caitlin, and Berry EPDP Meeting #7 Agenda Thursday, 22 August 2018 1. Roll Call & SOI Updates 2. Welcome and Updates from EPDP Team Chair 3. Preliminary input on Triage Report (deadline for input: Friday, 24 August at 19:00 UTC) 4. Proposed approach for moving forward, including review of proposed project plan 5. Commence deliberations and review of Appendix D – Uniform Rapid Suspension (see scorecard attached) 6. Commence deliberations and review of Appendix E – Uniform Domain Name Resolution Dispute Policy (see scorecard attached) 7. If time allows, commence deliberations and review of Appendix G: Supplemental Procedures to the Transfer Policy (see scorecard attached) 8. Wrap and confirm next meeting to be scheduled for Tuesday 28 August at 13.00 UTC.)

3 2

Face-to-face meeting attendance
by Kurt Pritz Aug. 22, 2018

Aug. 22, 2018

Hi Everyone: Here is where I am on attendance at the face-to face meeting (and for discussion tomorrow). I have given this considerable thought, writing a 1400+ word memo / analysis of the different options to the GNSO leadership. Then, I re-thought all of that to come up with an alternative approach. I believe that the best option is: Members are invited and will be provided travel support. 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. 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. 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: that member and the alternate can attend the full meeting but only one will be designated as a participant at any one time the alternate will not be given travel support I think this is the best option for several reasons: It provides travel support commensurate with membership It allows alternates, when needed, to keep up with the proceedings It is economical compared to other solutions It will be easy to manage who participates and when Will not materially impact the meeting room size or planning by the ICANN Meetings Team Thinking of other options: If alternate participation is curtailed beyond this, team effectiveness might be hobbled. If alternative participation is expanded beyond this, meeting costs might escalate and logistics would become complicated. My second choice would be to make the meeting completely open. In this case there would be two sets of attendees: members and observers. The separation would be easy to manage The goal of keeping alternates up to speed could be realised. Openness and transparency would be assured. However, costs and logistic support requirements would increase, taking budget from more important needs Thanks and regards, Kurt

3 2

ICANN Procedure for Handling WHOIS Conflicts with Privacy Law
by Marika Konings Aug. 22, 2018

Aug. 22, 2018

Dear All, Per the action item from today’s meeting, please find attached the staff assessment and next steps report on the Revised ICANN Procedure for Handling WHOIS Conflicts with Privacy Law which was published in May 2017. As there were specific questions in relation to the origin of the procedure, I’ve excerpted the background section from this document below. As noted, the GNSO Council has already agreed to form an Implementation Advisory Group to review the procedure and adopted a charter for this effort in February of this year (see https://gnso.icann.org/en/council/resolutions#201802) However, due to workload issues and the pending EPDP, the Council delayed the call for volunteers and agreed during its most recent meeting to decide when the call for volunteers should be launched following the publication of the Initial Report on the Temporary Specification by the EPDP Team. Best regards, Caitlin, Berry and Marika ============================ Background (from https://www.icann.org/en/system/files/files/whois-privacy-conflicts-procedu…) In November 2005, the GNSO concluded a policy development process<https://gnso.icann.org/en/issues/whois-privacy/council-rpt-18jan06.htm> (PDP) on Whois conflicts with privacy law which recommended that “In order to facilitate reconciliation of any conflicts between local/national mandatory privacy laws or regulations and applicable provisions of the ICANN contract regarding the collection, display and distribution of personal data via the gTLD Whois service, ICANN should: 1. Develop and publicly document a Procedure for dealing with the situation in which a registrar or registry can credibly demonstrate that it is legally prevented by local/national privacy laws or regulations from fully complying with applicable provisions of its ICANN contract regarding the collection, display and distribution of personal data via Whois. 2. Create goals for the procedure which include: * Ensuring that ICANN staff is informed of a conflict at the earliest appropriate juncture; * Resolving the conflict, if possible, in a manner conducive to ICANN's Mission, applicable Core Values, and the stability and uniformity of the Whois system; * Providing a mechanism for the recognition, if appropriate, in circumstances where the conflict cannot be otherwise resolved, of an exception to contractual obligations to those registries/registrars to which the specific conflict applies with regard to collection, display and distribution of personally identifiable data via Whois; and * Preserving sufficient flexibility for ICANN staff to respond to particular factual situations as they arise”. The ICANN Board of Directors adopted the recommendations in May 2006 and directed staff to develop such a Procedure. A draft Procedure was posted for public comment, and input was specifically solicited from the Governmental Advisory Committee (GAC). The GAC recommended adding a provision, which was included as section 1.4 in the procedure, urging a registrar or registry to work with relevant national governments to ensure adherence to domestic and international law, as well as applicable international conventions. If the Whois requirements require changes that ICANN determines prevent compliance with contractual Whois obligations, ICANN may refrain, on a provisional basis, from taking enforcement action for non-compliance, while ICANN prepares a public report and recommendation and submits it to the ICANN Board for a decision. Given that to date no registrar or registry operator has formally invoked the Whois Procedure, and yet numerous concerns have arisen from contracted parties and the wider community, ICANN launched a review in 2014, as provided in the Whois Procedure’s final clause. Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

5 7

***REMINDER*** Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 23 August 2018 at 13:00 UTC
by Julie Bisland Aug. 22, 2018

Aug. 22, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesday's and Thursday's at 13:00 UTC via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/TRhpBQ Kind Regards, Andrea Glandon

1 0

Re: [Gnso-epdp-team] For your review - EPDP Team Communications Plan
by Marika Konings Aug. 21, 2018

Aug. 21, 2018

Not having seen any further comments or suggestions, staff will move forward with the implementation of this plan as proposed. Of course, suggestions will remain welcome. Best regards, Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Wednesday, August 15, 2018 at 10:09 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] For your review - EPDP Team Communications Plan Dear All, Following yesterday’s meeting, please find attached for your review the proposed EPDP Team Communications Plan that has been developed with the support of our colleague Arial Liang. You are encouraged to provide any suggestions, comments and/or input you may have. Thanks, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Notes and action items from today's EPDP Team Meeting - 21 August 2018
by Marika Konings Aug. 21, 2018

Aug. 21, 2018

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Thursday, 23 August, 13:00 UTC. Best regards, Caitlin, Berry, and Marika =============== EPDP Team Meeting #6 Tuesday, August 21, 2018 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://community.icann.org/x/2IpHBQ. 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 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) Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Recordings, Attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Tuesday, 21 August 2018
by Andrea Glandon Aug. 21, 2018

Aug. 21, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 21 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/FxdpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-21aug18… AC Recording: https://participate.icann.org/p27r8mt24t5/<https://participate.icann.org/p27r8mt24t5/?OWASP_CSRFTOKEN=863031ed14eb3300…> ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ [community.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> Thank you. Kind Regards, Andrea Glandon

1 0