August 2019 - Gnso-epdp-team

**AUDIO CAST UPDATE / Meeting Invitation: Observers GNSO Temp Spec gTLD RD EPDP - Phase 2 Extraordinary call | Thursday, 29 August 2019 at 20:00 UTC
by Terri Agnew Aug. 29, 2019

Aug. 29, 2019

UPDATED AUDIO CAST: Listen in browser: http://stream.icann.org:8000/stream01 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 29 August 2019 at 20:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) 13:00 PDT, 16:00 EDT, 22:00 Paris CEST, (Friday) 01:00 Karachi PKT, (Friday) 05:00 Tokyo JST, (Friday) 06:00 Melbourne AEST For other times: https://tinyurl.com/y2z6kocj [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y2z6kocj&d…> Agenda Wiki: https://community.icann.org/x/EY3kBg The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: SEE ABOVE UPDATED LINKS If needed, an option to join via telephone has been added for this meeting. Passcode: EPDP Dial in numbers: Country Toll Numbers Freephone/ Toll Free Number ARGENTINA 0800-777-0519 AUSTRALIA ADELAIDE: 61-8-8121-4842 1-800-657-260 AUSTRALIA BRISBANE: 61-7-3102-0944 1-800-657-260 AUSTRALIA CANBERRA: 61-2-6100-1944 1-800-657-260 AUSTRALIA MELBOURNE: 61-3-9010-7713 1-800-657-260 AUSTRALIA PERTH: 61-8-9467-5223 1-800-657-260 AUSTRALIA SYDNEY: 61-2-8205-8129 1-800-657-260 AUSTRIA 43-1-92-81-113 0800-005-259 BELGIUM 32-2-400-9861 0800-3-8795 BRAZIL RIO DE JANEIRO: 55-21-40421490 0800-7610651 BRAZIL SAO PAULO: 55-11-3958-0779 0800-7610651 CHILE 1230-020-2863 CHINA CHINA A: 86-400-810-4789 10800-712-1670 CHINA CHINA B: 86-400-810-4789 10800-120-1670 COLOMBIA 01800-9-156474 CROATIA 080-08-06-309 CZECH REPUBLIC 420-2-25-98-56-64 800-700-177 DENMARK 45-7014-0284 8088-8324 ESTONIA 800-011-1093 FINLAND 358-9-5424-7162 0-800-9-14610 FRANCE LYON: 33-4-26-69-12-85 080-511-1496 FRANCE MARSEILLE: 33-4-86-06-00-85 080-511-1496 FRANCE PARIS: 33-1-70-70-60-72 080-511-1496 GERMANY 49-69-2222-20362 0800-664-4247 GREECE 30-80-1-100-0687 00800-12-7312 HONG KONG 852-3001-3863 800-962-856 HUNGARY 36-1-700-8856 06-800-12755 INDIA INDIA A: 000-800-852-1268 INDIA INDIA B: 000-800-001-6305 INDIA INDIA C: 1800-300-00491 INDONESIA 001-803-011-3982 IRELAND 353-1-246-7646 1800-992-368 ISRAEL 1-80-9216162 ITALY MILAN: 39-02-3600-6007 800-986-383 ITALY ROME: 39-06-8751-6018 800-986-383 ITALY TORINO: 39-011-510-0118 800-986-383 JAPAN OSAKA: 81-6-7878-2631 0066-33-132439 JAPAN TOKYO: 81-3-6868-2631 0066-33-132439 LATVIA 8000-3185 LUXEMBOURG 352-27-000-1364 8002-9246 MALAYSIA 1-800-81-3065 MEXICO GUADALAJARA (JAL): 52-33-3208-7310 001-866-376-9696 MEXICO MEXICO CITY: 52-55-5062-9110 001-866-376-9696 MEXICO MONTERREY: 52-81-2482-0610 001-866-376-9696 NETHERLANDS 31-20-718-8588 0800-023-4378 NEW ZEALAND 64-9-970-4771 0800-447-722 NORWAY 47-21-590-062 800-15157 PANAMA 011-001-800-5072065 PERU 0800-53713 PHILIPPINES 63-2-858-3716 1800-111-42453 POLAND 00-800-1212572 PORTUGAL 8008-14052 ROMANIA 40-31-630-01-79 RUSSIA 8-10-8002-0144011 SAUDI ARABIA 800-8-110087 SINGAPORE 65-6883-9230 800-120-4663 SLOVAK REPUBLIC 421-2-322-422-25 0800-002066 SOUTH AFRICA 080-09-80414 SOUTH KOREA 82-2-6744-1083 00798-14800-7352 SPAIN 34-91-414-25-33 800-300-053 SWEDEN 46-8-566-19-348 0200-884-622 SWITZERLAND 41-44-580-6398 0800-120-032 TAIWAN 886-2-2795-7379 00801-137-797 THAILAND 001-800-1206-66056 TURKEY 00-800-151-0516 UNITED ARAB EMIRATES 8000-35702370 UNITED KINGDOM BIRMINGHAM: 44-121-210-9025 0808-238-6029 UNITED KINGDOM GLASGOW: 44-141-202-3225 0808-238-6029 UNITED KINGDOM LEEDS: 44-113-301-2125 0808-238-6029 UNITED KINGDOM LONDON: 44-20-7108-6370 0808-238-6029 UNITED KINGDOM MANCHESTER: 44-161-601-1425 0808-238-6029 URUGUAY 000-413-598-3421 USA 1-517-345-9004 866-692-5726 VENEZUELA 0800-1-00-3702 VIETNAM 120-11751 Thank you. Kind Regards, Andrea

1 0

Notes and action items from EPDP Team Meeting #16 - 29 August 2019
by Caitlin Tubergen Aug. 29, 2019

Aug. 29, 2019

