August 2018 - Gnso-epdp-team

Proposed Agenda for EPDP Tam Meeting #4 (Tuesday 14 August at 13.00 UTC)
by mail＠berrycobb.com Aug. 12, 2018

Aug. 12, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 14 August at 13.00 UTC. Best regards, Caitlin, Berry and Marika ==================== EPDP Meeting #4 Agenda Thursday, 14 August 2018 1. Roll Call & SOI Updates 2. Welcome and Updates from EPDP Team Chair 3. Summary of responses to EPDP Input Survey Part 2 a. Results for Sections 5-7 (Requirements Applicable to Registry Operators and Registrars) b. Appendices B (Supplemental Data Escrow Requirements) & F (Bulk Registration Data Access to ICANN) 4. Substantive Discussion of Temporary Specification (Sections 5-7 + Appendices B & F) a. Part 2 of the Survey can be found at https://www.surveymonkey.com/r/7BMRCNS b. Responses and issue summaries are in the Spreadsheet accompanying this agenda 5. Wrap and confirm next meeting to be scheduled for Thursday 16 August at 13.00 UTC. (Part 3 Survey results due Wednesday, 15 August by close of business.) Thank you. B Berry Cobb GNSO Policy Consultant

1 0

ICANN Org questions from 7 August EPDP meeting
by Caitlin Tubergen Aug. 10, 2018

Aug. 10, 2018

Dear All, Below, please find answers to the questions posed to ICANN Org from the Tuesday, 7 August EPDP Team meeting. Question: The Team seeks clarification on the exact expiry date of the Temporary Specification. In Section 3, the effective date of the Temporary Specification is 25 May 2018, but was adopted on 17 May 2018. Response: Per Section 3 of the Temporary Specification, the effective date of the Temporary Specification is 25 May 2018. Additionally, the ICANN Board resolution adopting the Temporary Specification states: “The Temporary Specification will be effective for a 90-day period beginning 25 May 2018. The Board will reaffirm its temporary adoption every 90 calendar days for a total period not to exceed one year.” Question: If the Board is considering any amendments to the Temporary Specification, it would be helpful if the EPDP Team can be made aware of any proposed changes in advance. Is the Board currently considering any amendments to the Temporary Specification? To address what requirement? Response: ICANN Org is not aware that any amendments are currently being considered. The Board is scheduled to meet in August to consider reaffirming the Temporary Specification according to the process in ICANN’s agreements for adopting temporary policies and specifications. Question: When ICANN refers to “security” as part of its mission - can ICANN describe what types of security are included?? Response: The word “security” appears 36 times in the ICANN Bylaws in relation to topics such as: the DNS, the Internet, the Internet’s system of unique identifiers, the Internet’s root server systems, the registry database, and Top Level Domains. Question: With regard to the term “content,” in Section 4.4.5 - can ICANN provide context for use of the term? Response: It is generally believed that ICANN does not see itself in the role of a content regulator but there are scenarios where use of the term “content” is appropriate in this section. Section 4.4.5 of the Temporary Specification provides a mechanism for third parties to contact Registered Name Holders to address “technical issues and/or errors with a Registered Name or any content or resources associated with such a Registered Name.” With regards to the question about ICANN being a “content regulator,” Section 1.1.c of ICANN’s Bylaws makes clear that ICANN does not regulate content. Thank you. Best regards, Marika, Berry, and Caitlin

1 0

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

