August 2018 - Gnso-epdp-team

FW: Questions for ICANN Org from EPDP Team Meeting - 9 August 2018
by Marika Konings Sept. 13, 2018

Sept. 13, 2018

For your information. The responses to these questions will be posted on the related wiki page: https://community.icann.org/x/ahppBQ. Best regards, Caitlin, Berry and Marika From: Trang Nguyen <trang.nguyen(a)icann.org> Date: Tuesday, August 28, 2018 at 09:12 To: Marika Konings <marika.konings(a)icann.org>, Daniel Halloran <daniel.halloran(a)icann.org>, Erika Randall <erika.randall(a)icann.org> Cc: Berry Cobb <Berry.Cobb(a)icann.org>, Caitlin Tubergen <caitlin.tubergen(a)icann.org> Subject: Re: Questions for ICANN Org from EPDP Team Meeting - 9 August 2018 Hi Marika, Please see below responses to the question from the 21 August meeting. Best, Trang ** QUESTION: 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. RESPONSE: The Board reaffirmed<https://www.icann.org/resources/board-material/resolutions-2018-08-21-en> the Temporary Specification with no changes on 21 August 2018. QUESTION: 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? RESPONSE: The procedure was most recently invoked for .FRL in late 2017. However, the request was withdrawn prior to an outcome when .FRL agreed to comply with the requirements of the Temporary Specification. The request was withdrawn early on in the process so ICANN org had not conducted a formal review to identify specific issues with the procedure. The procedure was also previously attempted by .FRL in late 2016 but the request did not meet the requirements to utilize the procedure. At the time, requirement to trigger the procedure was that the contracted party must have received “notification of an investigation, litigation, regulatory proceeding or other government or civil action that might affect its compliance.” However, .FRL was not subject to any such proceeding at the time, and the procedure could not be used. QUESTION: 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. RESPONSE: The latest Draft Framework for a Possible Unified Access Model for Continued Access to Full WHOIS Data – For Discussion<Draft%20Framework%20for%20a%20Possible%20Unified%20Access%20Model%20for%20Continued%20Access%20to%20Full%20WHOIS%20Data%20–%20For%20Discussion> addresses the question of “whether or not logs of query activities concerning non-public data must be available to the registrant upon request except if prohibited by a relevant court order or legal requirement.” Please refer to Section 8 of the draft framework for more information on this topic. The draft framework is published for community discussion and to seek guidance from the European Data Protection Board. With a better understanding of the law, we will all be well positioned to develop, implement and enforce a legally sound, consistent unified model for access to non-public registration data, and lower the risk for the contracted parties in order for them to be able to accept such model.

5 4

Factual studies starting to shoot down the "going dark" panic
by Mueller, Milton L Sept. 6, 2018

Sept. 6, 2018

Relevant to the work of this group is the following study from Recorded Future. https://www.recordedfuture.com/gdpr-spam-impact/?utm_content=76363539&utm_m… Entitled "90 Days of GDPR: Minimal Impact on Spam and Domain Registration" Dr. Milton Mueller Professor, School of Public Policy Georgia Institute of Technology [IGP_logo_gold block_email sig]<http://www.internetgovernance.org/>

6 11

Re: [Gnso-epdp-team] Request for Adobe Access (Read-only) for Alternates
by Alan Greenberg Sept. 5, 2018

Sept. 5, 2018

I support Kristina's proposal. The graphics displayed can be important. Alan At 13/08/2018 04:29 PM, Rosette, Kristina via Gnso-epdp-team wrote: >All, > >On behalf of the RySG, Im writing to request >that EPDP Alternates be granted read-only access >to the Adobe Connect room. We are finding that, >without access to the Adobe room, it is >difficult for the Alternates to follow the >meeting fully, to assist Members during the >meeting, and to prepare for direct participation (when doing so for a Member). > >If it would be possible for us to add this >request to our agenda for tomorrow (as an AOB), >the RySG would appreciate it. I apologize for >the short notice, but I had drafted another >version of this email on Friday, where it got stuck in my pre-vacation Outbox. > >Thank you. > >Kristina > >Kristina Rosette >Senior Corporate Counsel, IP Domains ><mailto:rosettek@amazon.com>rosettek(a)amazon.com | 703.407.1354 > >_______________________________________________ >Gnso-epdp-team mailing list >Gnso-epdp-team(a)icann.org >https://mm.icann.org/mailman/listinfo/gnso-epdp-team

3 3

Section 4 of Temp Spec.
by Kavouss Arasteh Sept. 2, 2018

Sept. 2, 2018