Dear EPDP Team, Below, please find notes and action items from today’s EPDP Team meeting. As a reminder, the next EPDP Team meeting will be Thursday, 29 August at 20:00 UTC. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #16 Thursday, 28 August 2019 at 14.00 UTC Action Items SSAC EPDP Team Members to make agreed to changes and notify EPDP Support Staff when complete. Action: Support Staff to input LEA-2 use case into a Google Doc for feedback. Please see: https://docs.google.com/document/d/1bm8sdjrNHvNgftMK4f8s-U81FlNSIe2TVNlQKCX…. Action: EPDP Team members to submit comments for LEA-2 use case by tomorrow, Friday, 30 August. Please use the following link: https://docs.google.com/document/d/1bm8sdjrNHvNgftMK4f8s-U81FlNSIe2TVNlQKCX… Action: GAC colleagues to update the LEA-2 use case based on comments received by Tuesday, 3 September. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #16 Proposed Agenda Thursday, 29 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) Attendance will be taken from Zoom Remember to mute your microphones upon entry to Zoom. Please 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. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from Legal Committee · Questions from batch 1 were submitted to the list yesterday for plenary team review. · If there are no objections from the Team, these questions will be submitted to outside counsel. · EPDP Leadership gave a heads up to Bird & Bird that a set of questions will be forthcoming this week, noting that the EPDP Team would like to receive feedback in advance of its F2F meeting, scheduled on 9-11 September. · With respect to the 6(1)(b) question, some members of the Legal Committee will be refining the question and will be reverting to the EPDP Team with the updated question when available. · With respect to Question 3, the Team should not waste money on this question - as there is already advice on this topic in the city field memo. · The Legal Committee has concluded that it is important to ask this question, so if there is no objection, the Legal Committee will send these questions to Bird & Bird. · Raising this issue as a question that could be shaved off · The Legal Committee is looking for guidance in this specific case b) Reminder – contribute to google doc with questions for ICANN CEO / Strawberry Team in preparation for LA F2F meeting (see https://docs.google.com/document/d/1Q_0smZv58- rQ4RF9buAMBmt4PGVSk6gAYyLiPIOlyQU/edit [docs.google.com] · If any EPDP Members would like to add any questions or comments to the document, please do so using the above link. · It might be worth reaching out to the Strawberry Team to see if they have any updates since Marrakech for the EPDP Team. If any updates can be shared in advance, this will help the EPDP Team in formulating its questions to ICANN org. · The Strawberry Team is aware the EPDP Team is preparing questions and wishes to engage during the Strawberry Team. 4. Use case – second/final reading: When a network is undergoing an attack involving a domain name, and the operator(s) of that network need to contact the domain owner to remediate the security issue (DDOS, Botnet, etc.) [docs.google.com] (SSAC1) a) Overview of updates made in response to input received (SSAC) · The SSAC agreed with most suggestions provided in the document. · As a clarification, this is intended for network operators and not for third parties, unless the third party is designated as the operational security team. · The changes in Section B - “may be” is OK instead of “is required” · Administrative contact information was an oversight, so that should not have been included, and, as such, has been removed. · Section D - agree that 6(1)(f) is the appropriate basis in 99.9% of the cases, but there may be rare situations where critical infrastructure like hospitals have been taken down by botnets, which is why 6(1)(d) is included here. · Section E - highlighting that Recital 49 takes into account this situation, and this was one of the core purposes of RDS data · Section F - suggested add to the safeguards added to requestor - this has now been added · Section H - suggested additional safeguard applicable to data subject - agree to this add · Section J - there is no adequate accreditation body that currently accredits network operators b) Feedback from EPDP Team · Agree that legal basis will be declared by individual/entity making the request. If someone thinks it is a 6(1)(d), they will be free to do that and it will be up to the responding party to determine the validity of the claimed basis. · Why would you eliminate "high-volume automated" if you are concerned about DDoSing the SSAD? · Propose to keep both by adding “or” · The notion of accreditation occurring through distinct user groups is problematic - no such thing exists at the moment - this is calling for the formation of a global body. All of the use cases need to have and must develop a coherent notion of who does accreditation, where it comes from, and the idea of separate stakeholders doing it is not viable. · Interested in the lawful basis of the disclosing entity, not the requestor. Have a hard time with 6(1)(d) being included here. · Some EPDP Team members are arguing for high-volume queries. Does this use case require high volumes of automated requests for non-public registration data? · High volume does need to be accommodated within reason - with respect to this language - the same entity may need to make requests based on on a botnet that implicates hundreds of domain name · If an attack is ongoing, this would be a case where data is needed quickly. · SSAC to tighten up language in reference to high-volume requests. · There is a difference b/w accreditation and authentication. · Accrediting security practitioners is something that can be done by people in the industry so long as the appropriate framework is put into place by this Team. This topic should be further discussed in Los Angeles. · With respect to accreditation, individuals who want more liberal access to WHOIS data, are asking for sectoral access to data. You do not have to go to a global bureaucracy to investigate. You have a right to make an inquiry regardless of who you are if you have a lawful basis. It is odd that folks are asking for accreditation that does not guarantee anything. · Accreditation was not included as a hill to die on. It is something that could potentially be used down the line to speed up some speed bumps in this process. It is a possible avenue of identifying the requestor. It is not a guarantee of access or an elimination of the balancing test. · The IPC does not want a world where only accredited persons can request disclosure of RDS data. Accreditation is an important part of the discussion and is included in the EPDP Team’s charter. · If the responses are partially automated, it would be useful to look over the work the data commissioners have done over the years. · Action: SSAC to make agreed to changes and notify EPDP Support Staff when complete. c) Confirm next steps · Action: SSAC to make agreed to changes and notify EPDP Support Staff when complete. 5. Use case – final reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves (ALAC1) a) Overview of updates made in response to input received (ALAC) · There has been a lot of traffic on this list. In summary, one issue is whether consumer confidence is within ICANN’s mission. It does not matter. This is not an ICANN purpose; this is a 6(1)(f) case. Whether it is in ICANN’s mission or not is irrelevant. Whether it is a website or not is an issue that may have triggered the request by the user, but this is not an ICANN issue - it is a business practice of the contracted party. · Any user can submit a request. Whether or not we call it a use case or not will not stop this type of request. · With respect to automation, this will be changed to no, but if the Ry/Rr wants to automate this, it would be up to them. b) Feedback from EPDP Team · Does this particular use case intend to create policy recommendations? If not, can the Team park this and move on? · Rationales provided may belong in other use cases. · Isn’t WHOIS about the only place the internet user could go to identify who the registrant is for the phishing email? Individual users, particularly within a company that is being spear-phished - argues in favor of keeping this use case. The use case describes a situation and it may normatively recommend what we should with it. c) Confirm next steps 6. Use case – first reading: Investigation of criminal activity against a victim in the jurisdiction of the investigating EU LEA requesting data from a local data controller. (LEA 2) a) Intro to use case and overview of how/where this use case is different from LEA 1 (GAC) · Reason for having two similar cases is to help look at how different jurisdictions could affect policy recommendations the Team will make and how this could affect legal basis. · The investigating body and data controller are in the same jx. · Why non-public data is necessary -same reason as other use case. · Data needed is the same as LEA-1. · Changes to safeguard section - attempted to firm up the language and make it more encompassing · Action: Support Staff to input LEA 2 into a Google Doc for feedback. b) Feedback from EPDP Team · Is this a law enforcement use case for the same jurisdiction? But this understanding is incorrect? This use case is being looked at to tease out challenges when requesting data both inside and outside the jurisdiction? · Comparing the two LEA use cases will show how different jurisdictions are handled. c) Confirm next steps · Action: Support Staff to input LEA 2 into a Google Doc for feedback. · Action: EPDP Team members to submit comments by Friday, 30 August. · Action: GAC colleagues to update the use case based on comments received by Tuesday, 3 September. 7. Any other business (5 minutes) 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 29 August 2019 at 20.00 UTC (extraordinary meeting – intro to and initial feedback on zero draft) b) Thursday 5 September 2019 at 14.00 UTC c) Confirm action items d) Confirm questions for ICANN Org, if any

1 0

Fwd: [Ext] epdp Use Case LEA 2
by Marika Konings Aug. 29, 2019

Aug. 29, 2019

Please see attached for today’s meeting. Best regards, Caitlin, Berry and Marika Begin forwarded message: From: "LEWIS-EVANS, Christopher" <Christopher.Lewis-Evans(a)nca.gov.uk<mailto:Christopher.Lewis-Evans@nca.gov.uk>> Date: 29 August 2019 at 02:32:22 GMT-6 To: Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>>, "gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>" <gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>> Subject: [Ext] epdp Use Case LEA 2 OFFICIAL Marika, As promised an updated LEA 2 for todays meeting based from the input from LEA1. Thanks Chris Lewis-Evans This information is supplied in confidence by NCA, and is exempt from disclosure under the Freedom of Information Act 2000. It may also be subject to exemption under other UK legislation. Onward disclosure may be unlawful, for example, under data protection legislation. Requests for disclosure to the public must be referred to the NCA FOI single point of contact, by email on PICUEnquiries(a)nca.gov.uk<mailto:PICUEnquiries@nca.gov.uk>. All E-Mail sent and received by NCA is scanned and subject to assessment. Messages sent or received by NCA staff are not private and may be the subject of lawful business monitoring. E-Mail may be passed at any time and without notice to an appropriate branch within NCA, on authority from the Director General or their Deputy for analysis. This E-Mail and any files transmitted with it are intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please contact the sender as soon as possible.

1 0

Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019
by Caitlin Tubergen Aug. 29, 2019

Aug. 29, 2019