Aug. 9, 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, 14 August, 13:00UTC. Best regards, Marika, Berry, and Caitlin High-level Notes/Actions: Confirmations regarding the face-to-face meeting are expected to be sent out shortly. The message will also include details on how to make travel arrangements. The leadership and support team is considering how to speed up the triage effort - for example, we might continue the triage effort off-line based on survey responses so that we can start substantive discussion sooner, as early as next week. An assessment will be made after today’s meeting. The EPDP Leadership Team compiled the survey results and prepared “issue summaries” to capture the themes within the rationale reported by the Team members. These summaries are a tool to facilitate the discussion and should not be viewed as authoritative; the Team may provide feedback on the issue summaries by responding to the list. The next meeting is Tuesday 14 August at 13.00 UTC. The deadline for submission of Part 2 of the survey is Friday, 10 August at 19:00 UTC; for part 3, the deadline is Wednesday, 15 August at 19:00 UTC. Questions for ICANN Org from the EPDP team: 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? Regarding Temporary Specification section 4.4.13 - Handling contractual monitoring requests: which data sets will be required to measure compliance against which contractual provisions? All Action items: EPDP Team members to complete survey part 2 by Friday, 10 August at 19:00 UTC EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC Question for Org Liaisons: what is the intention behind section 4.4.8? Staff to communicate details regarding EPDP Team meeting as soon as possible. These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ. 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair Getting close on confirming location and timing of F2F meeting. Announcement is expected to be made later today, including information about how to arrange travel. Please note that third survey is due Wednesday 15 August at 19.00 UTC Leadership considering how to speed up triage effort - for example, continue triage effort off-line based on survey responses and dive into substantive discussion sooner, as early as next week. Will see how this meeting goes and write up thoughts about next steps to be shared with the EPDP Team for input. 3. Summary of responses to EPDP Input Survey Part 1 - Results for Appendix A – Registration Data Directory Services See summary of responses in slide deck Even though the green sections indicate agreement, it sometimes is more about the sentiment that is agreed with, but there are still edits suggested, so review still needed. 4. Substantive Discussion of Temporary Specification (beginning with Section 4.4.7 – 4.4.13, 4.5 and Appendix A - Registration Data Directory Services) – see updated spreadsheet attached. Part 1 of the Survey can be found at https://www.surveymonkey.com/r/CC6F9F8 4.4.7. Enabling the publication of technical and administrative points of contact administering the domain names at the request of the Registered Name Holder; Issue summary: Opinions not in favor of this section question the utility of this voluntary data submission and whether voluntary data submissions should be included in the temporary specification. RrSG: not so much questioning the voluntary nature but these technical and administrative contacts are a relic from a previous era and hard to justify collection in the context of data minimization principles as outlined under the GDPR. If the contacts are the same/duplicate, then it is not minimized data. If they are different, then how do we track consent between Registrant and the other (Admin/Tech) contacts? Admin/Tech does have utility in some instances - how do registrars establish that these are no longer in use? ICANN policies have different roles and responsibilities relating to those contacts, such as IRTP, WHOIS data reminder, UDRP. This is data that is used to satisfy ICANN policies. 90-95% are estimated to be duplicates between registrant / tech / admin / billing contact. Why collecting and sharing this duplicative information? Tracking consent is an issue when contacts are different. SAC044 specifies: Maintaining administrative and technical contacts plays a role in reducing single points of failure or attack. 4.4.8. 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; Issue summary: Explanation opposed to this section is not sufficiently detailed to adequately describe the issue. For example, what is the distinction among DNS Abuse, cybercrime and intellectual property theft? 4.4.9. Providing a framework to address appropriate law enforcement needs; Issue summary: There is a suggestion that LEA access to personal data needn't pass the balancing that data can be disclosed when legitimate and not overridden by fundamental rights. The preamble should refer to Art.6 of the GDPR. Must LEAs demonstrate the right to access data? GAC: Issue summary is correct on 4.4.8 and 4.4.9 - situation needs to be described better. NCSG: 4.4.8 do agree, but with a qualifier / suggestion. Detailing framework for access will come later but need to pinpoint who are the actors with legitimate interests. Also linked to the discussion on ICANN's mission. Put forward proposed replacement text. It seems to imply / create the impression that LEA are always legitimate, but there are plenty of arguments between DPAs and LEA concerning the proportionality. GAC: Article 2 of GDPR states that several categories/types of processing fall outside its scope and thus are NOT subject to the balancing test of Article 6(1)(f). This includes processing for criminal law enforcement and by competent authorities for safeguarding against and the prevention of threats to public security, which falls outside the scope of the GDPR and instead is subject to Directive (EU) 2016/680. Moreover, Article 6 of the GDPR provides for lawful processing in a number of circumstances as set forth in Article 6(1)(a) - (e), such as processing necessary for the performance of a task carried out in the public interest, that also are not subject to the balancing test of “overridden by the interest or fundamental rights” in (f). Finally, Article 6(1) also states that (f) “shall not apply to processing carried out by public authorities in the performance of their tasks.” RrSG: concern about going into content – so summary is correct on 4.4.8. Spec 11 / framework for registry operators to respond to security threats includes what is considered within scope for ICANN (phishing, malware distribution, botnets). May be worth reviewing in this context. Question for Org: what is the intention behind section 4.4.8? There is data that LEA can legally require of organizations - that is limited to the jurisdiction they’re in, work on cross-border transfer in EU being discussed. Tech industry have started recognizing requests for certain types of data from outside its jurisdiction as long as they are not breaking local privacy laws. This voluntary collaboration may not be supported in all jurisdictions. Not ICANN's role to fix MLATs. 4.4.10. Facilitating the provision of zone files of gTLDs to Internet users; Issue summary: Given the distinction between zone file data and registration data, whether zone file contains personal data, and the fact that zone file data is currently available - can this section remain? NCSG & RrSG: not clear on how registration data facilitates provision of zone files of gTLDs to Internet users. Does this belong in a WHOIS spec? There are other processes that support use cases requiring zone file data. Need to also consider other parts of processing, not only collection. May need to be more specific what applies in certain instances? For example, you may collect here for the purpose of safeguarding, but it is actually not shared. Part of the reason for focusing on collection is to think through all the steps that would follow, what processing would take place in addition to collection - if you cannot answer that it the affirmative, should you be collecting the data in the first place? 4.4.11. Providing mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure, or other unavailability of a Registrar or Registry Operator; Issue summary: Is it accurate to say there is general approval of this data use so long as ICANN does not have access to the registration data (which is thought to be the case)? RrSG: response to business failure of contracted party is handled by a separate mechanism than WHOIS so it is not relevant. Escrow system is used for that. Isn't escrow escrowing WHOIS data? It is escrowing a subset and a superset of WHOIS data. Some of the information is not published in WHOIS. Isn't it necessary to include it here as it is being used for purposes like escrow? Isn't that one of the reasons why that information is collected? There may be other ways in which the same purpose can be achieved. May need a graphic to describe different steps in detail. Should be clear about what our mission is - main goal is to go through the temp spec and determine whether it should become a consensus policy. Does the temp spec actually deal with everything so that it is compliant with GDPR? There may be some omissions that need to be addressed. If it is registration data it includes all the data that is submitted but also data that may be automatically generated as a result of the domain name registration, which may also become personal information. Need to make sure that we use the same terminology - WHOIS is a display mechanism, registration data itself can have other purposes. 4.4.12. Coordinating dispute resolution services for certain disputes concerning domain names; and Issue summary: Except for the standard registry response, there appears to be consensus support for this section. Recommendations for enhancement can occur in the next step. 4.4.13. Handling contractual compliance monitoring requests, audits, and complaints submitted by Registry Operators, Registrars, Registered Name Holders, and other Internet users. Issue summary: Where there is disagreement with this section, the disagreement focuses on those specific data needs, without which the compliance task would be impossible to accomplish. What are the reasons for compliance having access to this information? Broad array of uses for WHOIS as it relates to compliance activity of ICANN. Important to have access to effectively do their job. May need to ask for specification on what that job to assess if it is a legitimate purpose outweighing the privacy of individuals. 4.5. In considering whether Processing of Personal Data contained in Registration Data is consistent with Article 6(1)(f) of the GDPR, the GDPR requires ICANN to balance the legitimate interests described above with the interests, rights, and freedoms of the affected data subject. ICANN finds that the Processing is proportionate for the following reasons: see 4.5.1., 4.5.2. 4.5.3, 4.5.4, 4.5.5. Issue summary: Those not supporting this provision found the rationale in sections 4.5.1 et.seq. unconvincing. The alternative approach might be, as discussed earlier, to discuss the data collection and disclosure purposes recommended in 4.1.1 et.seq. and develop this section, if needed, after that. Significant disagreement with this section. May need to be updated / mapped to outcome on other sections such as 4.1.1. and 4.4. Some of the terms in this section may need further clarification such as 'limited' and 'unjustified'. APPENDIX A 1. Registration Data Directory Services 1.2 RDDS Search Capabilities 1.2. RDDS Search Capabilities 1.2.1. Where search capabilities are permitted and offered, Registry Operator and Registrar MUST: (1) ensure such search capability is in compliance with applicable privacy laws or policies; (2) only permit searches on data otherwise available to the querying user, based on whether the user only has access to data publicly available in RDDS or whether the user has access to non-public Registration Data; (3) only provide results otherwise available to the querying user based on whether the user only has access to data publicly available in RDDS or whether the user has access to non-public Registration Data; and (4) ensure such search capability is otherwise consistent with the requirements of this Temporary Specification regarding access to public and non-public Registration Data. 1.2.2. Where search capabilities are permitted and offered, Registry Operator and Registrar MUST offer search capabilities on the web-based Directory Service and the RDAP service (when implemented). Issue Summary: All parties agree that RDAP will be implemented regardless of the date provided in Section 1.1 (which should be removed). There is some uncertainty as to whether a search capability should be a contractual requirement, and whether such a provision such as Section 1 is required at all given the current contract, and also that the risks associated with the aggregation of data must be addressed. RySG: search capabilities are not required for all registries, but new gTLD contract does include language requiring support for search capability. In the base registry agreement there is already language included that should be sufficient as such language in temp spec is unnecessary and more burdensome to implement. For LEA this search ability is really important, even if it is anonymized and likely a redline. Also important for commercial entities who do reverse WHOIS look-ups or correlation analysis. This has been hampered after 25 May so some are of the view that the search capability should be required instead of optional. Does the Registry agreement require this functionality or just allow it? New gTLD RA allows it, but if applicant has said in application that it would offer searchable WHOIS, the applicant is required to include it in the RA. However, it is possible through RSEP to remove searchable WHOIS. RrSG does not support making this mandatory - questioning the legality of offering this as well as the scope of converting WHOIS in a pseudo surveillance system. 2.1 - 2.3 (when data is restricted) Requirements for Processing Personal Data in Public RDDS Where Processing is Subject to the GDPR 2.1. Registry Operator (except where Registry Operator operates a "thin" registry) and Registrar MUST apply the requirements in Sections 2 and 4 of this Appendix to Personal Data included in Registration Data where: the Registrar or Registry Operator is established in the European Economic Area (EEA) as provided in Article 3(1) GDPR and Process Personal Data included in Registration Data; the Registrar or Registry Operator is established outside the EEA and offers registration services to Registered Name Holders located in the EEA as contemplated by Article 3(2) GDPR that involves the Processing of Personal Data from registrants located in the EEA; or the Registrar or Registry Operator is located outside the EEA and Processes Personal Data included in Registration Data and where the Registry Operator or Registrar engages a Processor located within the EEA to Process such Personal Data. 2.2. For fields that Sections 2.3 and 2.4 of this Appendix requires to be "redacted", Registrar and Registry Operator MUST provide in the value section of the redacted field text substantially similar to the following: "REDACTED FOR PRIVACY". Prior to the required date of implementation of RDAP, Registrar and Registry Operator MAY: (i) provide no information in the value section of the redacted field; or (ii) not publish the redacted field. 2.3. In responses to domain name queries, Registrar and Registry Operator MUST treat the following Registrant fields as "redacted" unless the Registered Name Holder has provided Consent to publish the Registered Name Holder's data: Registry Registrant ID Registrant Name Registrant Street Registrant City Registrant Postal Code Registrant Phone Registrant Phone Ext Registrant Fax Registrant Fax Ext Issue Summary: Some parties believe that section 2.1 (coupled with sec. 3) is overly broad in that: GDPR data restrictions can be applied globally and include entities (registrars, registries, registrant) located outside the EEA, and data restrictions need not be applied to Legal persons where personal data is not included in the record. Others say that the legal/natural distinction cannot be made a priori and such a distinction is not implementable. Also, the privacy language prescribed (sec. 2.2) could be required prior to RDAP implementation. Some urge additional data be redacted as personal information can be gained from them: e.g., organization name, city, postal code. The Temporary Specification mentions "consent" without a requirement or specification for such. This group may take that up. Should thin registries should be required to move to thick as part of this Temporary Specification? Consider remaining sections at next meeting. Sharing of draft triage document with the EPDP Team will help in completing the triage effort. Leadership hopes to share this shortly with EPDP Team for review. 5. Wrap and confirm next meeting to be scheduled for Tuesday 14 August at 13.00 UTC. (Part 2 Survey results due Friday, 10 August by close of business.)