Dear Kurt Dear All Thanks to those who have generously volunteered to look st Section 4 , in particular, certain sub paragraph of that section as well as corresponding parts of Appendix C Having said that I wish to emphasise that it is nit expected to receive new draft from scratch ( total redrafting ) but merely suggesting necessary amendments to the existing text to maintain the relative consistency with the initial documents In addition, the distinguished drafter need to take into account comments already received in TIRAGE from. Various stakeholder groups and ACs as well as those expressed during the discussion( transcriptions, recordings and chats Moreover, it is absolutely necessary to avoid overlapping, repetitions and double application as may contained in other sub paragraphs drafted by others. Some sort of coordination thus nay be required. These suggested drafts should possibly made available 48 hours before the Thursday ( 11th ) meeting which needs to be seen by Kurt before . Agenda of the next meeting should be limited to certain specific issue and not discussing various points at the same time. Attention of respectful drafters are drawn to the fact that several adjectives or terms used which are required to be clearly defined to facilitate the implementation of the suggested / modified sub paragraphs This was raised st various instances and raised by some sub teams Best regards Kavouss

4 5

Pre-emptive request for our consideration of Appendix D&E
by Alan Woods Aug. 31, 2018

Aug. 31, 2018

Dear Kurt and team, In advance of our substantive discussions on the elements of the RPMs within the Temp Spec (Appendix D and E), in the interests of not delaying our deliberations at that time, I believe it prudent for the EPDP team to have the opportunity to review the agreements that ICANN has with the RPM providers, (or at least the Data Processing Agreements), so as to fully consider all safeguards in place, thus tipping the balance in favor of disclosure of the data to the RPM providers. As we already indicated in our triage response, we generally have no issue with the appendix (notwithstanding some process changes on the RPM review side being likely necessary). This does not absolve us however from fully considering the data flow, to confirm the appendices. Our task should be to do a thorough assessment of the required disclosure; documenting the purpose and legal basis for the disclosure; the safeguards applicable to the disclosure; and, in this case, complete our a consideration of the balance of the data subject rights. As the contracted parties do not maintain a direct contractual relationship with any RPM provider, we will therefore need to consider the applicable data processing agreement, to confirm how that data will ultimately be processed by the RPM provider (i.e. drawing inspiration from those elements required under Art 28 of the GDPR - Data Processor Requirements). This will allow for our transparent and well rounded consideration of the data flow, the safeguards in place, leading to a strong outcome for the EPDP consideration of the appendices. As such, I would request that, in the interests of time, the EPDP now requests sight of the relevant documents (whether that be the full agreement or the applicable data processing agreements) from ICANN so that we can duly consider it in the assessment of the appendices when we arrive at that point, in the hopes of moving swiftly along. Kind regards, Alan Woods [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

2 1

Re: [Gnso-epdp-team] Responses to early input request
by Marika Konings Aug. 31, 2018

Aug. 31, 2018

Note that early input from the NCSG has just been received as well and has been posted on the same page: https://community.icann.org/x/Ag9pBQ. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Monday, August 27, 2018 at 14:48 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Responses to early input request For your information, in response to the request for early input, a response was received from the SSAC. Their response, and any further input that may be received has been posted here: https://community.icann.org/x/Ag9pBQ. Staff will make sure to update the background documents section on the wiki with the documents referenced in the SSAC response. Best regards, 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-…>.

2 1

Suggestion to facilitate writing and review replacement language for Section 4.4
by Mark Svancarek (CELA) Aug. 31, 2018

Aug. 31, 2018

Dear Kurt and Team: To get us started on the daunting task of drafting replacement language for Section 4.4 of the Temp Spec, we propose to split the processing topics of section 4.4 into categories which parallel the structure of GDPR. The two processing categories we propose are: 1. Those which support the purposes of controllers and others related to the performance of their contracts (registrars, registries, and ICANN) 2. Those which support the purposes of third parties under applicable legal grounds (performance of contract, consent, and legitimate interest) Some items in Section 4.4 of the existing Temp Spec will apply to both categories; some will apply to only one. Even when an item applies to both categories, we propose to discuss the appropriate language separately and in the context of the specific category only. By removing conflation of purposes between parties, this split will facilitate discussion and lead to a more productive drafting process. Further discussion will determine whether ICANN needs to be uniquely broken into its own third category, or whether this two-way split will suffice. A "strawman" breakdown is as follows: Section of existing Temp Spec Processing to achieve the purposes of Controllers Processing to achieve the purposes of Third Parties 4.4.1 Yes - 4.4.2 Yes Yes 4.4.3 Yes Yes 4.4.4 Yes - 4.4.5 Yes Yes 4.4.6 Yes - 4.4.7 Yes - 4.4.8 Yes Yes 4.4.9 Yes Yes 4.4.10 Yes Yes 4.4.11 Yes - 4.4.12 Yes Yes 4.4.13 Yes - /marksv

1 0

FW: [Ext] ICANN News Alert -- ICANN Releases its Second Report on Global Legislative and Regulatory Developments
by Marika Konings Aug. 31, 2018

Aug. 31, 2018

For your information. From: ICANN News Alert <no-reply(a)external.icann.org> Reply-To: "no-reply(a)external.icann.org" <no-reply(a)external.icann.org> Date: Thursday, August 30, 2018 at 17:46 To: Marika Konings <marika.konings(a)icann.org> Subject: [Ext] ICANN News Alert -- ICANN Releases its Second Report on Global Legislative and Regulatory Developments [ICANN][icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org_&d=DwMFaQ…> News Alert https://www.icann.org/news/announcement-2018-08-30-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_ann…> ________________________________ ICANN Releases its Second Report on Global Legislative and Regulatory Developments 30 August 2018 ISTANBUL - 30 August 2018 - The Internet Corporation for Assigned Names and Numbers (ICANN) published today the second report [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…> [PDF, 214 KB] l highlighting a limited list of recent and pending legislative and regulatory initiatives on privacy/data protection and cybersecurity across the world. The report is a continuation of the initiative launched earlier this April, to identify legislative efforts across the globe early-on to raise awareness within ICANN and consider potential impacts, including how these legislative initiatives may have unintended consequences, which may be avoided. As a result of the community discussions over the past year or so leading up to the GDPR going into full effect, ICANN CEO and President Göran Marby committed to identify key legislative efforts around the globe while in their earlier stages. To this end, ICANN org initiated [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…> reporting efforts on global legislative and regulatory developments during the third quarter of FY18. The first report [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_syste…> [PDF, 97 KB] was a limited list of some recent legislative and regulatory initiatives around the world that relate to privacy/data protection and cybersecurity issues and that could impact ICANN's mission, operations or issues within ICANN's remit. It was the first product of a realization that ICANN, as both an org and a community, must pay closer attention to potential legislative efforts of interest across the world. The initial report received wide attention with a viewership of over six hundred unique visits. The community feedback on the report was positive, which paved the way for the continuation of the report on a quarterly basis. We would like to take this opportunity to thank everyone who has reviewed and provided feedback on the first report. We look forward to hearing from you about any high-impact developments in the e-privacy and cybersecurity ecosystem that should be tracked in future reports. You can send your comments and/or information about new developments in your region to trackingfeedback(a)icann.org<mailto:trackingfeedback@icann.org>. About ICANN ICANN's mission is to help ensure a stable, secure and unified global Internet. To reach another person on the Internet, you have to type an address into your computer - a name or a number. That address has to be unique, so computers know where to find each other. ICANN helps coordinate and support these unique identifiers across the world. ICANN was formed in 1998 as a not-for-profit public-benefit corporation and a community with participants from all over the world. Manage Your Subscription [app.icontact.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__app.icontact.com_icp_mm…> This message was sent to marika.konings(a)icann.org from no-reply(a)external.icann.org ICANN News Alert ICANN 12025 Waterfront DriveSuite 300 Los Angeles, CA 90094-2536 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [iContact - Try it for FREE][icontact.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icontact.com_signu…>

1 0

Notes and action items from today's EPDP Team Meeting - 30 August 2018
by Caitlin Tubergen Aug. 31, 2018

Aug. 31, 2018

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 4 September, 13:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting #9 Thursday, 30 August 2018 High-Level Notes and Action Items Regarding progress on the Purposes for Processing Data: Registrars will rewrite section 4.4 to align the purposes for data processing with current data collection processes and the domain name lifecycle. It is requested that the draft be completed in time for the meeting on Tuesday, 4 Sept so that the rest of the team can review it. For sections 4.4.2, 4.4.8 and 4.4.9, it was agreed to take those purposes for accessing data out from under the heading, “Purposes for Processing Data” and place it in another section of the Policy that is being developed. The Support Team will recommend alternatives for identifying those access needs in the new Policy in time for the 4 September meeting. The support team will facilitate the creation of a team to consider a re-drafting of section 4.4.8. Several team members volunteered to participate, and Alex Deacon and Amr Elsadr volunteered to lead. The Support Team will develop the time requirements for this team to finish its work, taking into account the project plan and delivery requirements. The team will have a “narrow remit,” i.e., to draft the purpose for data disclosure for the reasons set out in section 4.4.8. Regarding other sub-sections of 4.4 the following team members offered to propose revised language for the below-mentioned sections: § 4.4 (introductory paragraph): Alex Deacon § 4.4.2: Amr Elsadr § 4.4.9: Ashley Heineman, Kavouss Arasteh Regarding Appendix C, Data Processing Requirements: Alan Woods will provide a draft recommendation to ICANN that the subject matter be taken out from consideration by this group and folded into current CPH-ICANN negotiations regarding registration data elements of the RAA and RA. This writing should address Margie’s intervention that certain elements of Appendix C remain under the purview of this group, e.g., Disclosure of non-public RDDS/WHOIS to third parties. Additionally, Alex Deacon will compose amendments to Appendix C, section 2, Lawfulness of Processing, that includes all GDPR mechanisms that allow processing of data. Other items: Support Team to adapt Thomas’s spreadsheet to aid in future discussion of data elements. We will also re-affirm the timing of this discussion to ensure it is prioritized. Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? Notes 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 Please 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 Triage report - planning to create an updated, truncated version of the report to be distributed shortly Please ensure that any chat during the meeting is relevant to the discussion and does not distract from the speaker. 3. Review proposed next steps and action items on 4.4 a. Consider any input form the EPDP team that would include specific recommendation for amendments to the temporary specification for: 1. Registrar / Registry / ICANN processing of data: clarifying the elements proposed in the ICANN-developed specification 2. Third party processing where more specificity was requested At the end of the preamble, some suggested the text, "and only for the following legitimate purposes", may be unduly restrictive because of (1) potential new privacy laws in the future; and (2) updated advice from courts/DPAs. Accordingly, a proposed tweak may be, "and for legitimate interests not outweighed by the fundamental rights of relevant data subjects, consistent with GDPR." Feedback from EPDP Team: The point of the comment is when only focusing on legitimate interests, we are leaving out other lawful processing described in Article 6(1) of the GDPR - such as 6(1)(b), 6(1)(c), and 6(1)(f). Action item: Alex to propose updated language. Problem with 4.4.2 and 4.4.8 and 4.4.9 is that this is an access issue, not an ICANN purpose issue. The legitimate interest list is trying to incorporate third party legitimate interests into purpose definitions. If you try to accommodate access concerns by incorporating this into ICANN purposes, this is making the conflation DPAS explicitly warned against. Accordingly, this needs to be separated. If these sections are not in the correct part of the Temp Spec, where would these sections go? These sections appropriately belong in the access section. Clarifying question: we transitioned out of the welcome message into the substantive discussion. We are beginning on a wording issue, seemingly based on triage comments. What is the objective here? Are we trying to edit 4.4 and 4.4.2? This was an experiment is see if the language was an easy fix the team could agree to. It appears we are commingling purposes and legitimate interests for access, and we can explore separating these sections. We cannot provide access later, unless we have the data to start with. We may need to lower the rhetoric -- comments like "we will never agree to something" is unhelpful for forward progress. When we speak of data processing, we do not have to go through what a legitimate interest is. For data processing, we need to come up with what we mean by data processing at this stage. Are we talking about data collection? If so, this needs to be very narrowly defined - it needs to be based on ICANN's mission and purpose. Re: Thomas' email which mentions slicing and dicing, there are paths to obtain information. We must remember that payment information is collected for other registrar/registry purposes. We have to make a distinction making access to the data separate. We should focus now on collecting/processing of the data, and put access aside for now. We may need to add a few qualifiers to the text, such as ICANN's legal basis for processing this data. When we’re looking at bylaws references in the Temp Spec and any successor, we need to look at what the bylaws actually say and what they mean. This entire section appears to be hastily written. We might consider rewriting this from scratch, rather than tweaking current language. In the previous meeting and here, we need to bifurcate the sections in 4.4 et. seq. and create the first list for data processing for Ry/Rr. In reading through the triage comments, registrars frequently objected to this section, as there is a set of data collected for the purpose of dealing with the registrant, and this list may not be the correct list for dealing with these issues. Instead, we might consider rewriting this entire section to better align with Ry/Rr purposes. Kurt asked contracted parties to come up with a better way of looking at this type of data. Action item: Registrars to to rewrite section 4.4 in an attempt to align the text with actual business practices. The Temp Spec was written as a reaction to GDPR. It’s not written as policy recommendations. The intent here was to bolt on GDPR compliance to the existing system. Taking what is there and redlining it will be an unsuccessful endeavor. The starting point here is to make sure the entire group has a common understanding of what it means to deliver the service of a domain name registration to a registrant, as that will be the starting point of the purposes. There may be other purposes involved, but the first purpose is the delivery of the service of a domain name registration to a registrant. What clarification or direction is needed from the EPDP team for registrars to move forward with a conversation with your stakeholder group? Registrars will put pen to paper and circulate to the group. Perhaps we do not start with purposes, we start with what it means to deliver the service to avoid the problems the RDS group experienced. Re: ICANN Contractual Compliance, what does this mean, and what activities are involved? Like a third party, ICANN would have to demonstrate a legal basis to access this information. ICANN is a data controller, and ICANN collects data from contracted parties based on the RA and RAA. ICANN just needs to vet out their purposes and their legal basis to access this information. ICANN has solid purposes, but they need to be clear in what those purposes are. ICANN as a controller and as a party to the contract has a performance of contract purpose that is under GDPR. It is written in the bylaws and a commitment ICANN made during the transition. It is inappropriate to limit what ICANN can get access to for the purposes of enforcing the contract. We talked about whether ICANN has access to the data, and I believe the Temp Spec took away ICANN’s right to thick WHOIS, but only thin WHOIS. The Temp Spec did remove thick data transition, but that data is part and parcel of our discussions. There is still disagreement over § 4.4.8. This data disclosure does not belong under the purposes. Should the group rewrite these access questions? Where in our policy should these sections go so that we can preserve this right away? One option would be to move it to Appendix A, Section 4. Thinking about earlier comments, we may want to consider using a tool such as Thomas’s spreadsheet or concrete input from Rys/Rrs, and other groups would assist in drafting something so that when we come together next time, we are focused on specifics. The spreadsheet deals with data elements that support each purpose. Thoughts on path forward – flesh out purposes of data processing first and then identify data required to fulfill those purposes. If we can get the feedback from the RrSG to furnish the aforementioned homework quickly, we can move to the discussion on data elements shortly. Action: Alex as lead to clarify 4.4 Action: GAC as lead to rewrite section 4.4.9 We do not have a framework for investigation of cybercrime. We do have an obligation to support investigation of cybercrime, but it is not our framework, and this is an overreach in Section 4.4.8. This needs to be separated out and reworded. This discussion appears to be jumping around a bit. How are we going to reach a final product? Our end goal here is policy recommendations. Ad hoc debate of various sections of the temp spec may not help us reach our end goal. We’re talking about Section 4.4 today because we agreed to talk about purposes for processing first. However, we can use a spreadsheet as a tool to have a concrete discussion about data. To close this out, for third party uses of data, does anyone think these need to be adjusted? 4. Begin discussion on Appendix C For each section, we will refer to the Triage survey and meeting comments as a guide for considering to amend the specification section. We might then form a rough consensus for the content of edits and assign a small team (1-3) people to create a revised version for the next meeting. Breaking the Appendix into its parts: a. Preamble EPDP Team Feedback: Appendix C includes a chart which includes gTLD processing activities We can guide the discussion of what was capture in the triage EPDP Team Feedback: Amend the preamble, then amend the table. Take these in order. In reference to the preamble, some of the comments note that restating the GDPR (but not precisely) is not helpful. Should this match the GDPR, or should it be removed? Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? Perhaps this should be handed back to ICANN Legal for review – send the chart back to ICANN and have that married with the other discussion on what other processing needs to take place. Should this be examined with the domain name lifecycle as a reference? When you put a point on discussion in the debate, it would be helpful to have one or two leads to put pen to paper and then share with the group for discussion. b. gTLD Processor Activity Chart c. Section 1 (Principles for Processing) Section 2 (Lawfulness of Processing) EPDP Team Feedback: Should the reference to applicable laws and regulations be removed? Should Section 1 in principles for processing might include principles from GDPR other than 6.6? Should it reference data principles more broadly? In Section 2, should there be an LEA carve out for the balancing test? Should we go back once we have agreed upon legitimate interests, should we go do an Article 4 code of conduct referral? How do we move this forward? Should we post these questions online and ask for responses? Proposal to change each controller “shall observe” instead of “will observe” On Section 2, it focuses on legitimate process and does not include other lawful purpose, so it needs to be changed similar to Section 4. The LEA carve out could then be removed. We have to have a discussion on the critical part – we are allowed to consider the needs of others if we have a justification. Are we allowed to look at others’ needs in WHOIS or not? There seems to be a copy/paste of Article 28 of the GDPR. This should be a suggestion to the GNSO that it should be added to the contract, not in here. This is a contractual matter and should not be in the policy. The feedback is not that we not consider other legitimate interest, but rather, to not conflate the legitimate interests of third parties with ICANN’s purposes. This Appendix may not be necessary once the agreement is re-negotiated with the contracted parties, though certain elements may still be necessary. It is not that we cannot consider third party interests, it is that they should not be conflated with ICANN’s interests. The fact that we take third party interests in the data into consideration does not mean that we collect data with third party interests in mind. Cooperation is the key here. · d. Deliberate on Sections 3.1, 3.1.1 – 3.1.6 (Specific Controller Processing requirements) e. Deliberate on 3.2 – 3.11 (Specific Controller Processing requirements) Discuss next steps for dealing with input on Appendix C 5. Confirm action items and questions for ICANN Org, if any Question for ICANN Org: Language in the preamble is similar but different from the GDPR. What was the thinking in writing it this way? 6. Wrap and confirm next meeting to be scheduled for Tuesday 4 September at 13.00 UTC.

3 4

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

Aug. 30, 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 Thursday, 30 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-30aug18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p7roeo6r513/<https://participate.icann.org/p7roeo6r513/?OWASP_CSRFTOKEN=1878425a032e0b15…> ** 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

Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 04 September 2018 at 13:00 UTC
by Andrea Glandon Aug. 30, 2018

Aug. 30, 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/0gONBQ Kind Regards, Andrea Glandon

1 0

Project plan posted on wiki
by Marika Konings Aug. 30, 2018

Aug. 30, 2018

Dear All, Several of you asked about the project plan – the latest version has now been posted on the related wiki page: https://community.icann.org/x/2opHBQ. As further updates may be made over time, any updates will be posted on this page. Best regards, 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

Slicing and dicing
by Thomas Rickert Aug. 30, 2018

Aug. 30, 2018

All, A few points below that I committed to send to the list. Data matrix During our last call, we have discussed a proposed methodology to slice and dice the work and document what data elements can be processed for what purpose based on what legal basis with what rationale. I have attached an attempt to capture that. This only covers the framework for capturing the collection of data by the registrar and the transfer from registrar to registry. The table would need to be extended to cover the additional processing activities, but at this stage it shall serve only to illustrate an approach where we could all feed our ideas into one document with a level of granularity that prevents us from conflating issues. 4.4.8. Also, when we discussed 4.4.8. I proposed we also discuss the purpose in concrete terms. Milton asked me to give an example. 4.4.8 reads: Supporting a framework to address issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual property protection only. Many in the group think this is too broad. So let’s take IP protection. If the purpose included the publication of all data of potential cybersquatters, including their payment data to allow for investigators to do their work efficiently, I think we would all agree that that would go too far. Yet, one could think that such action was covered by the purpose of 4.4.8.. On the other hand, if in the case of a UDRP proceeding, the data of the registrant shall be disclosed to the dispute resolution provider, we would probably (not to say hopefully) all agree that this would be fine. So my plea is that when we are talking about all those issues that could fall under 4.4.8. - let’s come up with concrete suggestions as to what the parties involved are supposed to do. We should all put some thought into that. What shall be done in the area of consumer protection e.g.? Are we talking about collection of additional data elements? Disclosing them to third parties? Retaiing them for a longer period? In other work, what could or should consumer protection entail in the gTLD world? Same for the other aspects in 4.4.8. Playbook Mark asked during the last call to send a link to the eco Playbook. Here it is: eco GDPR Domain Industry Playbook <https://www.eco.de/wp-content/uploads/2018/02/eco-domain-industry-playbook-…> We have gone through a lot of the exercises that this group will need to go through, so I encourage you to take a look at it. Maybe we can reuse parts of it to expedite our work. Don’t get me wrong - I am not trying to sell you the approach in the Playbook, but I think it can be a good basis to argue over certain questions. Finally, I happen to be one of the authors. The good sentences have likely been written by others. The things you might not like surely come from me. Best, Thomas

6 6

Proposed Agenda - EPDP Team Meeting #9 - 30 August at 13.00 UTC
by Caitlin Tubergen Aug. 29, 2018

Aug. 29, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday, 30 August at 13.00 UTC. Additionally, please find the discussion summary index for Appendix C attached. Best regards, Marika, Berry, and Caitlin EPDP Meeting #9 Agenda Thursday, 30 August 2018 Roll Call & SOI Updates Welcome and Updates from EPDP Team Chair Review proposed next steps and action items on Section 4.4 - Lawfulness and Purposes of Processing gTLD Registration Data For Registrar-Registry-ICANN Contract Purposes (for collection), all, but registrars specifically, are asked to provide input on whether there are additional legitimate reasons why ICANN may need to require contracted parties to collect data from registrants? Should these purposes be re-grouped in some way to better capture their relevance, necessity and the data needed to support them? For Third Party Purposes (for access), the EPDP Team is expected to weigh in on whether the purposes enumerated here are valid and legitimate? Do those purposes have a corresponding legal basis? Do these purposes need to be reviewed for clarity? Note that any discussion on the safeguards and limitations in relation to access necessary to ensure GDPR compliant disclosures would happen after the gating questions have been answered. Once step 2 and 3 have been completed, the EPDP Team will need to review how this separation of purposes is to be reflected in 4.4 and what updates, if any, need to be made to the preceding sections (4.1 – 4.3), if these are still deemed necessary and relevant in light of the separation. Begin review of data elements table Begin discussion on Appendix C – Data Processing Requirements Deliberate on Preamble Deliberate on Section 1 (Principles for Processing) Deliberate on Section 2 (Lawfulness of Processing) Deliberate on Sections 3 – 3.1.6 (Specific Controller Processing requirements) Deliberate on 3.2 – 3.7 (Specific Controller Processing requirements) Deliberate on Sections 3.8 – 3.11 (Specific Controller Processing requirements) Discuss next steps for dealing with input on Appendix C Confirm action items and questions for ICANN Org, if any Wrap and confirm next meeting to be scheduled for Tuesday, 4 September at 13.00 UTC.

2 1

ALAC Early Input
by Alan Greenberg Aug. 29, 2018

Aug. 29, 2018

The ALAC wishes to support SAC 101 as submitted by the SSAC and as noted on https://community.icann.org/display/EOTSFGRD/Request+for+Early+Input+-+1+Au…. Alan

1 0

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

Aug. 29, 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/VRhpBQ Kind Regards, Andrea Glandon

1 0

Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 30 August 2018 at 13:00 UTC
by Andrea Glandon Aug. 28, 2018

Aug. 28, 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/VRhpBQ Kind Regards, Andrea Glandon

1 0

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

Aug. 28, 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, 28 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/UxhpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-28aug18… AC Recording: https://participate.icann.org/p4u1ncx0k5b/<https://participate.icann.org/p4u1ncx0k5b/?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

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

Aug. 28, 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, 30 August, 13:00 UTC. Best regards, Caitlin, Berry, and Marika =============== EPDP Team Meeting #8 Tuesday, August 28, 2018 Notes and Action Items High-level Notes/Actions: * Leadership will look into options for training on GDPR Training and report back to the EPDP Team. * EPDP Team encouraged to provide input on proposed approach in relation to triage report as outlined . * EPDP Team encouraged to review Issue Categorization and proposed Project plan. * The Leadership / Support team will revise the framework for considering data processing to: * accommodate additional forms of LEA-type requests for data, e.g., public authorities * clarify the role of ICANN in the eco-system * clearly differentiate between the purposes of collecting data vs disclosing data to third parties * differentiate (“un-conflate”?) the role of ICANN and contracted parties in the processing of data * clearly layout how disclosure of data to third parties is governed through GDPR compliance * Contracted parties are to examine the purposes enumerated in the Temporary Specification (§§ 4.4.1, 4.4.3-4.4.7; 4.11-4.12) and recommend changes * All are asked to consider the broad wording in section 4.4.8 of the Temporary Specification and recommend detailed purposes so that data sets can be deduced from those purposes Questions for ICANN Org from the EPDP Team: None All Action items: Action item #1: EPDP Team to share recommendations for whom or which organization should be considered to provide GDPR training to the EPDP Team. Action item #2: EPDP Team to provide input on path forward for triage report on the mailing list. Action item #3: EPDP Team to review Issue Categorization and proposed Project Plan and provide feedback. Action item #4: Staff to review whether any other policies would need to be called out under Registrar-Registry-ICANN Contract Purposes, in addition to dispute resolution services. 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/2IpHBQ. 1. Roll Call & SOI Updates (2 min) * 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 (3 min) * Please take note of today's agenda - pretty full, but main objective is to start deliberations on 4.4 * Request for GDPR training from RySG - support expressed from many. Leadership team will work on options to provide a training that would be provided in addition to the regular Tuesday / Thursday meeting. Action item #1: EPDP Team to share recommendations for whom or which organization should be considered to provide GDPR training to the EPDP Team. 3. Reconcile input received on Triage Report, if needed, and confirm report for submission to the GNSO Council (5-10 min) * Comments submitted by BC, IPC, RySG, RrSG and Milton (see https://community.icann.org/x/jxBpBQ) * Comments focused on: * Reinforcement that comments made and recorded in this report are not binding, limiting or prejudicial on any party * Some important points were missed and should have been included * Correction of legal or other terminology * Form of the issue * Question * Some say “A” and others say “not A” * Some advocacy * Policy vs specification * Options going forward: one more draft accepting substantive points from above, or, submit color-coded matrix (and comments) only, use comment summaries to guide substantive discussion. * Consensus policy can include specification so not necessarily correct that GNSO Policy Recommendations cannot affect specifiations. But what is the difference between a policy and a specification? From a contracted party perspective, both are enforceable by Compliance. * Data elements redaction - should positions on current redaction be recorded in the triage report? Maybe better positioned for the substantive discussion that follows? * Important to get triage report done so EPDP Team can move on to substance. Action item #2: EPDP Team to provide input on path forward for triage report on the mailing list. 4. Review of project plan (10 min) (see also section category allocation attached) * See issue categorization table shared prior to the meeting - divided into four sections 1) Sections affected by EDPB, 2) Sections where the Team indicated that amendment is desirable (2a - sections where change is required to bring the section to compliance with GDPR, 2b) sections requiring less attention as issues are not expected to impact compliance with GDPR, 3) Sections related to existing policies / procedures, 4) background, rationale, justification / admin. * This categorization has inspired the proposed project plan for how issues are expected to be considered throughout the remaining meetings. * See project plan. * Will it be possible to keep this level of abstraction as there is interconnectivity between topics - for example what is the data collected for, for what legal basis and agree on certain data subjects being required for certain purposes and take those through the whole lifecycle of the data. * Update should be made to reflect that 4.4. is purposes for collection, not access. Need to focus on how purposes are related to collection, storage and disclosure as they relate to ICANN's mission. Action item #3: EPDP Team to review Issue Categorization and proposed Project Plan and provide feedback. 5. Touch base on comments received on & review status of: (10-20 min) A. Appendix D – Uniform Rapid Suspension (see discussion summary index (DSI) at https://community.icann.org/x/ExxpBQ) B. Appendix E – Uniform Domain Name Resolution Dispute Policy (see DSI at https://community.icann.org/x/ExxpBQ) C. Appendix G: Supplemental Procedures to the Transfer Policy (see DSI at https://community.icann.org/x/ExxpBQ) * No comments / input received to date * Leadership team to consider how to encourage input on how these appendixes may need to be updated, if needed 6. Commence deliberations for section 4.4 – Lawfulness and Purpose of Processing gTLD Registration Data (see DSI at https://community.icann.org/x/ExxpBQ) (50 min) * See slides distributed and discussed during the meeting (https://community.icann.org/download/attachments/90773587/EPDP%20Team%20Mee…) * Take particular note of the EDPB advice: There are processing activities determined by ICANN, for which ICANN, the registrars and registries, require their own legal basis and then there are processing activities determined by third parties, which require their own legal basis and purpose. ICANN should take care not to conflate its own purposes with the interests of third parties. Data legitimately collected by ICANN, registrars and registries would not categorically exclude the subsequent disclosure of personal data to third parties for their own (legitimate) interests and purposes. Personal data disclosure can be made for the purposes of the legitimate interests third parties, provided that those interests are not overridden by the interests or fundamental rights and freedoms of the data subject, i.e., disclosure is proportionate and limited to that which is necessary and the other requirements of the GDPR are met. * See slide 19 - purposes limited to the data necessary to provide services bargained for and required by contract, uses necessary to provide services bargained for and required by policy or contract. However there may be other legitimate purposes for which this data may be accessed for example by LEA or for consumer protection, investigation of cybercrime, DNS abuse, intellectual property protection, contract compliance. * Should be clear that ICANN does not determine the data to be collected alone, especially if Ry and Rr are considered joint controllers. * Overarching concern of the GAC is that there is only reference to the LEA and not references other public authorities and their obligation to carry out their tasks. Also need to clarify whether this also includes cross-jurisdictional requests, but with necessary safeguards on how these are to be handled. * Is this meant to be inclusive or are some purposes missing from slide 19? Performance of contract, consent do not seem to be covered, for example. UDRP is an example of a dispute resolution mechanism that is required by contract and as such, does it need to be subject to the balancing act? * Registars also collect information for its own purposes, on behalf of the account holder, such as invoicing information. Does this need to be controlled by ICANN? ICANN's role should focus on domain name registrations and the agreements it has with contracted parties. Need to be clear and look at the contractual relationships, these can also govern third party interests. Need to look at what data needs to be collected to fulfil contractual obligations and then review how this data can also be accessed for legitimate third party interests. * Need to bring in ICANN's purposes - why does ICANN require collection of data of CPs? Is done through the contract making contracted parties joint controllers. Third party legitimate interests are different from this - it is asking this data from Rr, not a legitimate purpose of Rr. * By whom are purposes pursued - see slide 20. * Slide 21 - proposed categorization of purposes (Registrar-Registry-ICANN Contract Purposes / Third-Party Purposes). Consider whether the breakdown should follow the GDPR (6.1(b), 6.1.(f), 6.1.(a)). * Possible path forward for Registrar-Registry-ICANN Contract Purposes - see slide 22. CP input needed - are there additional legitimate reasons why contracted parties collect data from registrants? Should these purposes be re-grouped to better capture their relevance, list and consolidate data necessary to support all purposes? * Possible path forward for third party purposes - see slide 23. Are the purposes enumerated here valid and legitimate? Do those purposes have a corresponding legal basis? If there are instances where personal data can be made available to third parties under these conditions, then we can retain the purpose in the Specification; Describe the data elements required. * Should ICANN Contractual Compliance move to Registar-Registry-ICANN Contract Purposes. * Registrars collect data for their business purposes that are well out of the ambit of ICANN's control, including the MS process. Need to keep in mind that distinction. Should make a clear demarcation of what data is collected and for what purposes it is collected as registration data in the gTLD world and what data the registrars process for their own purposes. Only the former shall be governed and enforced by ICANN. * What is the purpose of a domain name registration? Start at the basics. This maybe too complex to meet the deadlines that are in place? Most of the purposes outlined on slide 22, apart from 4.4.12 seem to be directly related to domain name registration. * Need to also consider whether there are other means to fulfil the needs identified. For example, for payment and invoicing there may be other ways in which contractual obligations are fulfilled. May be taking on too much. Should focus on essential elements of the temporary specification. * Isn’t that circular: “it’s in our contract, therefore it must be legal because the law allows for service of a contract" * Consider list of purposes and data elements, outlining processing steps. For example, excel sheet with all the data elements collected by the registrar, look at travel from that data from registrar to registry for performance to the contract, what on the basis of a legitimate interest, what on the basis of consent? That may focus on a sub-set of data elements that is collected by registrars. Then follow that for EBERO, escrow, ICANN, etc. See also https://www.icann.org/resources/pages/gtld-registration-dataflow-matrix-201… which could serve as a potential basis. * Consider adding ‘for the compliance with ICANN policies’ to slide 22. Some may not expressly listed here, so consider making it a stand-alone item. Note that any policies would need to be compliant with GDPR and a separate data protection impact assessment may be needed. * Concern about including purposes that go beyond ICANN’s mission, for example 4.4.8 and 4.4.9. Some noted that it is ICANN’s responsibility to make sure the DNS works and can be trusted. Should this be a rationale that is included as it is the basis for third party access? * If data is collected for the sole purpose of maintaining the registration and compliance with ICANN policies, isn’t third party access for a legitimate purpose not overcome by the rights of the individual, acceptable and consistent with ICANN’s mission? That is not disputed, but making third party purposes part of ICANN’s purposes is the concern as that could broaden what is collected. But focus is on purposes for collection that would focus on ICANN’s purposes so there would not be a risk that data collected is expanded as that cannot be done on the basis of a third party legitimate purpose. Third party purposes do not include collection. * Issue is with the reference to ‘framework’ without it being defined anywhere (in 4.4.8 and 4.4.9). Framework may be further addressed in the access discussion? Could be read as ready and available to support decisions that are made in the EPDP team? * Can an agreement be written up that data collected for domain name registration purposes can then be made available to third parties under certain conditions? Could ask third parties to flesh out which data elements would be needed for those third party access? * Should consider how 4.2 and 4.3 fit with this? Action item #4: Staff to review whether any other policies would need to be called out under Registrar-Registry-ICANN Contract Purposes, in addition to dispute resolution services. 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

Request for GDPR Training
by Rosette, Kristina Aug. 28, 2018

Aug. 28, 2018

All, I submit this request on behalf of the RySG and RrSG: The RySG and RrSG request that all EPDP WG Members and Alternates receive as soon as practicable the training about the GDPR referenced in the GNSO Council's 12 July Call for Volunteers. It is clear from the EPDP WG meetings to date that knowledge and understanding of the GDPR is uneven among the EPDP Members and Alternates. This uneven knowledge and understanding hinders participation and impedes the rapid progress of the WG that the Charter requires. The training should be in addition to (and not part of) the WG's Tuesday and Thursday meetings. Thank you. Kristina Rosette Senior Corporate Counsel, IP - Domains rosettek(a)amazon.com<mailto:rosettek@amazon.com> | 703.407.1354

4 3

Re: [Gnso-epdp-team] Ahead of tomorrow's call
by Marika Konings Aug. 28, 2018

Aug. 28, 2018

Matt, all, The input received to date on the triage report can be found here: https://community.icann.org/x/jxBpBQ. Best regards, Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Matt Serlin <matt(a)brandsight.com> Date: Monday, August 27, 2018 at 10:13 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org>, "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: [Gnso-epdp-team] Ahead of tomorrow's call Hi All, In looking at the agenda for the call tomorrow, I see we have 5-10 minutes to reconcile input received from each group on the Triage Report. Personally, I think it would help if we could get that input ASAP, so we have an opportunity to review it ahead of the call tomorrow. To that end, I’m attaching the RrSG feedback which was submitted Friday. I know we have an already packed agenda, but I’m concerned that 5-10 minutes on this topic on the call tomorrow will not be sufficient if the input received varied significantly. Look forward to speaking to everyone tomorrow. Regards, Matt

3 2

Responses to early input request
by Marika Konings Aug. 28, 2018

Aug. 28, 2018

For your information, in response to the request for early input, a response was received from the SSAC. Their response, and any further input that may be received has been posted here: https://community.icann.org/x/Ag9pBQ. Staff will make sure to update the background documents section on the wiki with the documents referenced in the SSAC response. Best regards, 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-…>.

2 1

REMINDER: Travel Planning to Los Angeles/ alternates needed by Tuesday, 28 August 2018
by Terri Agnew Aug. 27, 2018

Aug. 27, 2018

Hello all, As a reminder, please confirm by Tuesday, 28 August at the latest whether any alternates are replacing any members for the whole duration of the F2F meeting or a significant period of the F2F meeting (as outlined below) as staff needs a confirmation of number of attendees ASAP. To confirm an alternate replacement for a significant period of the F2F meeting, or the whole duration of the F2F meeting, please complete the following form: https://docs.google.com/forms/d/e/1FAIpQLScuCvS7vKS4MuaXwJmDcUHtOTskg6t5qrS… To date, two confirmations have been received (Lindsay Hamilton-Reid (RrSG) will be replacing Emily Taylor (RrSG) and Fiona Asonga (ISPCP) will be replacing Esteban Lescano (ISPCP) for the whole duration of the F2F meeting) Thank you. Kind regards, Terri -----Original Message----- From: Gnso-secs <gnso-secs-bounces(a)icann.org> On Behalf Of Terri Agnew Sent: Thursday, August 23, 2018 11:56 AM To: GNSO EPDP <gnso-epdp-team(a)icann.org> Cc: gnso-secs(a)icann.org Subject: Re: [gnso-secs] [Gnso-epdp-team] Travel Planning to Los Angeles Hello all, To get travel ready, those members who cannot attend in person and will assign an alternate for travel or a portion of the meeting, please complete the Alternate Assignment form (see below - point 2) by Tuesday, 28 August 2018. Members and Liaisons; ICANN Constituency Travel has sent out emails with your travel information. Please submit air or travel by Friday, 24 August 2018. If you have not received this email, let us know right away at gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Thank you. Kind regards, Terri -----Original Message----- From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Kurt Pritz Sent: Thursday, August 23, 2018 11:36 AM To: GNSO EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: [Gnso-epdp-team] Travel Planning to Los Angeles Hello Everyone: After reviewing the chat and content of our call Tuesday, 21 August, it has been decided to proceed with the meeting in Los Angeles as proposed. (See bullet three, below.) 1. Members who are attending in person already should have travel arrangements in process. 2. Members unable to attend should have designated their alternates for attendance, who should be in contact with ICANN regarding travel arrangements. (See Alternate Assignment form, https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_…) Remote participation is available for members that prefer to participate remotely instead of designating an alternate. 3. Members who are attending but will miss a portion of the meeting should designate an alternate who will replace that member when they are gone from the meeting for a significant period. That alternate will be permitted to sit in on the entire three-day meeting but participate only when the member is absent from the meeting. In these cases, alternates will not be provided travel funding. Travel funding is allocated based on the number of members in each group. Remote participation will also be available for those members that prefer to participate remotely instead of designating an alternate. If any of the above is not clear or if you have questions, you can contact me, Rafik or the ICANN Support Team. Through this email, I am asking Terri Agnew to follow up with you to ensure all necessary travel is planned and funded. I am looking forward to the meeting and commit to work with the support staff to make the effort on your part worth your while. Best regards, Kurt _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-secs mailing list Gnso-secs(a)icann.org<mailto:Gnso-secs@icann.org> https://mm.icann.org/mailman/listinfo/gnso-secs

1 0

Re: [Gnso-epdp-team] Correction!!
by Mueller, Milton L Aug. 27, 2018

Aug. 27, 2018

> -----Original Message----- > My understanding is EPDP was tasked to find a way > to gain access to WHOIS data without running foul of GDPR and nothing > else..compliance with other laws was not part of the EPDP mandate. > Aslam That is a pretty fundamental misunderstanding of the ePDP's charter. The basic task of ePDP is to ratify or modify the temp spec. Here is the relevant statement from the charter. " This EPDP Team is being chartered to determine if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy, as is or with modifications, while complying with the GDPR and other relevant privacy and data protection law." Regarding access, the charter says, "Work on this topic shall begin once the gating questions above have been answered and finalized in preparation for the Temporary Specification initial report" So: 1) temp spec first; 2) "other relevant privacy and data protection law" is applicable, not just GDPR; 3) we deal with access to redacted Whois data after we have resolved the status of the temp spec. Here's a link to the charter: https://gnso.icann.org/sites/default/files/file/field-file-attach/temp-spec…

1 0

Ahead of tomorrow's call
by Matt Serlin Aug. 27, 2018

Aug. 27, 2018

Hi All, In looking at the agenda for the call tomorrow, I see we have 5-10 minutes to reconcile input received from each group on the Triage Report. Personally, I think it would help if we could get that input ASAP, so we have an opportunity to review it ahead of the call tomorrow. To that end, I’m attaching the RrSG feedback which was submitted Friday. I know we have an already packed agenda, but I’m concerned that 5-10 minutes on this topic on the call tomorrow will not be sufficient if the input received varied significantly. Look forward to speaking to everyone tomorrow. Regards, Matt

1 0