August 2018 - Gnso-epdp-team

Preparation for next meeting
by Kurt Pritz 24 Aug '18

24 Aug '18

Dear All: As mentioned, there is a homework assignment for our next meeting. I apologize for this coming out so late but I hope you recorded some of these from the meeting discussion on homework and have been thinking about them. 1. Temporary Specification sections 4.4.1-4.4.13: Please review the attached discussion summary index (DSI) for section 4.4.1-13, as well as your own notes and the record of the triage discussion. Our discussion’s objective is to redline this section so that it complies with GDPR taking into account: · advice provided by the EDPB, · input that has been provided by other members of the EPDP Team, (All the information cited above is included in the DSI.) It will be very helpful if you share proposals regarding each of the with the mailing list as soon as possible, and particularly by Monday 18.00 UTC. The purpose in gathering written comment is so that commonalities can be identified in your proposals in order to better focus the discussion. 2. Appendix D, E and G: Provide proposed edits (using the DSIs if possible) for Appendix D, E and G, having to do with URS, UDRP and Transfers, respectively. Please share your proposed edits to these sections on the mailing list that would address the comments / issues that have been identified. Understanding that these sections have already been put into operation, please flag specific changes that are required to be addressed in the initial report, i.e., are of an urgent nature, needing to be addressed as a matter of priority. In some cases we might decide that certain sections do not affect Temporary Specification compliance with GDPR and can be placed for later discussion. I am working on a discussion flow for our next meeting to make efficient and meaningful use of your time. If you have thoughts on this please let me know. I will follow up on this with my thoughts in a subsequent email. Thanks in advance for providing your thoughts on these issues. Best regards, Kurt

1 0

Travel Planning to Los Angeles
by Kurt Pritz 24 Aug '18

24 Aug '18

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://docs.google.com/forms/d/e/1FAIpQLScuCvS7vKS4MuaXwJmDcUHtOTskg6t5qrS…) 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

7 6

Notes and action items from today's EPDP Team Meeting - 23 August 2018
by Caitlin Tubergen 23 Aug '18