1 0

Recordings, attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Thursday, 09 August 2018
by Terri Agnew Aug. 9, 2018

Aug. 9, 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, 09 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: <https://community.icann.org/x/nAtpBQ> https://community.icann.org/x/nAtpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-temp-spec-registration-data-09aug18-e n.mp3 AC Recording: <https://participate.icann.org/p2z1tx9n4wy/?OWASP_CSRFTOKEN=14dea907460b8fed 1934c6322f81020ab8465cb463a6521d925e42e825da8334> https://participate.icann.org/p2z1tx9n4wy/ ** 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/> https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: <https://community.icann.org/x/IYEpBQ> https://community.icann.org/x/IYEpBQ Thank you. With kind regards, Terri

1 0

Welcome - EPDP on the Temporary Specification for Registration Data
by Kurt Pritz Aug. 9, 2018

Aug. 9, 2018

Dear All: I am honored to be named chair of this EPDP team. I know many of you well and look forward to working with all of you. I’ve attached some thoughts about the operation of our team. These suggestions are intended to increase our effectiveness and facilitate the building of consensus. I appreciate your comments on any or all of them, either during the meeting or offline. The attached outline tracks to the meeting agenda, which is being sent out simultaneously with this email. If you have questions about the agenda items, please check the document attached here for some degree of explanation. Our first meeting (1 Aug 14:00UTC) will concern mainly process issues but I have reserved some time at the end for substantive discussion as we should get started in some small way. I look forward to seeing you all on Wednesday. Sincerely, Kurt