Dear EPDP Team: Please find notes and action items from today’s EPDP Team meeting below. As a reminder, the next EPDP Team meeting will be Thursday, 8 August at 14:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #11 Thursday, 1 August 2019 at 14.00 UTC Action Items EPDP Team to review the early input documents (the SSAD worksheet and the Google doc) that have been posted. Leadership will devote time to going over the input at the EPDP Team meeting in two weeks’ time. Further to the EPDP Team request, Staff support will put up the use cases as google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. SSAC to incorporate feedback from the EPDP Team in advance of the next EPDP Team meeting; the updates should also include an example of how accreditation can be done and by whom. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #11 Proposed Agenda Thursday, 1 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom · Remember to mute your microphones upon entry to Zoom. · Please 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. Confirmation of agenda (Chair) · Following comments made after the previous call regarding postponement of the accreditation discussion, EPDP Leadership proposed to continue discussion of use cases. · No objections to the agenda. 3. Welcome and housekeeping issues (Chair) (10 minutes) 1. Early input review – next steps · Some groups noted a further discussion of the early input submitted was needed. · Question to the Team: when will groups be prepared to discuss the early input received from the different groups? EPDP Team Feedback: · GAC will be sending in its early input today. · Support Staff was planning to review the input and take it into account when drafting recommendations for the Initial Report. When drafting, Support Staff plans to flag any opposing views or areas of disagreement that may need further discussion within the EPDP Team. · With respect to requirements around early input, there is an expectation that early input is reviewed by the Working Group. The Support Team has used the early input review tool to facilitate this review: https://community.icann.org/x/zIWGBg. In short, did the WG agree, disagree, and/or how does the WG plan to respond to the input. · Is there a way to incorporate the feedback into the worksheets and review the input as the WG deliberates on the respective topics? Answer: yes, Support Staff already incorporated the early input into the SSAD worksheets per the previous request of the EPDP Team. · The RrSG provided its early input prior to the deadline and also provided comments to a Google Doc - was this homework submitted properly? Answer: yes, the RrSG comments were received. · Not clear on what the purpose of this exercise is. · This is a GNSO requirement. · There seems to be a low level of interest in reviewing early input. Perhaps the Team can defer reviewing the early input as such and review it when the respective topics are discussed within the SSAD worksheet. · There are two separate activities Support Staff undertook at the request of the Team: (1) incorporate the early input into the SSAD worksheet, noting the relevant categories/topics; (2) create a Google Doc that allows groups to provide feedback on the early input received. Some of the input may relate to additional Charter questions, so the group may want to consider additional questions or topics as a result of feedback rather than assuming all input relates to topics already noted in the worksheet. · Chair proposal: · ACTION: EPDP Team to review the early input documents (both the SSAD worksheet and the Google Doc for providing feedback). Leadership will devote some time to going over the input in two weeks time. 4. Use Cases Categorization (10 minutes) Review results of the survey · The document on the screen represents the survey sent next week. · This categorization of use cases was put together by a small team - with the understanding that it may be possible to derive common conclusions from use cases that are deemed similar. · The objective of the survey was to identify the use case that was deemed the most representative of the group. Note: this does not mean the other use cases would not be considered. · Six groups responded to the survey. Some of the use cases were very close, so EPDP Leadership made some suggestions. · The proposed schedule also includes proposed deadlines. By Friday after the first reading, all proposed EPDP Team edits/concerns need to be submitted to the list. This will allow the author, with Staff Support assistance (if desired), to update the use case in advance of the next meeting, during which the second reading will occur. · The use case review will continue into late August. Then the group will need to consider what other use cases need to be considered or reviewed. Toward the end of August/early September, Leadership and Staff Support hope to share draft policy principles derived from the commonalities, which can serve as the basis for the F2F discussion. Confirm review order and schedule · Could SSAC-3 be reviewed next week? · The purpose of today’s reading is to raise concerns and not necessarily to answer them, which means Greg will have the ability to review the concerns and address them during the second reading, which will be next week. · Procedural suggestion: it is difficult to go back and forth in an email thread. Perhaps the group can consider using Google Docs? · Staff support will put it up the use cases as a google doc, with the understanding that the author will hold the pen in making updates / changes based on the input provided. · ALAC is not sure it would be a good use of time to review the ALAC use case today. · Groups should not be advocating a use case where something is always right/data will always be disclosed - these should be generic cases, wherein another member or alternate in the group should be able to discuss. In terms of manual balancing tests, this activity still needs to be discussed. 5. Use case – first reading continued: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack (45 minutes) Input from EPDP Team – questions, concerns, proposed modifications · The purpose of this reading is to continue last week’s discussion. Subsection B · With respect to phishing, non-law enforcement parties are concerned with taking down the domain name to block or mitigate phishing. They may not be interested in attribution and/or prosecution. These activities may need to be broken down into those specific cases in which disclosure of nonpublic information is necessary. · Attribution is necessary here to capture the gamut of domain names involved in the phishing enterprise. · With respect to task 3, accuracy of contact data is always desirable. With respect to inaccurate information, though, this may not be a sign of bad faith or criminal activity. With respect to cross-field address validation, there are many false positives. Cross-field address validation does not solve the issue; it sometimes exacerbates the issue. · If the Team is discussing a generic SSAC use case, this includes the need for disclosure of RDS data. · There is a challenge that if the use case is too specific, there will be too many use cases, but if they are too generic, there is an argument that it may not be specific enough. · Not arguing for proliferation of use cases, but rather discussing when disclosure is necessary. For example - Task 4 - suspending a domain name does not require disclosure. Task 2 - IP address is public in WHOIS records, so no disclosure is needed for that. Task 5 - borderline case - you could need disclosure, but perhaps it could be turned over to law enforcement. Task 3 - agree with GoDaddy that this is a completely different use case and is not part of mitigation of phishing. The tasks should be winnowed down to those that actually require disclosure. The tasks that are thrown out do not need to become new use cases. · Necessary under GDPR means reasonably necessary. With respect to Task 3, just because data is inaccurate does not mean there is fraud; however, when data is falsified, that typically does indicate fraud. · With respect to Task 4, how data is handled once it has been processed is important to consider. The way this use case is laid out allows the Team to see how the data is handled when it has already been disclosed. · Need a better understanding on what the Team will do with the use cases, and how do they trickle up to policy recommendations. · The use cases will be provided as an illustration for how the EPDP Team got to its recommendations. · While this is a useful case as a discussion instrument, request adding a footnote that this is a discussion instrument only. Secondly, on the accuracy issue - if inaccurate data shows criminal intent, we should consider taking down credit reporting bureaus. If this group has no delegation under law to prosecute, it cannot collect personal data. Just because this happens does not make it correct. Subsection C · Is tech contact still collected? If so, this should be removed from this report. · Tech contact may still be collected under Phase 1 recommendations. · Tech contact physical address was eliminated in Phase 1. · The specific data elements to be requested should be limited to the request at hand - if they are not needed for the specific investigation, they should not be requested/disclosed. Subsection D/E · Issue with the number of lawful bases for the parties here. Vital interest is a very difficult lawful basis - very few instances where this lawful basis can be used, so it is probably unrealistic for phishing. 6(1)(f) or 6(1)(c) may be better. · Subsection D looks like a shotgun approach to applying a lawful basis. This increases rather than decreases the vulnerability that this will be challenged. · How does 6(1)(b) apply to this use case? There is no description in Subsection E for how this will apply. · It may be of interest to look at BC-1 when reviewing these lawful bases, specifically 6(1)(b) and 6(1)(d). In this case, human trafficking may be involved, though in BC-1, BC elected not to include 6(1)(d). · As written, Subsections D and E do look like a shotgun approach. In the overwhelming majority of these cases, SSAC recognizes that 6(1)(f) would be the applicable lawful basis. There are limited edge cases, where a contract for phishing mitigation or similar is used and where 6(1)(b) would be applicable. · When writing these use cases, some of this discussion is premature until the Team receives further legal advice about lawful basis. · All lawful bases need to be deleted except 6(1)(f). The other lawful bases may be relevant for different use cases, but not this one. Subsection F · Be careful with the term code of conduct as this is a term of art in GDPR. Data processing agreement may be the more appropriate term here. Subsection G · No comments. Subsection H · With respect to the last sentence, this is already a requirement in the Registration Accreditation Agreement - curious why it needs to be included here. · Under the Temp Spec, the WHOIS inaccuracy process isn’t able to be utilized. · The WHOIS accuracy program has not changed, so the above statement is not correct re: the program not being utilized. Subsection I · Reverse search and wildcard search are not currently offered and this should not become part of the requirements. · These additional capabilities and functions were never part of the RDS functions - they were provided by third party data harvesting firms and should not be included here. · Functionality that hasn’t existed in the past should not be deleted as a safeguard just because it did not previously exist. · Item one for I is not being asked as a policy recommendation - simply pointing out that if there were a legal way to do this under GDPR, it would be helpful. Point 1 can be removed for purposes of this exercise. · Beware of making broad statements that certain activity is illegal or unethical. BC-2 shows where a wildcard search would be acceptable. · Wild card searches create a new role under this system as it could track registrant behavior across TLDs and registrars. We need to be careful about putting ICANN or whoever is ultimately responsible in that position. · Phishing attacks need to be mitigated quickly - and this is a factor in addressing them. Subsection J · Accreditation and authentication of users identifies who the requester of the data is. It does not and cannot mean that the request does not have to be checked. · Action: SSAC to provide an example of how accreditation can be done by whom. · There would not be a separate accreditation for an anti-phishing working group. There would not be special recognition given to groups; there would just be generic accreditation. Subsection M - P Confirm next steps · ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the SSAC use case ideally by Friday, August 2, but at the latest by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 6. Use case – first reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves (60 minutes) 1. Introduction of use case (ALAC) · Because the group is not currently distinguishing b/w legal and natural persons, the use case may need to be altered when it does discuss legal vs. natural. · Consumer protection is within ICANN’s mission. · This use case touches on online buyers or internet users who are trying to purchase services or goods in order to verify the legitimacy of the website they are dealing with. This use case is referencing commercial websites. · The data elements that would be required for this use case is the contact information. The lawful basis for this would be 6(1)(f). · There is a wider public benefit here - for ordinary users to confirm the legitimacy of a website is a benefit to the users to report a website before they are victims. · There is likely no need for accreditation here. Input from EPDP Team – questions, concerns, proposed modifications · The key issue here that suggests that this is a use case that should be discarded is the distinction b/w ex-post and ex ante checking. Being able to not find information on a website is not, in and of itself, a crime unless it is in a jx that requires the posting of information. As a consumer, you have the right to refuse to do business if you do not feel comfortable with the validity of the website. If a consumer has been defrauded (ex-post), that is another use case. · Clarifying question: the user makes a typical 6(1)(f) request, and the data controller will look at it - if the controller has a legal vs. natural distinction ability, they would use this. What if they don’t? · There is a fundamental flaw in this use case in that it conflates the registrant of the domain name and the operator of the website, particularly in marketplaces which connect buyers and sellers (like eBay, for example). Holding up WHOIS data vs. use/adoption of SSL certificates is worrisome. If a consumer is defrauded, that would be a different use case, which is probably LEA. · It is time to move on - the conflation of domain name provider and operator of the business is a problem. Consumers should not be encouraged to get data via WHOIS. If you cannot tell who you are dealing with via the website, the consumer should choose not to deal with them. Web presence is not within ICANN’s remit. · The case will also be published on Google Docs for those who would like to include comments. · The FTC issued a statement re: how the WHOIS database is critical to consumers. · The intent of this use case is not to be speculative, but rather, an egregious case. Perhaps the earlier sections need to be reworded. Local law enforcement will not take a case against an organization that is likely outside of its jurisdiction. Confirm next steps ACTION: EPDP Team to provide additional input, via the comment functionality, to the google sheet for the ALAC use case ideally by Sunday, 4 August. Please note EPDP Team Members were sent an invitation to the Google Doc. 7. Any other business (5 minutes) 1. Priority 2 small team meetings update · Accuracy and WHOIS ARS (see https://docs.google.com/document/d/1pS9Pibanj-Hp6LztZpeERtxdoLsnp4y_-do0vU5…) · Input received on other priority 2 items from RrSG (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-June/002174.html) · Leadership to recommend next steps via mailing list 2. Council request for input on org letter requesting clarification on Data Accuracy and Phase-2 (see https://gnso.icann.org/sites/default/files/file/field-file-attach/marby-to-…) EPDP Team to provide input on the mailing list. Confirm deadline for input. 8. Wrap and confirm next EPDP Team meeting on Thursday 8 August 2019 at 14.00 UTC (5 minutes) Confirm action items Confirm questions for ICANN Org, if any