23 Aug '18

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Tuesday, 28 August, 13:00 UTC. Best regards, Marika, Berry, and Caitlin EPDP Team Meeting - 23 August 2018 High-level Notes/Actions: Please provide additional input (if any) on the Triage Report by Friday, 24 August at 19.00 UTC. The Triage Report, scheduled for release early next week, will include the following appendices or companion documents: all the survey responses sorted by group and sorted by Temporary Specification section; a print version of the opening statements made by each group; Early Inputs submitted by each group. The Team has now begun substantive discussion of the Temporary Specification. As a tool to aid in these discussions, the support team will distribute discussion summary indexes for each survey section, which provides the relevant Temporary Specification text, related charter question(s), EPDP Team Members’ feedback provided to date (via the triage surveys), related EDPB advice (if any). The discussion summary index also provides a field in which EPDP Team Members may propose modified text. Members of the group raised the utility of performing a privacy impact assessment. Three takeaways were for members to understand the benefits of such an assessment in the work, suggest which elements could be helpful to undertake (given the timeline), and also to ask ICANN if it was planned that an impact assessment will be undertaken. See, https://bit.ly/2OVgeYY. In discussing whether and how other privacy regimes impact our work, the support team pointed out that other privacy regulations can be found at https://bit.ly/2PxFt4I. It was also indicated by Thomas and Alan that, as a generalization, GDPR provides a “high-water mark. I.e., if our work is GDPR compliant, it should be universally compliant. It was suggested that ICANN be asked to perform an assessment to determine if other privacy regimes should be analyzed for possible inclusion into this work. Per the proposed strategy discussed today, the Leadership Team is working together to propose a detailed project plan, which outlines the order in which the EPDP Team will deliberate on the sections of the Temporary Specification. For more detail on the strategy, please refer to the detailed notes. With regard to next steps, there were several recommendations that we examine the purposes of collecting and purposes of accessing data. That input matches with the existing plan to undertake a look at sections 4.4.1-4.4.13 next, which describe the uses of data. The corresponding discussion summary index that will be distributed for this discussion will include the charter questions that might be answered in parallel with this inquiry. As a prerequisite to that discussion, we will discuss the purposes of collecting data. This was discussed in depth in the RDS working group and the support team will document the findings by that working group. All Action Items: Preliminary input on the triage report is due Friday, 24 August. Goal is to submit the triage report early next week. For any groups who plan to respond to the requests to provide early input, please do so as soon as possible. Support Team to provide EPDP Team with output of RDS PDP WG’s work on which data elements are required to register a domain name and maintain that registration. EPDP Team members to look at the discussion summary indexes for Appendix D, E, F and provide recommend redlines (if any) to the email list. We will attempt to address these sections via email rather than take up meeting time with them. Support team to distribute discussion summary index for Section 4.4, as well as RDS findings with regards to the purposes of collecting registrant data. EPDP Team members to review discussion summary index for Section 4.4 in preparation to discuss at next EPDP Team meeting on Tuesday, 28 August at 13.00 UTC 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 via the Adobe Connect Room. SOIs must be kept up-to-date. All relevant documentation can be found on the EPDP wiki space. Please remember to state your name before speaking. 2. Welcome and Updates from EPDP Team Chair We will be moving from discussing every section of the Temporary Specification in the triage surveys and turning to a substantive review of specific sections. We will spend the first part of the meeting discussing the strategy for moving forward. 3. Preliminary input on Triage Report (deadline for input: Friday, 24 August at 19:00 UTC) Preliminary input on the triage report is due Friday, 24 August. Goal is to submit the triage report early next week. As a reminder, for any group who would like to respond to the early input requests, please do so as soon as possible. The triage report will be updated to include all submitted comments. 4. Proposed approach for moving forward, including review of proposed project plan A GDPR-compliant specification is required by 25 May, requiring a good portion of our work to be completed in October. GDPR-compliance requires, among other things, that the sections specifying processor requirements must have the consensus support of this team Some prioritization is required that takes into account: The time available Sections that require registrar / registry & other processor actions Issue complexity Which sections are already in operation and functioning Availability of EDPB and other guidance Further guidance is possible (dependent on timing) New questions for EDPB or DPAs Clarification requests of existing guidance But case law and standard practices will be lacking EPDP Team feedback: The goal is to comply with GDPR Any successor should take into account emerging privacy law in other jurisdictions. Aiming to tackle the topic of privacy in a more holistic way would be a more efficient use of our time. Examples could include privacy-by-design principles or a privacy impact assessment What is a privacy impact assessment? Generally, a privacy impact assessment would be a systematic process conducted by government agencies or businesses to reflect on privacy and see how various practices impact individuals Is some sort of survey needed of other privacy regimes? A privacy impact assessment has been around in several jurisdictions for years. The only problem in doing a privacy impact assessment is that it's only as good as the framework you apply, and since there are over 100 national laws around the world, you would have to select the leader or come up with a framework that allows you to select other laws. In the context of emerging legislative and regulatory initiatives that may impact on ICANN, please see https://www.icann.org/en/system/files/files/legislative-regulatory-fy18-23a…. This is something that is actively being tracked. It might not be necessary to select a particular regime for a privacy impact assessment. The GDPR is principle-based, and the principles can be applied broadly. The privacy impact assessment could be based on broad principles. What we are effectively doing in the EPDP is a privacy impact assessment of the temp spec ourselves -- for example, are the purposes connected to a solid legal basis? Doing a privacy impact assessment for ICANN would be a complicated and expensive exercise. Other companies may look at this type of work as a threat assessment -- what are we trying to protect? Who has access to it? Who is using it? Is there a specific question to ask ICANN - whether any of the other regimes create requirements above and beyond the GDPR? Proposed Criteria for Discussion Planning Priority must be assigned to those sections: affected by EDPB advice, i.e., where change is mandated by advice received after the specification was written where the Team has indicated the likelihood that change is required to bring the section into compliance with GDPR Requiring less attention are issues that are not expected to impact the Temporary Specification’s compliance with the GDPR, such as: operations changes to existing consensus policy such as UDRP or Transfers requirements issues that can be settled after the initial report is launched, e.g., SLAs to be negotiated between contracted parties and ICANN, Best practices and reporting requirements where it is thought the Temporary Specification is overly prescriptive Unless a pre-requisite to the issues above, those items that do not direct registry and registrar actions can be considered as time is available such as: background, rationale, justification, administrative sections. Sections affected by EPDB are Category 1. Sections where the Team Indicated Amendment to the Temp Spec is desirable are Category 2. Sections related to transfers, DRPs and require little or no change, are Category 3. Sections involving background, admin are Category 4. For sections where there is pertinent EDPB guidance or where the Team has indicated a likelihood that change is required: Allocate time to ensure a common understanding of: The Temporary Specification section Existing EDPB advice or other authority Previous discussion and the issues raised Deliberate what changes, if any, are required, to ensure that the advice has been addressed. As these are more complex issues the discussion might be plan to extend over (a part of) two or three sequential meetings. If it becomes clear that additional information, research or guidance is necessary, or that progress might be facilitated by offline discussion between two or more parties, then a small group might be assigned work, that will operate based on the task assigned: Populated by interested and necessary parties Working methods (e.g., email, conference) based on the task assigned With delivery set to support a delivery of the initial report This approach is meant to be flexible. For sections that are not expected to impact the Temporary Specification’s compliance with the GDPR, or those items that do not direct registry, registrar and other processor actions: Time will be allocated for a briefing on these items during meetings to review the previous discussion and issues raised. In many cases, attaining consensus might be attained in a brief period. Where addition refinement is necessary an expert group might be asked to provide additional information or recommend an amendment: Ex: where the Temporary Specification recommends content for Privacy Notices to be posted by registrars: a registrar and GDPR expert might be asked to create a better approach Wherever possible, this additional work would be considered and included in the initial report. If not and based on the subject matter, the Team will consider the timing of inserting the new draft into the successor specification for approval. Depending on the review and the approval cycle, inclusion into the successor specification might occur before or after the final report. (This is a ”parking lot” where issues will be recorded and resolved.) EPDP Team Feedback: While not against this approach, using an example - for discussing transfers, you first need to discuss what data goes to a registry. Depending on that outcome, you can then discuss transfers. It's important to have the questions in the correct sequence so that problems don't occur and/or already-proposed changes need to be corrected later in the process. A point of contention between people in the group is whether ICANN has made the legal argument over where information can be collected and later distributed. Who is responsible for building the legal argument? Is it the EPDP team's job or is that ICANN org's job? ICANN may believe it has built the legal argument in the Temp Spec, but there is a question whether that has been satisfied in this group. Perhaps the team can tailor the discussion around the processing of data under GDPR - after doing that, the team can go back and look at ICANN's powers. The EPDP Team needs to deal with the fundamental issues regarding what data needs to be collected and redacted. ICANN org thinks it has already done this, but the team should come to an agreement on the redacted data elements. Purpose and collection is equally fundamental, but it's unlikely the team will come to agreement on that. Agreeing on redacted data elements appears to be a concrete and specific task. Our charter lays out the questions (and the sequence to be used to answer them) quite nicely. Our charter already laid out the sequence, so the team should follow the charter and use that order of how to approach the work. The Team can decide how to tackle the work, but the charter provides a good order to begin with. For example, tackling purposes is critical. If we do not come up with an agreed upon set of purposes for our deliberations, we will never agree on other points. Agree that we need to debate the purposes. The GAC's next meeting is to discuss what data will be provided, and how will the data be transferred. The purpose issue is primary; however, having debated purposes since 2005, there is concern we will never move past that. Some may approach this as what data they would like access to and work backwards to try to get data. What is the plan when we discover we cannot agree on purposes? This EPDP was formed to break this deadlock, and as a group, we have to find a way to move forward. It will be impossible to debate other sections without first agreeing on purposes. People tend to justify data they need and define purposes based on that; however, one thing that we could catch in a privacy impact assessment is what problem are we trying to solve? You may or may not have to collect information to solve a problem. As we discuss purposes, we should come back to the problems we need to solve, like hijacked domain names. The problems may also be a source of contention, but the group may agree on these problems. What the group should aim for is to make sure that the purposes listed do comply with the privacy laws. In terms of going about the work the team needs to do, debates around purpose would happen in category 2, but perhaps the group needs to see the full schedule. Maybe if the group maps the schedule based on the flowchart in the slides, and include the charter questions for each piece of work, the team could see the roadmap and have a better idea of the work going forward. Some members believe the discussion of purpose may be theoretical and abstract, but this is problematic. If purposes of the data to be collected is abstract in theory, the whole Temp Spec is abstract in theory. We are operating in a multi-stakeholder environment – we are trying to retrofit a set of policies and contracts so that it does not violate data protection law and the GDPR. Naturally, we have a hard time determining purpose because many of the stakeholders consider their purpose the same as the registrar’s purpose. The actual purpose for collecting registration data is a very narrow one – it is for the domain name to function. Publishing this data is not a legitimate purpose. The RDS Team raised most of these arguments, and if we have to rehash these arguments, this team will fail. What problem are we trying to solve, and what data do we need? This question is inherently problematic – rather than collecting use cases, we should ask what is ICANN’s purpose. If we continue to focus on what data we need, we lose sight of the problem. If I had a guarantee that if I go to a Ry/Rr and get information in a predictable timeframe, I may never have to see the data (probably unlikely), but this is a possibility. There is a trap for an attractive piece of data and why it should be published, and we should avoid this. Let’s look to the technical people to solve the problems of bulk access. Focusing on the data itself is a bit of a trap. Focusing instead on purposes is very important. ICANN needs to collect data to fulfill its purposes – its purposes are not IP or law enforcement; however, the data is collects may be useful to entities with legitimate purposes. If we recognize the difference between ICANN’s purpose and third-party purposes, the group can make progress. When we confuse third party purpose with the purpose of WHOIS is where we run into trouble. We should first look at what data needs to be collected for domain name registration. Then we can look at what additional data might be required – that could include additional data under consent. Then, you can look at transfer of data to other parties. If we go through that thought process, we can look at what data can be collected in domain name registration. As well as looking at what is necessary for registration contracts, we need to look at ICANN’s mission/coordination role. GDPR recognizes there are legitimate purposes and exemptions – what is missing from our conversation is an assessment of necessity and proportionality. One problem is that we have different opinions on what ICANN’s mission is – one part of ICANN’s mission is to secure a trusted DNS. What does ICANN need to do to achieve that part of our mission – that is where the tie-in to law enforcement and third-party interests lie. The team seems to be confusing several issues – one thing we need to talk about is enforcement of contracts. There is an agreement in the registration agreement that the registrant submits to UDRP disputes. This is squarely within the mission of ICANN and providing a framework for having a trusted DNS. The mission is not that narrow. What the team should do is try to peel the onion. Start by looking at data collected for the registrant – look at what is required to register a domain name and maintain that registration. We are conflating what is required to perform a contract with the overarching goals ICANN has in its mission. The RDS WG already did some of this work. One of the homework assignments is to go back to the RDS WG’s work to look at which data elements are required to register a domain name and maintain that registration. Our future conversations will be guided by discussion summary indexes. For each section (and relevant sub-sections) a scorecard will be prepared to facilitate the deliberations which will include: Current text Identification of category Related charter question(s) Support indicated as result of triage effort DPA/EDPB Advice (if any) Proposed changes / rationale for change (as provided by EPDP Team in response to triage surveys) Information to be completed: Proposed response to charter question(s) High level summary of the deliberations and/or recommendation(s) Proposed modification of text (if appropriate) Level of consensus Data Summary Index to facilitate development of Initial Report The number of meetings we have to get the work done is limited, as displayed on the screen. The leadership team is embarking on how to divide the work in the meetings. 5. Commence deliberations and review of Appendix D – Uniform Rapid Suspension (see discussion summary index) 6. Commence deliberations and review of Appendix E – Uniform Domain Name Resolution Dispute Policy (see discussion summary index) 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. Action Items: Preliminary input on the triage report is due Friday, 24 August. Goal is to submit the triage report early next week. For any groups who plan to respond to the requests to provide early input, please do so as soon as possible. Support Team to provide EPDP Team with output of RDS PDP WG’s work on which data elements are required to register a domain name and maintain that registration. EPDP Team members to looks at the discussion summary indexes for Appendix D, E, F and provided suggested mark-ups (if any) to the email list Support team to distribute discussion summary index for Section 4.4 EPDP Team members to review discussion summary index for Section 4.4 in preparation to discuss at next EPDP Team meeting on Tuesday, 28 August at 13.00 UTC