7 9

Audio cast information for alternates and observers August 9th 2018, 13:00 UTC
by Nathalie Peregrine Aug. 9, 2018

Aug. 9, 2018

Dear all, Non-members can follow the third EPDP call taking place today at 13:00 UTC via the audio cast: Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u Agenda wiki page: https://community.icann.org/x/nAtpBQ Kind regards, Nathalie Nathalie Peregrine Manager, Operations Support (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Email: nathalie.peregrine(a)icann.org <nathalie.peregrine(a)icann.org%20> Skype: nathalie.peregrine.icann Find out more about the GNSO by taking our interactive courses<applewebdata://EB3A6F47-9760-400D-A39B-A7EFFC56B467/learn.icann.org/courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>

1 0

Proposed Agenda for EPDP Tam Meeting #3 (Thursday 9 August at 13.00 UTC)
by Marika Konings Aug. 8, 2018

Aug. 8, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 9 August at 13.00 UTC. Best regards, Caitlin, Berry and Marika ==================== EPDP Meeting #3 Agenda Thursday, 9 August 2018 1. Roll Call & SOI Updates 1. Welcome and Updates from EPDP Team Chair 1. Summary of responses to EPDP Input Survey Part 1 - Results for Appendix A – Registration Data Directory Services 1. Substantive Discussion of Temporary Specification (beginning with Section 4.4.6 – 4.4.13, 4.5 and Appendix A - Registration Data Directory Services) – see updated spreadsheet attached. * Part 1 of the Survey can be found at https://www.surveymonkey.com/r/CC6F9F8 1. Wrap and confirm next meeting to be scheduled for Tuesday 14 August at 13.00 UTC. (Part 2 Survey results due Friday, 10 August by close of business.) 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-…>.