8 14

Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case
by Alan Greenberg Aug. 29, 2019

Aug. 29, 2019

At 28/08/2019 08:39 PM, farzaneh badii wrote: 1. Are there alternatives to WHOIS to achieve the online buyer purpose: the answer as has been argued is Yes. Therefore since WHOIS is not the only means to be used for online buyers purpose, it does not pass the balancing test. There may be alternative sources in some cases. In others not. As our colleagues from the contracted parties have repeatedly told us, you cannot decide on the "balance" based on generalities. The specifics of the case must be used. 2. Some insist that this would have been a really easy use case had we accepted to distinguish between legal and natural. Not only this is wrong because of the points Volker enumerated, but it is also based on the wrong premise that all the online sellers are "businesses" and "legal entities", hence creating a distinction is easy. The Internet became the hotbed of Consumer to Consumer (C2C) transactions due to its global nature and reduction of transaction costs for consumers to sell their goods on online intermediaries but also on their own websites. People can set up a website and sell the contents of their garage, or sell a pamphlet about how to grow the best tomato in the world! They cannot be automatically categorized as "legal entities" because they occasionally sell their postcards on their personal website. We have gone over this too many times. Legal vs Natural is still on our official to-do list. If and when we actually get to it, we can discuss the merits. At the moment, we are working on the premise that the RDS will not necessarily make such a distinction (Phase 1 allowed but did not require contracted parties to make a distinction). SInce we are assuming that in the general case, the RDS data will NOT distinguish, this use case allows a access request recipient to using whatever means they choose (or choose not to) to make a "manual" distinction. It does not REQUIRE them to, but gives them the opportunity to. We really don't have to insist on all the use cases submitted by various people to be accepted by this group. It makes the exercise much more difficult and we get sidetracked. As Amr pointed out, regardless of whether this WG "allow" this use case, a user can, without asking permission, submit an access request. Us pretending it is not going to happen does not alter that. Alan Farzaneh On Thu, Aug 29, 2019 at 1:51 AM Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: Amr, as few points. 1. This use case is NOT about content. It is true that the user request *MAY* have been triggered by content of a web site. But it could equally well have been triggered by an e-mail received. Or just the semantics of the domain name. A registrar *might* choose to use any web content as a basis for responding positively or negatively to such a request for access, but it could also use its own database of its customer information to determine if the registrant is a legal person. What the registrar does in resolving an access request will not be dictated by any ICANN policy and is purely up to its business practices. 2. I really do not understand the concept if us "rejecting" a use case. We were asked to identify potential use cases and we did. You captured the validity of the case at the end of your message: "there is still nothing preventing an Internet user from requesting information about a website they might do business with from a registrar". Any EPDP rejection notwithstanding, a user may still request access to information about a registrant that she believes may be a legal person. And a registrar/registry may ultimately agree to grant that access - or not. Therefore it *IS* a user case, albeit perhaps one you don't like. Nothing in this use case presupposes that access will be granted, nor does it presume that such a use will be handled in anything but a manual mode with the registrar performing the "balancing" as dictated by GDPR. Alan At 28/08/2019 03:30 PM, Amr Elsadr wrote: Hi Brian, I'm not sure that it makes a difference - wether disclosure can or cannot be presupposed as an outcome. If we, as a Team developing gTLD policy recommendations, tackle an issue concerning web content, reach a conclusion (any conclusion) on it, send a recommendation to the GNSO Council, which is adopted and then sent to the ICANN Board, which adopts it yet again, then what is the outcome? To me, the answer to that question would be that the EPDP Team, the GNSO Council and the ICANN Board have all contributed to creating contractual obligations on Contracted Parties that ICANN should have no business creating. To me, this is also a means of pulling topics out-of-scope of ICANN's mission in to it, because although this scope is defined by the Bylaws, there are also Bylaws granting the GNSO responsibility for developing gTLD policy. Would create a bit of a messy constitutional sort of situation, I think. Also, at some point in the future, the Consensus Policy we are in the process of developing recommendations for will be reviewed, and amendments may be sought. Reviewing Consensus Policies could potentially be initiated by either the GNSO or GDD (if you're following the current Council conversation on reviews of implemented Consensus Policies). So even if we are not presupposing any outcome of disclosure in this use case now, we open the door to further policy development on this topic at some point in a future iteration. On a topic that should have been flagged as out-of-scope of ICANN's mission to begin with!! Ideally, we would not submit any recommendations concerning web content at all. If we did, it'd be nice to know that there are checks and balances in place that initiate some kind of course correction. For instance, the GNSO Council or the ICANN Board would respond saying, wait a minute, why are you sending us a policy recommendation on a topic outside of ICANN's scope?! Speaking for myself, unfortunately, I very much doubt that would happen. It's probably also noteworthy that even if we, as an EPDP Team, reject this use case, and do not address the topic in our recommendations, there is still nothing preventing an Internet user from requesting information about a website they might do business with from a registrar, as you suggest. Our use of these use cases should focus on helping respondents to disclosure requests understand how best to deal with whatever disclosure requests they receive. We can't cover every single potential use case anyway, so the ones we do work out should at least provide some guidance on how to deal with unforeseen circumstances. With that in mind, I believe there is value in addressing this use case, and rejecting it, as opposed to not looking at it at all. This is my personal perspective, and apologies if it was slightly lengthier than it needed to be, but you asked. ;-) Thanks. Amr Ã¢€ Ã¢€ Ã¢€ Ã¢€ Ã¢ââ‚¬ Ã¢â‚¬ Ã¢€ Ã¢€ Original Message Ã¢€ ¢â‚¬ Ã¢€ Ã¢€ Ã¢€ Ã¢€ Ã¢ââ‚¬ Ã¢â‚¬ Ã¢€ On Wednesday, August 28, 2019 8:25 PM, King, Brian < Brian.King(a)markmonitor.com<mailto:Brian.King@markmonitor.com>> wrote: Hey Amr and all, I canÃ¢€™t speak authoritatively for ALACÃ¢â‚¢â‚¬™s intent, but I read this use case as allowing internet users tto request (not have an entitlement to receive) information about a website they might do business with, a link they might click, etc. I think weÃ¢€™re merely talking about allowing an interternet user to ask the question, without presupposing any access outcome. Does that change your perspective? IÃ¢€™m sympathetic to concerns raised about the bounds ds of ICANNÃ¢€™s remit, and I might find those concerns mo more persuasive if we were talking about guaranteed access in this case. Brian J. King Director of Internet Policy and Industry Affairs T +1 443 761 3726 markmonitor.com<http://www.markmonitor.com> MarkMonitor Protecting companies and consumers in a digital world From: Gnso-epdp-team < gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Amr Elsadr Sent: Tuesday, August 27, 2019 7:28 AM To: Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg<mailto:Hadia@tra.gov.eg>> Cc: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Hi, The issue many of us have with this use case isnÃ¢€™t tt that Internet users should not be entitled to know who they elect to do business with over the web, so I donÃ¢€™t believe it is necnecessary to keep pushing that point. The issue is that in situations where entities conducting commerce over the Web do not have their contact information readily published on their websites, ICANN/gTLD policy is an inappropriate substitute to resolve this, due to ICANNÃ¢€™s narrow missission. Speaking for myself, even if it were legal for ICANN to adopt policies that are beyond the scope of its mission (which I donÃ¢€™t ¢t think is the case here), it is undesirable for it to do so. Not having a clearly drawn line in the sand on what ICANN can regulate online via contractual compliance with Registries and Registrars, including selling and purchasing goods and services, is a prospect that I find to be very unappealing. It creates a great deal of uncertainty for both Contracted Parties providing domain name registration services, as well as registrants who utilize these services. My interpretation of consumer protection from an ICANN perspective is that registrants are THE consumers of services in the ICANN context. In that context, proposing policy recommendations beyond the scope of ICANNÃ¢â‚¬™s mission is bad, not good, for consumer protection. …, and like I said…, I do donÃ¢âÃ¢â‚¬™t believe it to be complaint with data protection regulationn, such as the GDPR, anyway. Thanks. Amr On Aug 26, 2019, at 5:37 PM, Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: Hello All, The ALAC online buyers online case is a real life scenario for why there needs to be a distinction between natural and legal persons. I shall not get into this debate. However, I note that consumers identity and even location is now available to buyers through many online applications, GDPR protects personal information of natural persons and not legal persons. It is only fair to Internet end users to allow them to have the contact information of the online businesses. This is particularly important in case Internet end users are dealing with small businesses online. You can find online businesses contact details now through some existing applications. What and who are we trying to protect by not allowing this use case. Commercial websites should be encouraged to indicate who they are and publish their information. The architecture of the web inherently does not require real identity, but having a complete anonymous system is always an invitation to problems, making people feel less accountable and diminishing the trust in the network. A survey conducted by Bright Local showed that 60% of customers prefer to call small businesses on the phone. The survey also showed that consumers now look beyond websites, RDS is only one tool of many however, prohibiting it to exist works against the norm. I also note that getting clarity in relation to the contracted parties liability in this regard is very important and if implemented information should only be provided if the case is absolutely clear. I attach the updated user case, which is also available through the google doc Best Hadia el-Miniawi From: Gnso-epdp-team [ mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Monday, August 19, 2019 5:27 PM To: Tara Whalen; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] Notes and action items from EPDP Team Phase 2 Meeting #11 - 1 August 2019 - ALAC Online buyers Use Case Tara: Responses inline below: The ICANN Board resolved in May to have the ePDP Ã¢€œdetermine and resolve the Legal vs. Natural issue in P Phase 2." https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> Because the issue is not decided. Not quite correct. The Board noted that EPDPÃ¢€¬™s own Recommendation said that we would resolve the issue in Phasee 2. The board did not tell us to do so. The resolution also notes the Ã¢€œPotential liability of a registered name holder's incorrerect self-identification of a natural or legal person, which ultimately results in public display of personal data.Ã¢€ This concern was one of several that motivvated our reluctance to attempt differentiation. The EWG recommended a differentiation solution -- that registrants be required to identify as a Registrant Type, with Legal Person and Natural Person among the options. It also required that a mandatory Business PBC be published for Ã¢€œRegistrants that self-identify as Legal Persons engaged in commercial activity" (pages 42-44 of final report). This option _was_ discussed and discarded in Phase 1. It was noted that to the vast majority of ordinary people the distinction between legal and natural has no meaning, and that there would be liability consequences if there were incorrect identification (see above). And besides, the recommendation of the EWG was made prior to GDPR and has no bearing on EPDP. ICANNÃ¢€™s Procedure for Handling WHOIS Confliflicts with Privacy Law was reviewed by the GNSO and revised in mid-2017. A goal of the Procedure was Ã¢€œto resolve the problem i in a manner that preserves the ability of the registrar/registry to comply with its [current] contractual WHOIS obligations to the greatest extent possibleÃ¢€ . So -- to publish as much data as possible as allowed bby law. Now you are way off base. Contractual Whois obligations in 2017 were not compliant with GDPR. The Conflicts with Privacy Law procedure is completely irrelevant to our proceedings. Under that Procedure, about the only precedent was the .TEL case, which addressed concerns raised by UK privacy law. In that case, the WHOIS service was made to differentiate between natural and legal persons. Some public WHOIS data was limited for natural persons who had elected to withhold their personal information from disclosure by the WHOIS service, records for Legal Persons had to return full and complete WHOIS data (including applicable personal data), and Legal Persons were not permitted to opt out of disclosing such information. The GDPR is definitely a different law and may yield a different policy. But the .TEL case did show that itÃ¢€™s possible to tell the difference between a natural pe personÃ¢€™s data and a legal personÃ¢€â„â‚¬â„¢s data, and to control where that data appears. Same comment as above. <Consumer_Protection_Use_Case_ALAC - Online buyers_Update_2.docx> _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy) and the website Terms of Service ( https://www.icann.org/privacy/tos) You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