1 0

Re: [Gnso-epdp-team] Coordination between ICANN org and EPDP
by Kurt Pritz 23 Aug '18

23 Aug '18

Hello Göran: Thanks very much for contacting me and your note I have repeated some your email below so that there is a clear connection between your questions and my responses. Today, ICANN org held a call to provide community leaders with updates regarding various GDPR activities. The slides and recording of the call are available at https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en <https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en>. On the call, a few community leaders reinforced the value of coordination between ICANN org and the EPDP Working Group, particularly around access model. To this end, please share with us any thoughts you might have regarding a process by which: 1) ICANN org can share guidance we receive from the DPAs and European Data Protection Board with the EPDP Working Group. Generally, our Team discussions are appropriately aimed at refining / altering ICANN processes so they are GDPR compliant. So guidance, case law or authoritative opinions received that provides compliance requirements will be extremely helpful. a. Through its many recent actions: engaging with the ICANN community, governments, the EDPB, and others, it is apparent that ICANN is the midst of executing a plan to obtain certainty around the various GDPR provisions. It would be instructive for the EPDP Team if ICANN were to share its plan (or elements of it) so that the team can anticipate the receipt (and timing) of new information. It would also indicate where there is likely no additional information, i.e., where the team would be left to draw conclusions based on the information that is already available. This information would likely cut down on the number of questions the ICANN Org receives from the team. We understand that the plan must have a degree of informality and be flexible, with each step based upon the information received in the step before it. However, where available, it would be instructive to know the planned-for objectives, expected learnings, a set of ultimate questions to be answered, planned inquiries, targets and so on. b. While ICANN has published each communication, the findings or results of those communications have not been organized in anyway of which we know. For example, observers of the back-and-forth between the ICANN Org and the EDPB have offered conclusions that can be drawn from these documents. However, no one has organized those conclusions in a way that might become a rule set or set of guidelines for those reviewing the Temporary Specification or creating an access model. Coincidentally, in today’s EPDP meeting such a request was made: for disclosure of all the communications with the EDPB and DPAs, the staff commentary to those communications, and some organization of same. c. We also wish to hear of developments related to GDPR in other industries, if available, such as: what data processing protocols have been adopted what data processing protocols have been tested in courts what other privacy regimes are in works in other jurisdictions what data is available regarding: the effects of GDPR on malfeasance detection, avoidance other positive or negative effects of GDPR d. Finally, it’d be helpful to be made aware of the details of ICANN’s GDPR implementation plan as ICANN org had to take on the advice of DPAs and the EDPB in fashioning that. (This is a request made from the EPDP team in yesterday’s meeting and so this request has been repeated to the ICANN liaisons working with the EPDP.) 2) How the EPDP Working Group will provide input regarding access to ICANN org to use in our interactions with DPAs and European Data Protection Board to obtain legal guidance that will help guide the Working Group in its work. As you know, we post all information we receive through our blogs and engage with stakeholders, also through communications we post whether through correspondence or comments via gdpr(a)icann.org <mailto:gdpr@icann.org>. a. A point of information: The EPDP team’s third set of deliverables is to provide an, “Initial Report and a Final Report regarding the EPDP Team’s recommendations … for a System for Accredited Access to Non-Public Registration Data.” Work on this could begin as early as the completion and publication of the Initial Report on the Temporary Specification. (The Team stays in close contact with the GNSO Council leadership in pursuit of the deliverables to ensure the spirit and letter of the EPDP Charter is followed.) b. While our current answer to this question is not yet finely honed, it is likely that, from time to time, the EPDP Team will have question regarding the constraints / opportunities imposed by the GDPR. These questions might take the form of a proposed access model (or elements of an access model). The EPDP Team will forward those to ICANN, which, in turn, can test them against its own knowledge base, with DPAs, with the EDPB, or elsewhere. c. As ICANN is a data controller involved in the collection, use and disclosure of the same data that is the subject matter of this Team’s work, it is expected that ICANN will work with the team on the successor to the Temporary Specification and an access model. I hope you find this response helpful. The team is keen to continue an active correspondence with ICANN in order to flesh out the framework provided by GDPR with detailed clarifications, implementation guidance and cases from other, similarly situated industries that have faced many of these same issues. We also plan to remain in close communication with ICANN leaders on this topic, through the ICANN-provided liaisons to the EPDP Team. Sincerely, Kurt > On Aug 14, 2018, at 8:17 AM, Goran Marby <goran.marby(a)icann.org> wrote: > > Kurt, > > Today, ICANN org held a call to provide community leaders with updates regarding various GDPR activities. The slides and recording of the call are available at https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en <https://www.icann.org/resources/pages/data-protection-meetings-2017-12-08-en>. > > On the call, a few community leaders reinforced the value of coordination between ICANN org and the EPDP Working Group, particularly around access model. To this end, please share with us any thoughts you might have regarding a process by which (1) ICANN org can share guidance we receive from the DPAs and European Data Protection Board with the EPDP Working Group; and (2) How the EPDP Working Group will provide input regarding access to ICANN org to use in our interactions with DPAs and European Data Protection Board to obtain legal guidance that will help guide the Working Group in its work. As you know, we post all information we receive through our blogs and engage with stakeholders, also through communications we post whether through correspondence or comments via gdpr(a)icann.org <mailto:gdpr@icann.org>. I look forward to hearing your thoughts on how we can continue to strengthen our work together toward the common goal of having an access model that is guided by the law and supported by the community. > > Best regards, > > Göran Marby > President & CEO ICANN > +1(310) 578 8690 > > > Cássia Oliveira > Sr. Manager, Office of the President & CEO > cassia.oliveira(a)icann.org <mailto:cassia.oliveira@icann.org> > +1(310) 578 8656

2 1

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

23 Aug '18

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

Meeting Invitation / Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 28 August 2018 at 13:00 UTC
by Andrea Glandon 23 Aug '18

23 Aug '18

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/UxhpBQ Kind Regards, Andrea Glandon

1 0

redacted data
by Mueller, Milton L 23 Aug '18

23 Aug '18

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 23 Aug '18

23 Aug '18

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 23 Aug '18

23 Aug '18

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 23 Aug '18

23 Aug '18

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