3 2

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

Aug. 8, 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, 9 August, 13:00UTC. Best regards, Marika, Berry, and Caitlin High-level Notes/Actions: While it is not confirmed, the likely dates for the EPDP Face-to-Face are Sept. 24 -26 (Mon – Wed) and most likely located in Los Angeles due to: cost, the headquarters’ ability to accommodate the size of the group as well as meeting team ability to organize a meeting on such short notice. Please do not book travel yet, but tentatively pencil-in these dates. Further to Rafik Dammak’s appointment as Vice-Chair, members of the EPDP team have suggested ways to escalate potential conflicts that should clear the path to his confirmation. Given the lack of consensus on most sections of the Temporary Specification, it seems beneficial to compile the triage report as soon as possible, rather than to spend time to resolve differences. That will be left to the stage of formulating the first Initial Report. The EPDP Leadership Team compiled the survey results and prepared “issue summaries” to capture the themes within the rationale reported by the Team members. These summaries are a tool to facilitate the discussion and should not be viewed as authoritative; the Team may provide feedback on the issue summaries by responding to the list. The next meeting is Thursday 9 August at 13.00 UTC. The deadline for submission of Part 2 of the survey is Friday 10 August at 19:00UTC. Questions for ICANN Org from the EPDP team: The Team seeks clarification on the exact expiry date of the Temporary Specification. In Section 3, the effective date of the Temporary Specification is 25 May 2018, but was adopted on 17 May 2018. If the Board is considering any amendments to the Temporary Specification, it would be helpful if the EPDP Team can be made aware of any proposed changes in advance. Is the Board currently considering any amendments to the Temporary Specification? To address what requirement? When ICANN refers to “security” as part of its mission - can ICANN describe what types of security are included?? With regard to the term “content,” in Section 4.4.5 - can ICANN provide context for use of the term? It is generally believed that ICANN does not see itself in the role of a content regulator but there are scenarios where use of the term “content” is appropriate in this section. All Action Items: ICANN Support Staff to capture any questions where a response is needed from ICANN Org (see above). ICANN to draft first portion of Triage document to demonstrate how information will be organized and for EPDP Team review. EPDP Team to review issue summaries and share any proposed edits/additions with the mailing list for inclusion in the triage document. EPDP team to complete the second part of the survey by Friday, 10 August, 19:00UTC. EPDP Leadership Team to look into creating a matrix (collection, uses and disclosure of data vs. the potential recipients of data) to help describe data flow scenarios. We will use the work that has already been done on this by the RDS PDP WG. 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. Welcome and Updates from EPDP Chair While it is not confirmed, the likely dates for the EPDP Face-to-Face would be Sept. 24 -26 (Mon – Wed) in Los Angeles due to the headquarters’ ability to accommodate the size of the group as well as meeting team ability to organize a meeting on such short notice. Please do not book travel yet, but tentatively pencil in these dates. Requests for Early Input were sent out to all SGs/Cs/ACs. This exercise is slightly redundant with the exercise we are already doing since this team is representative, but we are obliged to follow the PDP requirements. See https://community.icann.org/x/Ag9pBQ. Further to questions or concerns about Rafik Dammak as being the Vice-Chair, the GNSO Chair has agreed to step in, or designate a representative, if there is any sort of disagreement that involves the Vice-Chair / Liaison so that the remaining issues can be resolved. One alternate for ALAC has bad connectivity and as a result has difficulty following the audiocast – would it be possible to arrange dial-out instead? 2. Roll Call & SOI Updates Roll call will be taken from Adobe Connect. 3. Overview of EPDP Input Survey Part 1 Results Part 1 of the Survey can be found at https://www.surveymonkey.com/r/CC6F9F8 Thanks to all for the feedback that went into the responses – the rationale given was helpful and will be a useful tool in carrying the conversation forward in both the triage exercise and later in the process. The leadership team attempted to collate the survey results in a meaningful way, but due to the large amount of information, it may be difficult to display. It may be helpful to look at (1) the spreadsheet of survey results, which was sent around yesterday, and (2) a copy of temporary specification separately during the conversation. Six takeaways from the survey results: There is not consensus for most sections of the Temp Spec, but the rationales provided were helpful. There were some suggestions to focus on legitimate purposes (4.4.1 – 4.4.13) first so that it will inform the discussion of other interrelated sections of the Temp Spec. Given the lack of consensus, it would be preferable to complete the triage report for the GNSO Council right away so that we can begin delving into the substance. The rationales provided in the survey will serve as the basis for the triage report. The goal for the triage report will be to create a summary of the issues detailed in the survey results. The originally-provided survey deadlines were very ambitious, and in response to feedback received, Part 2 will now be due Friday, 10 August and Parts 3 and 4 will be due Sunday, 19 August. Suggested path forward: triage is intended to be an abbreviated process that details the consensus levels of the Temporary Specification. The plan is to spend the next few meetings sharing thoughts and comments from the sections surveyed. The EPDP Leadership Team suggested some neutral wording; however, this is for discussion only, and feedback is welcome. To confirm, the EPDP Team’s next meeting will be Thursday 9 August at 13.00 UTC (as originally scheduled). The date for submission of Part 2 of the survey will be Friday 10 August at 19.00 UTC. Suggestion to reconsider the meeting schedule, as the current schedule requires a lot of hours. 4. Substantive discussion of Temporary Specification In the interest of time, the EPDP Leadership Team grouped the issues for discussion. As an example of an issue summary, please note in Section 1 (Scope), may found the clause beginning with “unless ICANN determines…” to be problematic. In Section 3, the effective date of the Temp Spec is 25 May 2018, but was adopted on 17 May 2018, but can the Team get clarification on the exact expiry date of the Temp Spec? Action Item: ICANN Org to confirm precise expiry date of the Temp Spec. If the Board is considering any amendments to the Temp Spec, it would be helpful if the EPDP Team can be made aware of any proposed changes in advance. Action: EPDP Policy Support staff to capture questions in writing and send to the ICANN Org for response. EPDP discussion: GDPR is not the only data protection system, and national data protection systems should not be subordinated by the GDPR. It appears the EPDP Team has consensus on the removal of “unless ICANN determines in its reasonable discretion” clause. EPDP Team can “put a pin” in this and confirm if this can be removed this from the next iteration. The Temp Spec has various timelines within it (in 30 days, 90 days, etc.), and the team needs to pay attention to implementation timeline dates and how these might be affected if changes are made to the Policy Effective Date following the adoption of the policy recommendations. The next quadrant for discussion includes 4.1 – 4.4.2. Question: before we begin discussion, would it be possible to determine which determinations of lawfulness we can determine on our own, and which will be determined for us, i.e., in court cases? Do we have an agreed upon approach to how we find whether something is lawful? We do not yet have an agreed upon approach or a determination of what authority we have. At this state, however, we would like to summarize the rationales and compile the triage report. Ultimately the arbiter of what is a legitimate purpose will be determined by case law, so the EPDP Team should deal with the rationale of 4.4. The NCSG objected to facilitation for all kinds of third party interests. While the NCSG has agreed to access of certain data in the survey, it did this by looking at ICANN’s mission and role of security and stability of the DNS, rather than third party interests. Several responses indicated that the team should consider looking at the uses of the data first. Others suggested that rather than looking at uses, the team should first look at the ICANN’s mission and purpose. What type of security are we talking about when we refer to ICANN’s mission – network security? Who determines that a purpose is legitimate? What is personal data? Is there anywhere to find the list of personal data? The RDS PDP WG failed to resolve these issues of purposes, and a post mortem on this would be very valuable as to why the RDS PDP WG went in circles. Since the RDS PDP WG discussions, ICANN has received more input from DPAs. It would be useful to consolidate the advice ICANN has received and cut short the items where the EPDP Team is conflating the issue. EPDP Team has to figure out how the DPAs have already opined on some of these issues. Security is within ICANN’s remit – unless data is collected, it cannot be made available to other people. There are provisions in the GDPR that consider third party needs. If something is clearly not supported by the law, the group would be foolish to try to include it in the policy, but no court is ever going to add more purposes. Rather, the courts will chip away at purposes in certain jurisdictions. The EDPB letter is asking ICANN to clearly note its purposes for collecting data. There is availability to process data that is already collected. Action item: consider creating table of data elements – what data elements are necessary for ICANN, how it is used, and what data elements are needed for third parties? Article 6 of GDPR does allow legitimate interest of controller or third party. A sweeping statement has been made about what happens if ICANN no longer has a mandate of collection and disclosure of data – how does the group envision that happening if ICANN is no longer in the picture? The above question reveals a misunderstanding – with a domain name registration, the registrar will always collect information, and law enforcement can always collect this information from the registrar, rather than from ICANN. ICANN will collect data for its own purposes, law enforcement will follow its process, but ICANN’s purpose is not to be law enforcement on the internet. In response to some of the questions raised on today’s call – it may be helpful to have trainings on the GDPR. Putting ICANN aside for a moment, when we leave from this room, law enforcement will make requests from Registrars/Registries, and businesses and trademark owners will do the same. The purpose of the team working together is not to work on validation of ICANN, but rather, work out mechanisms where legitimate purposes that meet the relevant threshold are accommodated in an economical and transparent way. The Temporary Specification is here, and there will be future requests for data: we need to find a way to evaluate the purposes and decide as a group how to accommodate them. Is ICANN Org and the Board hoping the EPDP Team will build the legal argument as to what legitimate purposes are? If there is internal work happening, this is crucial to the work to understand this. Outside the United States, due process in flawed. The process can take anywhere from 3-12 months. The group’s purpose here is not to replace WHOIS with something identical, but please be mindful of saying there are other mechanisms, because those mechanisms do not always work well. This is a two-step process: what are legitimate purposes, and which ones are not overridden by the GDPR? We are deep into the discussion that happens after the triage discussion. The slide on the screen shows summaries of the issues noted in the survey responses. Question: if we do not believe that the issue summarization text is necessarily complete, how can we best address this? Red lines? Flagged during the call? Action item: EPDP Team to review issue summaries and share any proposed edits/additions with the mailing list for inclusion in the triage document. In sections 4.4.1 and 4.4.2, law enforcement needs to pass the relevant threshold – legitimate interest not overridden by fundamental rights. 4.4.2 seems to be a catch-all provision – this may address the GAC’s concern that the Temp Spec limits the number of legitimate purposes. In section 4.4, the balancing test is important, but some types of processing fall outside this scope and are not subject to the balancing test, so we need to understand that it’s not always the case that the balancing test is required. 4.4.2 does not entirely cure the problem – a legitimate interest is just one basis under GDPR, and there are other data protection sources that we are not gathering at the moment in different jurisdictions that will not be covered by 4.4.1 – 4.4.13. The best path forward may be to create the triage report on the sections we have reviewed so that the group can see what the triage report would look like. 4.4.1 is fine for the NCSG – this data needs to be collected for the purpose of the registration. 4.4.2 is an odd construct – the purpose is to provide access to the data. This statement is circular. 4.4.2 seems to say that anyone who wants the data can get it – this is begging the question – ICANN is in no position to determine what is legal. 4.4.2 opens the door that if you pass the GDPR test, you can add use of the data to this list, but there may be a better way of doing this. What we are missing here is that the WHOIS system provides a public service. Through the Temp Spec, we need to recognize the public interest served by WHOIS. As a whole, when you step back – we’re talking about ICANN’s role in the public interest that supports this directory service. The legitimate interest is not for the people trying to access the data, but rather, the legitimate interest of the processor of the data. The collection and publication of RDS data is done in the public interest and is not necessary for registrars to communicate with their customers. It is not necessary for registrars: WHOIS data is collected over and above the data registrars already have. How do you collect information of the registrant without name, address, etc.? The directory is necessary to establish the registrant’s right in the domain name. This is a legitimate and unassailable interest in ICANN requiring the collection of this data. Collection of data for purposes of publication in a directory is not needed to serve the customers or to register a domain name. There is no public interest definition in ICANN’s publication of a directory service. The legitimate interest does not only reference the controller. See Article 6(f) of the GDPR. It is important to note that third parties are considered in the GDPR in Article 6. What is a legitimate purpose? Can we get some criteria definitions around this? Registrars may also comply with other data protection law or where commercially necessary. This is a fundamental question. How far can this exercise as an EPDP go? In a temporary specification, you can attempt to comply with other laws, although we’re only focused on the GDPR at the moment, but it seems nonsensical to allow this where commercially feasible – it appears like we are only concerned with laws that have heavy financial penalties. The situation could be remedied by adding something like “since GDPR appears to be leading the world in data protection as a model, parties should comply with the GDPR in other jurisdictions as required.” There are a number of national privacy laws that are proposed or in the works – it is impossible to predict where the landscape is going, so we’ll have to treat that as a known unknown – that the future laws will be mostly or entirely compatible with GDPR, or service providers. 4.4.3 appears to be a header for the next four sections since all have to do with registrants. Each purpose needs to be justified and compliant with GDPR. It is hard to know what precise amendment to propose because the level of principle is not reflected in the draft. Another important point for contracted parties is necessity of collection of data, while it may be necessary to collect, it may not be necessary to publish. We should go through collection, use, and disclosure. As referenced earlier, we could create a list of the data and how it’s used. It could be a matrix. The RDS PDP WG already did something similar so maybe that could serve as a basis? Section 4.4.5 should be read very carefully because ICANN does not regulate content. Knowing the term content raises red flags, there must have been some sort of reason why this included – let’s capture this question. Question for ICANN Org – is there a reason for the inclusion of the term content in section 4.4.5? In 4.4.3, we are talking about the reliability, but in 4.4.4. and 4.4.5 does not mention reliable. We need to define who defines reliable; however, this word should be kept. SSAC believes content should stay in 4.4.5. If your domain name is infected, it may be spewing out spam at high rates, and it is helpful to contact you with respect of that content. Rather than the type of content, it is talking about content more generally. It would be helpful to hear from the team how we can best conduct these discussions to best get through the triage period. We propose to finish the rest of the surveys and assemble that material unless members have alternate suggestions. 5. Wrap and confirm next meeting to be scheduled for Thursday 9 August at 13.00 UTC