2 1

Approved questions from Legal Committee - Batch 1
by Caitlin Tubergen Aug. 29, 2019

Aug. 29, 2019

Dear EPDP Team, On behalf of the Phase 2 EPDP Legal Committee, please find the first set of legal questions the Legal Committee has agreed to send to outside counsel. As a reminder, the below text has been reviewed, edited, and agreed to by a representative group of EPDP Team Members, and, as such, EPDP Leadership would ask the EPDP Team to apply the “cannot live with” standard it its review of the below questions. Thank you. Best regards, Marika, Berry, and Caitlin Questions to Outside Counsel: Batch 1 Consider a System for Standardized Access/Disclosure where: contracted parties “CPs” are contractually required by ICANN to disclose registration data including personal data, data must be disclosed over RDAP to requestors either directly or through an intermediary request accreditation/authorization body, the accreditation is carried out by third party commissioned by ICANN without CP involvement, disclosure takes place in an automated fashion without any manual intervention, data subjects are being duly informed according to ICANN’s contractual requirements of the purposes for which, and types of entities by which, personal data may be processed. CP’s contract with ICANN also requires CP to notify data subject about this potential disclosure and third-party processing before the data subject enters into the registration agreement with the CP, and again annually via the ICANN-required registration data accuracy reminder. CP has done so. Further, assume the following safeguards are in place ICANN or its designee has validated/verified the requestor’s identity, and required in each instance that the requestor: · represents that it has a lawful basis for requesting and processing the data,  · provides its lawful basis, · represents that it is requesting only the data necessary for its purpose,  · agrees to process the data in accordance with GDPR, and  · agrees to EU standard contractual clauses for the data transfer.    ICANN or its designee logs requests for non-public registration data, regularly audits these logs, takes compliance action against suspected abuse, and makes these logs available upon request by the data subject. 1. What risk or liability, if any, would the CP face for the processing activity of disclosure in this context, including the risk of a third party abusing or circumventing the safeguards? 2. Would you deem the criteria and safeguards outlined above sufficient to make disclosure of registration data compliant? If any risk exists, what improved or additional safeguards would eliminate1 this risk? 3. In this scenario, would the CP be a controller or a processor2, and to what extent, if at all, is the CP’s liability impacted by this controller/processor distinction? 4. Only answer if a risk still exists for the CP: If a risk still exists for the CP, what additional safeguards might be required to eliminate CP liability depending on the nature of the disclosure request, i.e. depending on whether data is requested e.g. by private actors pursuing civil claims or law enforcement authorities depending on their jurisdiction or the nature of the crime (misdemeanor or felony) or the associated sanctions (fine, imprisonment or capital punishment)? Footnote 1: “Here it is important to highlight the special role that safeguards may play in reducing the undue impact on the data subjects, and thereby changing the balance of rights and interests to the extent that the data controller’s legitimate interests will not be overridden.“ (https://iapp.org/media/pdf/resource_center/wp217_legitimate-interests_04-20… [iapp.org] Footnote 2: https://ec.europa.eu/info/law/law-topic/data-protection/reform/rules-busine… [ec.europa.eu] To what extent, if any, are contracted parties liable when a third party that accesses non-public WHOIS data under an accreditation scheme where by the accessor is accredited for the stated purpose, commits to certain reasonable safeguards similar to a code of conduct regarding use of the data, but misrepresents their intended purposes for processing such data, and subsequently processes it in a manner inconsistent with the stated purpose. Under such circumstances, if there is possibility of liability to contracted parties, are there steps that can be taken to mitigate or reduce the risk of liability to the contracted parties? (Formerly Q9) Assuming that there is a policy that allows accredited parties to access non-public WHOIS data through an SSAD (and requires the accredited party to commit to certain reasonable safeguards similar to a code of conduct), is it legally permissible under Article 6(1)(f) to: · define specific categories of requests from accredited parties (e.g. rapid response to a malware attack or contacting a non-responsive IP infringer), for which there can be automated submissions for non-public WHOIS data, without having to manually verify the qualifications of the accredited parties for each individual disclosure request, and/or · enable automated disclosures of such data, without requiring a manual review by the controller or processor of each individual disclosure request. In addition, if it is not possible to automate any of these steps, please provide any guidance for how to perform the balancing test under Article 6(1)(f). For reference, please refer to the following potential safeguards: · Disclosure is required under CP’s contract with ICANN (resulting from Phase 2 EPDP policy). · CP’s contract with ICANN requires CP to notify the data subject of the purposes for which, and types of entities by which, personal data may be processed. CP is required to notify data subject of this with the opportunity to opt out before the data subject enters into the registration agreement with the CP, and again annually via the ICANN-required registration data accuracy reminder. CP has done so. · ICANN or its designee has validated the requestor’s identity, and required that the requestor: o represents that it has a lawful basis for requesting and processing the data, o provides its lawful basis, o represents that it is requesting only the data necessary for its purpose, o agrees to process the data in accordance with GDPR, and o agrees to standard contractual clauses for the data transfer. · ICANN or its designee logs requests for non-public registration data, regularly audits these logs, takes compliance action against suspected abuse, and makes these logs available upon request by the data subject. Under the GDPR, a data controller can disclose personal data to law enforcement of competent authority under Art. 6 1 c GDPR provided the law enforcement authority has the legal authority to create a legal obligation under applicable law. Certain commentators have interpreted “legal obligation” to apply only to legal obligations grounded in EU or Member State law. As to the data controller: a. Consequently, does it follow that the data controller may not rely on Art. 6 1 c GDPR to disclose personal data to law enforcement authorities outside the data controller’s jurisdiction? Alternatively, are there any circumstances in which data controllers could rely on Art. 6 1 c GDPR to disclose personal data to law enforcement authorities outside the data controller’s jurisdiction? b. May the data controller rely on any other legal bases, besides Art. 6 I f GDPR, to disclose personal data to law enforcement authorities outside the data controller’s jurisdiction? As to the law enforcement authority: Given that Art. 6 1 GDPR states that European public authorities cannot use Art. 6 I f GDPR as a legal basis for processing carried out in the performance of their tasks, these public authorities need to have a legal basis so that disclosure can take place based on another legal basis (e.g. Art. 6 I c GDPR). c. In the light of this, is it possible for non-EU-based law enforcement authorities to rely on Art. 6 I f GDPR as a legal basis for their processing? In this context, can the data controller rely on Art. 6 1 f GDPR to disclose the personal data? If non-EU-based law enforcement authorities cannot rely on Art. 6 1 f GDPR as a legal basis for their processing, on what lawful basis can non-EU-based law enforcement rely?

2 1

**REMINDER** Meeting Invitation: Observers GNSO Temp Spec gTLD RD EPDP - Phase 2 call | Thursday, 29 August 2019 at 14:00 UTC
by Julie Bisland Aug. 28, 2019

Aug. 28, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 29 August 2019 at 14:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) 07:00 PDT, 10:00 EDT, 16:00 Paris CEST, 19:00 Karachi PKT, 23:00 Tokyo JST, (Friday) 00:00 Melbourne AEST For other times: https://tinyurl.com/y4eevh45 [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y4eevh45&d…> Agenda Wiki: https://community.icann.org/x/pKajBg The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream02 <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream02.m3u <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> If needed, an option to join via telephone has been added for this meeting. Passcode: EPDP Dial in numbers: Country Toll Numbers Freephone/ Toll Free Number ARGENTINA 0800-777-0519 AUSTRALIA ADELAIDE: 61-8-8121-4842 1-800-657-260 AUSTRALIA BRISBANE: 61-7-3102-0944 1-800-657-260 AUSTRALIA CANBERRA: 61-2-6100-1944 1-800-657-260 AUSTRALIA MELBOURNE: 61-3-9010-7713 1-800-657-260 AUSTRALIA PERTH: 61-8-9467-5223 1-800-657-260 AUSTRALIA SYDNEY: 61-2-8205-8129 1-800-657-260 AUSTRIA 43-1-92-81-113 0800-005-259 BELGIUM 32-2-400-9861 0800-3-8795 BRAZIL RIO DE JANEIRO: 55-21-40421490 0800-7610651 BRAZIL SAO PAULO: 55-11-3958-0779 0800-7610651 CHILE 1230-020-2863 CHINA CHINA A: 86-400-810-4789 10800-712-1670 CHINA CHINA B: 86-400-810-4789 10800-120-1670 COLOMBIA 01800-9-156474 CROATIA 080-08-06-309 CZECH REPUBLIC 420-2-25-98-56-64 800-700-177 DENMARK 45-7014-0284 8088-8324 ESTONIA 800-011-1093 FINLAND 358-9-5424-7162 0-800-9-14610 FRANCE LYON: 33-4-26-69-12-85 080-511-1496 FRANCE MARSEILLE: 33-4-86-06-00-85 080-511-1496 FRANCE PARIS: 33-1-70-70-60-72 080-511-1496 GERMANY 49-69-2222-20362 0800-664-4247 GREECE 30-80-1-100-0687 00800-12-7312 HONG KONG 852-3001-3863 800-962-856 HUNGARY 36-1-700-8856 06-800-12755 INDIA INDIA A: 000-800-852-1268 INDIA INDIA B: 000-800-001-6305 INDIA INDIA C: 1800-300-00491 INDONESIA 001-803-011-3982 IRELAND 353-1-246-7646 1800-992-368 ISRAEL 1-80-9216162 ITALY MILAN: 39-02-3600-6007 800-986-383 ITALY ROME: 39-06-8751-6018 800-986-383 ITALY TORINO: 39-011-510-0118 800-986-383 JAPAN OSAKA: 81-6-7878-2631 0066-33-132439 JAPAN TOKYO: 81-3-6868-2631 0066-33-132439 LATVIA 8000-3185 LUXEMBOURG 352-27-000-1364 8002-9246 MALAYSIA 1-800-81-3065 MEXICO GUADALAJARA (JAL): 52-33-3208-7310 001-866-376-9696 MEXICO MEXICO CITY: 52-55-5062-9110 001-866-376-9696 MEXICO MONTERREY: 52-81-2482-0610 001-866-376-9696 NETHERLANDS 31-20-718-8588 0800-023-4378 NEW ZEALAND 64-9-970-4771 0800-447-722 NORWAY 47-21-590-062 800-15157 PANAMA 011-001-800-5072065 PERU 0800-53713 PHILIPPINES 63-2-858-3716 1800-111-42453 POLAND 00-800-1212572 PORTUGAL 8008-14052 ROMANIA 40-31-630-01-79 RUSSIA 8-10-8002-0144011 SAUDI ARABIA 800-8-110087 SINGAPORE 65-6883-9230 800-120-4663 SLOVAK REPUBLIC 421-2-322-422-25 0800-002066 SOUTH AFRICA 080-09-80414 SOUTH KOREA 82-2-6744-1083 00798-14800-7352 SPAIN 34-91-414-25-33 800-300-053 SWEDEN 46-8-566-19-348 0200-884-622 SWITZERLAND 41-44-580-6398 0800-120-032 TAIWAN 886-2-2795-7379 00801-137-797 THAILAND 001-800-1206-66056 TURKEY 00-800-151-0516 UNITED ARAB EMIRATES 8000-35702370 UNITED KINGDOM BIRMINGHAM: 44-121-210-9025 0808-238-6029 UNITED KINGDOM GLASGOW: 44-141-202-3225 0808-238-6029 UNITED KINGDOM LEEDS: 44-113-301-2125 0808-238-6029 UNITED KINGDOM LONDON: 44-20-7108-6370 0808-238-6029 UNITED KINGDOM MANCHESTER: 44-161-601-1425 0808-238-6029 URUGUAY 000-413-598-3421 USA 1-517-345-9004 866-692-5726 VENEZUELA 0800-1-00-3702 VIETNAM 120-11751 Thank you. Kind Regards, Andrea

1 0

**Reminder** Meeting Invitation: Observers GNSO Temp Spec gTLD RD EPDP - Phase 2 Extraordinary call | Thursday, 29 August 2019 at 20:00 UTC
by Julie Bisland Aug. 28, 2019

Aug. 28, 2019

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, audio cast will be made available for the EPDP plenary meetings. Staff will be monitoring audio cast attendance numbers so that the EPDP leadership can assess its usage. As a reminder, the zoom recording, mp3 recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 29 August 2019 at 20:00 UTC for 120 minutes. (calls will be scheduled for 120 minutes but aim to keep to 90 minutes) 13:00 PDT, 16:00 EDT, 22:00 Paris CEST, (Friday) 01:00 Karachi PKT, (Friday) 05:00 Tokyo JST, (Friday) 06:00 Melbourne AEST For other times: https://tinyurl.com/y2z6kocj [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y2z6kocj&d…> Agenda Wiki: https://community.icann.org/x/EY3kBg The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> Meeting Audio Cast (for observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream02 <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream02.m3u <https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> If needed, an option to join via telephone has been added for this meeting. Passcode: EPDP Dial in numbers: Country Toll Numbers Freephone/ Toll Free Number ARGENTINA 0800-777-0519 AUSTRALIA ADELAIDE: 61-8-8121-4842 1-800-657-260 AUSTRALIA BRISBANE: 61-7-3102-0944 1-800-657-260 AUSTRALIA CANBERRA: 61-2-6100-1944 1-800-657-260 AUSTRALIA MELBOURNE: 61-3-9010-7713 1-800-657-260 AUSTRALIA PERTH: 61-8-9467-5223 1-800-657-260 AUSTRALIA SYDNEY: 61-2-8205-8129 1-800-657-260 AUSTRIA 43-1-92-81-113 0800-005-259 BELGIUM 32-2-400-9861 0800-3-8795 BRAZIL RIO DE JANEIRO: 55-21-40421490 0800-7610651 BRAZIL SAO PAULO: 55-11-3958-0779 0800-7610651 CHILE 1230-020-2863 CHINA CHINA A: 86-400-810-4789 10800-712-1670 CHINA CHINA B: 86-400-810-4789 10800-120-1670 COLOMBIA 01800-9-156474 CROATIA 080-08-06-309 CZECH REPUBLIC 420-2-25-98-56-64 800-700-177 DENMARK 45-7014-0284 8088-8324 ESTONIA 800-011-1093 FINLAND 358-9-5424-7162 0-800-9-14610 FRANCE LYON: 33-4-26-69-12-85 080-511-1496 FRANCE MARSEILLE: 33-4-86-06-00-85 080-511-1496 FRANCE PARIS: 33-1-70-70-60-72 080-511-1496 GERMANY 49-69-2222-20362 0800-664-4247 GREECE 30-80-1-100-0687 00800-12-7312 HONG KONG 852-3001-3863 800-962-856 HUNGARY 36-1-700-8856 06-800-12755 INDIA INDIA A: 000-800-852-1268 INDIA INDIA B: 000-800-001-6305 INDIA INDIA C: 1800-300-00491 INDONESIA 001-803-011-3982 IRELAND 353-1-246-7646 1800-992-368 ISRAEL 1-80-9216162 ITALY MILAN: 39-02-3600-6007 800-986-383 ITALY ROME: 39-06-8751-6018 800-986-383 ITALY TORINO: 39-011-510-0118 800-986-383 JAPAN OSAKA: 81-6-7878-2631 0066-33-132439 JAPAN TOKYO: 81-3-6868-2631 0066-33-132439 LATVIA 8000-3185 LUXEMBOURG 352-27-000-1364 8002-9246 MALAYSIA 1-800-81-3065 MEXICO GUADALAJARA (JAL): 52-33-3208-7310 001-866-376-9696 MEXICO MEXICO CITY: 52-55-5062-9110 001-866-376-9696 MEXICO MONTERREY: 52-81-2482-0610 001-866-376-9696 NETHERLANDS 31-20-718-8588 0800-023-4378 NEW ZEALAND 64-9-970-4771 0800-447-722 NORWAY 47-21-590-062 800-15157 PANAMA 011-001-800-5072065 PERU 0800-53713 PHILIPPINES 63-2-858-3716 1800-111-42453 POLAND 00-800-1212572 PORTUGAL 8008-14052 ROMANIA 40-31-630-01-79 RUSSIA 8-10-8002-0144011 SAUDI ARABIA 800-8-110087 SINGAPORE 65-6883-9230 800-120-4663 SLOVAK REPUBLIC 421-2-322-422-25 0800-002066 SOUTH AFRICA 080-09-80414 SOUTH KOREA 82-2-6744-1083 00798-14800-7352 SPAIN 34-91-414-25-33 800-300-053 SWEDEN 46-8-566-19-348 0200-884-622 SWITZERLAND 41-44-580-6398 0800-120-032 TAIWAN 886-2-2795-7379 00801-137-797 THAILAND 001-800-1206-66056 TURKEY 00-800-151-0516 UNITED ARAB EMIRATES 8000-35702370 UNITED KINGDOM BIRMINGHAM: 44-121-210-9025 0808-238-6029 UNITED KINGDOM GLASGOW: 44-141-202-3225 0808-238-6029 UNITED KINGDOM LEEDS: 44-113-301-2125 0808-238-6029 UNITED KINGDOM LONDON: 44-20-7108-6370 0808-238-6029 UNITED KINGDOM MANCHESTER: 44-161-601-1425 0808-238-6029 URUGUAY 000-413-598-3421 USA 1-517-345-9004 866-692-5726 VENEZUELA 0800-1-00-3702 VIETNAM 120-11751 Thank you. Kind Regards, Andrea