1 0

Recordings, attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Tuesday, 07 August 2018
by Terri Agnew Aug. 7, 2018

Aug. 7, 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, 07 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: <https://community.icann.org/x/kgtpBQ> https://community.icann.org/x/kgtpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-07aug18… AC Recording: <https://participate.icann.org/p5xqvetfsh7/?OWASP_CSRFTOKEN=14dea907460b8fed…> https://participate.icann.org/p5xqvetfsh7/ ** 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/> https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: <https://community.icann.org/x/IYEpBQ> https://community.icann.org/x/IYEpBQ Thank you. With kind regards, Terri

1 0

EPDP Team - Temporary Specification Input Surveys
by Caitlin Tubergen Aug. 7, 2018

Aug. 7, 2018

Dear All: In order to facilitate the triage of the Temporary Specification as outlined in the EPDP Team Charter as the first deliverable, please work with your appointing organization team members to complete the below surveys. Please find the relevant survey links and accompanying deadlines below: Part 1, due Monday, 6 August 2018 by 23:59 UTC: https://www.surveymonkey.com/r/CC6F9F8 Part 2, due Wednesday, 8 August by 2018 23:59 UTC: https://www.surveymonkey.com/r/7BMRCNS Part 3, due Monday, 13 August 2018 by 23:59 UTC: https://www.surveymonkey.com/r/7PWQPP7 Part 4, due Sunday, 19 August 2018 by 23:59 UTC: https://www.surveymonkey.com/r/9KD5K79 Thank you. Best regards, Marika, Berry, and Caitlin

10 16