1 0

Proposed agenda - EPDP Team Meeting #16 on Thursday 29 August at 14.00 UTC
by Marika Konings Aug. 26, 2019

Aug. 26, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 29 August at 14.00 UTC. As a reminder: Groups are welcome to provide additional comments in response to early input in the Early Input Google Doc<https://docs.google.com/document/d/1CXKIZmjBRUO3qRIiNl78S0692EIHDCum/edit> over the next two weeks (by 29 August). Support Staff will consider input received when compiling the Zero Draft document. 29 August 2019 Early Input Google Doc<https://docs.google.com/document/d/1CXKIZmjBRUO3qRIiNl78S0692EIHDCum/edit> Best regards, Caitlin, Berry and Marika =================== EPDP Phase 2 - Meeting #16 Proposed Agenda Thursday, 29 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Update from Legal Committee b) Reminder – contribute to google doc with questions for ICANN CEO / Strawberry Team in preparation for LA F2F meeting (see https://docs.google.com/document/d/1Q_0smZv58- rQ4RF9buAMBmt4PGVSk6gAYyLiPIOlyQU/edit<https://docs.google.com/document/d/1Q_0smZv58-%09rQ4RF9buAMBmt4PGVSk6gAYyLi…>) 4. Use case – second/final reading: When a network is undergoing an attack involving a domain name, and the operator(s) of that network need to contact the domain owner to remediate the security issue (DDOS, Botnet, etc.)<https://docs.google.com/document/d/1eLcD6TpQCW029qgi05BQHGwDA9PW29jM3e9ZhPE…> (SSAC1) a) Overview of updates made in response to input received (SSAC) b) Feedback from EPDP Team c) Confirm next steps 5. Use case – final reading: Online buyers identifying and validating the source or services/ Internet users validating the legitimacy of an email or a website to protect themselves<file:///Users/marika.konings/Documents/Documents/EPDP%20Team%20Phase%202/Online%20buyers%20identifying%20and%20validating%20the%20source%20or%20services/%20Internet%20users%20validating%20the%20legitimacy%20of%20an%20email%20or%20a%20website%20to%20protect%20themselves> (ALAC1) a) Overview of updates made in response to input received (ALAC) b) Feedback from EPDP Team c) Confirm next steps 6. Use case – first reading: Investigation of criminal activity against a victim in the jurisdiction of the investigating EU LEA requesting data from a local data controller<https://community.icann.org/download/attachments/111386876/Use%20Case%20-%2…>. (LEA 2) a) Intro to use case and overview of how/where this use case is different from LEA 1 (GAC) b) Feedback from EPDP Team c) Confirm next steps 7. Any other business (5 minutes) 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 29 August 2019 at 20.00 UTC (extraordinary meeting – intro to and initial feedback on zero draft) b) Thursday 5 September 2019 at 14.00 UTC c) Confirm action items d) Confirm questions for ICANN Org, if any 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__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

Notes and action items from EPDP Phase 2 Meeting #15 - 22 August 2019
by Caitlin Tubergen Aug. 23, 2019

Aug. 23, 2019

Dear EPDP Team, Please find the notes and action items from today’s EPDP Team meeting below. As a reminder, the EPDP Phase 2 Legal Committee will meet on Tuesday, 27 August. The plenary team will meet twice on Thursday, 29 August: at 14:00 UTC and 20:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #15 Thursday, 22 August 2019 at 14.00 UTC Action Items ALAC EPDP Team members to review comments received on ALAC 1 (Online buyers identifying and validating the source of goods or services/ Internet users validating the legitimacy of an email or a website to protect themselves) and distribute updated version of the use case by Tuesday, 27 August in preparation for final reading on Thursday, 29 August. Brian King to consider comments made today regarding legal basis and amend the IP use case accordingly. Greg Aaron to update the SSAC use case on crime and abuse investigation by non-law enforcement parties to reflect today’s conversation. For the moment, the Team will park this use case and can revisit in the future when going through the zero draft. EPDP Team Members to add comments from today’s discussion of SSAC use case on operational security in the corresponding Google Doc by tomorrow, Friday, 23 August. SSAC EPDP members to review comments and distribute updated version of the use case by Tuesday, 27 August in preparation for final reading on Thursday, 29 August. Support Staff to create and distribute a Google Doc for EPDP Team members to contribute questions for the face-to-face session with Göran and the Strawberry Team. Notes These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. EPDP Phase 2 - Meeting #15 Proposed Agenda Thursday, 22 August 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) · Attendance will be taken from Zoom room 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) a) Confirm timeline for publication of zero draft and planning for F2F meeting: · Circulation of zero draft to the EPDP Team: Tuesday 27 August · Extraordinary EPDP Team meeting to present zero draft and get initial reactions from EPDP Team: Thursday 29 August at 20.00 UTC (note, this meeting will be in addition to the regular EPDP Team meeting at 14.00 UTC) · Conduct survey to assess which aspects of the zero draft are of most concern and as such should be prioritized for the F2F meeting: Monday 2 – Wednesday 4 September. · Confirm priority items for F2F meeting and confirm ‘homework’ for F2F meeting: Thursday 5 September (regular EPDP Team meeting) b) Update from Legal Committee · Legal Committee met on Tuesday to discuss the SSAD legal questions · Legal Committee made progress on questions to be sent to outside counsel - the first batch is awaiting an anchor question · The questions will be sent to the plenary team as soon as available · The questions appear to be very specific and have a lot of qualifiers - caution against too much specificity - the questions should be more general and overarching. Answers to overly specific questions will likely be unhelpful. · Question 3 seems to be vague -- would it be possible to shed more light on this question. · There was a letter from the European Commission that came in after Bird & Bird’s memo. · What within the EC letter needs to be highlighted in the memo? The question is open and vague. The LC may want to consider highlighting specific points that may warrant an updated an answer from the memo. · Questions refer to accreditation and accredited parties - there are significant differences within the team with respect to what those terms mean - is the Legal Committee aware of this? 4. Use case – second/final reading: Providers requesting access required to facilitate due process in the UDRP and URS [docs.google.com] (IP 5) (45 minutes) a) Review updates made to use case to reflect input received (IPC) · Authors of use cases - please remember to alert the EPDP Team when updates have been made to a Google Doc. A summary of the updates made in response to comments will help facilitate discussions. · 6(1)(a) was removed as a lawful basis · 6(1)(b) was kept · 6(1)(c) was kept, but this would be a rare instance · NCSG noted 6(1)(f) is the only appropriate basis, but IPC disagrees and noted the disagreement b) Feedback from EPDP Team · Subsection A · Subsection B · Subsection C · Subsection D and E · This is a 6(1)(f). The contractual obligation does not apply to third parties - registrars do not have a contract with the individual who is requesting the data. · What is the rationale of including 6(1)(c) here? · General comment on all use cases: when EPDP Team members have commented, it appears that use case drafters disagree with the points and do not propose edits or compromises. This would amount to wasted time. · The reason 6(1)(c) was included is because UDRP and URS cases can be appealed - if this appeal happens, processing the data may be necessary to participate in the court proceeding. · 6(1)(f) should be included here. It is important for the Team to do this review. Regarding 6(1)(b), and the Bird & Bird memo - it doesn’t appear 6(1)(b) would apply with the current legal advice. · It’s unacceptable for 6(1)(f) to not be included at all. · Subsection F · Subsection G · Subsection H · Subsection I · Subsection J · “Or” should not be used in the accreditation criteria. If there is going to be processing of gTLD registration data, a combination of this criteria would be needed. · With respect to number 4, why would an entity seeking accreditation or disclosure have to affiliated with a DRP? What does it mean to be affiliated with? · What is the vision of accreditation - who is the accreditation for - URS or UDRP providers? Is the accreditation for entities seeking to file a UDRP or URS complaint? · There are two things happening in this box - one is the points made as “or” b/c you may not have an IP right, but you may work for someone who does, which is why not everything is “and”. Number 4 is the real problem that accreditation can help to fix. Maybe a UDRP provider could be accredited to receive data once a complaint has been filed. · It appears the use case is meant to apply to DRPs and TM holders. These are different user groups, and it should not be conflated into one use case. · This is a good point, and this could be divided into two use cases. The 6(1)(b) processing basis still applies to the Complainant since the data subject is a party to the contract. · Why is there is a 6(1)(b) basis for UDRP providers, but not complainants? · Registrants have signed a contract with registrars that commits them to submit to a DRP. Complainant is an unaffiliated party with a legitimate interest in the data, but there is no contract with complainants. · The Complainant may obtain data with 6(1)(b), but the contract b/w ICANN and DRPs would likely trigger 6(1)(f). Leave two legal bases in and it would be OK. · Subsection K · Subsection L · Subsection M · Subsection N · Subsection O c) Confirm next steps · Action item: Brian to consider comments made today regarding legal basis and amend the case accordingly. 5. Use case – final reading: Investigation of criminal activity where domain names are used. Typical specific example: phishing attack [docs.google.com] (SSAC 3) a) Review updates made to use case to reflect input received (SSAC) · SSAC made a number of edits based on comments received. · If there is a disagreement, how should that be reflected in the use case? · Disagreements need to be bridged through compromise, or, at a minimum, documented within the use case · In some instances, the SSAC use case invokes recitals that NCSG disagrees with. · Safeguard requirements are applicable to the entity that is protecting the data subject · Contracted parties have noted their discomfort with the combination of criminal activity and abusive activity in outlining this use case. There is significant overlap b/w this as written and the previous use case by the GAC. · How do the use cases fit into the final report? The Team understands that these are exercises that allow us to confront issues. The problem comes when including these use cases in the Final Report - if documents are included in the Final Report, there needs to be consensus. Authors cannot use these to be advocates and/or wishlists. The penholder cannot arbitrarily decide that they do not agree with something and arbitrarily decide what the legal basis is. Disagreements, at a minimum, need to documented in the Final Report. · This use case covers criminal use cases and abuse cases, and these need to be separated. · The use cases will not be attached to the Final Report. · It will be helpful to include as much detail in the policy was possible. · This use case does not conflate crime and abuse since these two aspects of the same thing. · Crime and abuse are not disambiguated b/c they cannot be. Phishing is a crime. What can make a difference is which party is dealing with it when. Law enforcement has different bases than private parties. · Regarding safeguards, this is a chicken or egg situation - safeguards may be the same no matter which type of party is making the request. The Team will have to talk about safeguards as a separate subject. Accreditation comes out of safeguards. · It is SSAC’s assumption that entities that get into an accreditation scheme have to meet some sort of bars. · These documents are the only place to capture thoughts and ideas. The parts of the Initial Report that are consensus-based are the recommendations, so it would make sense in places where there are disagreements. · Re: legal bases - the SSAC team looked at the bases from the comments. 6(1)(f) will represent most of the requests here. However, it would be inadvisable to rule other legal bases out. Additional commentary will be added to these legal bases. · The legal basis discussion is what is causing the group to stumble. Suggestion: perhaps the use case could be separated based on the legal basis. · Action item: SSAC to reflect today’s conversation in the use case. For the moment, the Team will park the use case and can revisit in the future when going through the zero draft. b) Feedback from EPDP Team c) Confirm next steps 6. Use case – first reading: When a network is undergoing an attack involving a domain name, and the operator(s) of that network need to contact the domain owner to remediate the security issue (DDOS, Botnet, etc.) (SSAC1) a) Introduction to use case (SSAC) · Domain names are often used either maliciously in DNS-based attacks, DDOS being the most common. · The use case is about a network operator, who is under attack, and needs to contact the domain owner to remediate the security issue. · Pseudonymized data is unlikely to help the issue · Most of the time, these situations need immediate contact - therefore, registrant contact, admin contact, tech contact, phone and email would be required here. · 6(1)(d) - sometimes critical infrastructure like hospitals or power grids could be brought down by network attack, which is why this legal basis was included in the list · In Subsection E, Recital 49 is added b/c this is exactly what Recital 49 is meant for. · Subsection F - Requestor will comply with all GDPR aspects · As far as disclosing the data, same standard safeguards should be applied. · If automation is possible, the hope would be that info could be disclosed in a few seconds. If manual, same-day response would be desirable. b) Feedback from EPDP Team · Consternation with 6(1)(d) as a lawful basis - it would be easier to walk through 6(1)(f) as a contracted party · Urgency of the request is something that should dictate the response and speed of the response. · This is the original purpose of collecting and displaying WHOIS data. 6(1)(d) may make registrars nervous. · Issue with 6(1)(d) - that legal basis is very limited in scope. · It would be helpful for anyone making comments in today’s meeting in the Google Doc itself. c) Confirm next steps 7. Any other business (5 minutes) · In preparation for the Los Angeles F2F, Janis suggested having CEO present during F2F. In order to structure that conversation, Support Staff will create a Google Doc with a few initial questions and EPDP Team members may contribute additional questions. 8. Wrap and confirm next EPDP Team meeting (5 minutes): a) Thursday 29 August 2019 at 14.00 UTC (5 minutes) b) Confirm action items c) Confirm questions for ICANN Org, if any

2 1