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

RrSG initial comment on SSAD Registrant user group
by Sarah Wyld 10 Jun '19

10 Jun '19

Hello all, The RrSG has significant concerns with the inclusion of Registrants as a user group for the System for Standardized Disclosure of non-public gTLD registration data, and strongly recommends that this group be removed from the proposed list of users. We are curious as to the origin of these proposed user groups, and suggest that instead of working through this list we begin by reviewing the purposes for processing data (Recommendation 1) and assessing the potential user group applicable to each purpose. Registrants already access their domains via their service provider (registrar or reseller)’s system, as required under the RAA. Having multiple interfaces to access the same information poses a significant risk of inappropriate data exposure; this unnecessary and unbalanced security risk is not compliant with data protection law. It also creates a confusing user experience for the registrant. For example, if a registrant uses the SSAD to review their domain data for the purpose of confirming that it is accurate, they would still need to work with their service provider to confirm that the data held in that system is also up to date. The RrSG notes that a system used to access or disclose data is not also a system to modify that data. The EPDP team definitions of access and disclosure do not include any capability to modify the data, so this is a new addition to the requirements not grounded in any previously agreed-upon basis or definition. Modification of domains via the SSAD could easily result in synchronization issues and security risks, where the SSAD holds data that is different from what is in the registrar or reseller’s platform, or an unauthorized party could modify and even hijack a registered domain. This also represents a fundamental shift from the system in place for the past twenty years: EPP is one-directional, with data flowing from the reseller or registrar through to the registry, so any functionality for updating domain data would need to be created and implemented by thousands of service providers worldwide. We look forward to discussing this important concern at today’s EPDP team call. Beyond these concerns about the “Registrants” group, we are also uncertain that “end users” is a valid group; this and the other groups should be discussed with the plenary team. -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392

6 6

EPDP Team input in response to GNSO Council's request
by Janis Karklins 09 Jun '19

09 Jun '19

Dear Keith, Following the request of the GNSO Council for the EPDP Team to identify any questions, comments or concerns to be shared with the ICANN Board in relation to their action on the EPDP Phase 1 Recommendations, 3 groups provided their feedback (see Annex A) which the EPDP Team discussed during its meeting on 6 June 2019. Although there was not sufficient time to formalize and agree on an EPDP Team response, the team felt it important to share the different perspectives with you to help inform the Council’s preparation for the consultation process with the ICANN Board. My take-away from the discussion was that: · In relation to purpose 2, there is general understanding for why the Board decided to not adopt this purpose and the EPDP Team confirms that it considers it firmly within its scope for phase 2 to further review this purpose in the context of the System for Standardized Access / Disclosure (SSAD); · For recommendation #12, some additional context has been provided that may help explain the thinking behind the EPDP Team’s original recommendation. However, there is no agreement at this stage on whether or not the Board’s non-adoption should be supported. The EPDP Team understands that following the GNSO Council’s consultation with the ICANN Board you will follow up with us to provide an update on dialogue with ICANN Board and request further input on the possible next steps for GNSO Council. The EPDP Team stands ready to assist as needed. Best regards, Janis Karklins

1 0

Recordings, Attendance & Zoom Chat / EPDP - Phase 2 / Thursday, 06 June 2019
by Terri Agnew 07 Jun '19

07 Jun '19

Dear all, Please find the attendance attached to this email, and links to the audio recording, zoom recording (audio, visual, rough transcript) and chat below from the EPDP – Phase 2 call held on Thursday, 06 June 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/6YSGBg Audio Recording: https://gnso.icann.org/sites/default/files/policy/2019/audio/audio-epdp-gtl… Zoom Recording (includes visual and rough transcript. To access the rough transcript, select the Audio Transcript tab): https://icann.zoom.us/recording/share/IdzcB-EYtEWP4-56mGz4aekIci4O0N3yAYup8… Chat:https://icann.zoom.us/recording/download/2D3oJPPfuoP1XACPGkiB3EOXKU79qTdt7pT1PNl71CdxtNbWDQwYkn6MFBlsXKJq ** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Terri

1 0

Updated Priority 2 Worksheets: PPSAI and Natural vs. Legal
by Caitlin Tubergen 06 Jun '19

06 Jun '19

Dear EPDP Team, Further to the request during today’s call, please find links to the updated worksheets for PPSAI and Legal vs. Natural following the Priority 2 Worksheets call on Monday, 3 June. Thank you. Best regards, Marika, Berry, and Caitlin

1 0

Notes and action items from EPDP Call #5 6 June 2019
by Caitlin Tubergen 06 Jun '19

06 Jun '19

Dear EPDP Team, Please find notes and action items from today’s call below. As a reminder, the next plenary call will be Thursday, 13 June at 14:00UTC. Best regards, Marika, Berry, and Caitlin -- ACTION ITEMS Support Staff to update the working definitions based on input received from the EPDP Team. Each group to nominate one person for the representative legal committee and provide the nomination to the Chair in advance of the next meeting, Wednesday, 12 June. Within 2-3 hours after the call, Support Staff to work with the EPDP Chair to produce a one page synthesis of concerns and questions the Team wishes to provide to the Council regarding the Board resolution. Annex all submissions to that synthesis page. Post synthesis page for silent procedure until tomorrow (Friday, 6 June). EPDP Team to only react if there is violent disagreement with concept (not edits, etc.) Team to review the Priority 1 SSAD Worksheet by COB tomorrow, Friday, June 7. Staff will then edit the document based on the suggestions and provide it to the Team by Tuesday, June 11. Support Staff will organize a list of purposes from previous documentation (https://www.icann.org/en/system/files/files/gdpr-dataflow-matrix-responses-…) and post for Team members to suggest edits by Tuesday, 11 June. Notes & Action items These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. 1.Roll Call & SOI Updates (5 minutes) Alternate from NCSG and RrSG 2. Confirmation of agenda (Chair) No objection 3. Welcome and housekeeping issues (Chair) (10 minutes) SG/C/SO/AC input requests have been sent – deadline for input 21 June · No comment Working definitions · Input received on “access” and “legitimate interest”. There is no agreement on the “access” definition. Text on “legitimate interest” has been modified based on proposed edits. · Replace “full set and subset of the data set” with “provision of a dataset appropriate for the purpose” or “provision of a dataset necessary to achieve the purpose”. · Second bullet, 3rd party access, definition is dependent on GDPR but policy is meant to be global policy, replace “GDPR” with “applicable law”. · SSAD bullet point: ICANN is not a third party, suggest “third party plus ICANN” · These are not agreed text by the whole group yet, but incorporate the input as part of the exercise. · ACTION ITEM: Staff to update the working definitions based on input received from the EPDP Team Legal advisory group · The Chair proposed to create a subset of the team -- a small team, but not with a representative model -- to make a first cut of legal issues, review the issues, and discuss them with the Team. Every legal question will be dealt in the small team, staff and leadership will propose background document for the consideration of the group. · Important that the questions are delivered to the legal counsel with no censoring on the questions, and get responses from the legal counsel fast. Don’t lose time on the formality or how this small team would not work out. · The task for the small team is to formulate the right questions, filtering out the questions that legal advice has already been provided. · The small team should be balanced and all interest should be represented. It should be clear that the team cannot be dominated by certain interests. · Why can't we revert to the format and category composition used by the "legal committee" in phase 1? (New members where previous members are not participating in Phase 2.) The Phase 1 legal committee seemed to function okay. · It seems premature to abandon the sub team concept. Support continuing the legal group as a sub group. · Based on the input from the team. Chair withdrew his proposal. · ACTION ITEM: Each group nominates one person for the representative legal committee, and lets the chair know the nominee by the next meeting. 4. Review of clarifying questions, concerns and/or background information submitted in relation to GNSO Council -Board consultation in relation to Board action on Phase 1 recommendations - see https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.… (Chair) (15 minutes) a. Overview of clarifying questions, concerns and/or background information put forward · RrSG: · Rec 12, significant background info has been provided, propose to focus on the solution. Can add a similar requirement as the one in Rec 29 for Rec 12. It is important to have a blank organization field. If the presence of data in the Org field indicates that the domain is owned by a legal person, then natural persons must be able to keep the field blank. If we cannot delete the Org field contents, how would we make the field blank for this user? · Redaction is not necessarily sufficient for data minimization principles, it is still a processing activity for which we may not have a legal basis. · RySG · Feedback is similar to the registrars. Rec 3 and Rec 18 were adopted by the Board. · Organization field, some concerns about implementation, unintended consequences. If incorrect data cannot be deleted, it would be troublesome. Should provide more info to the Council and Board why the recommendation is made it was. RrSG’s suggestion about deleting data is practical and can be implemented. RySG supports RrSG’s suggestion. · ALAC: · Board has issue with “deleting” the field. The option is to continue redacting the field, unless the registrant has been silent. · BC: · Rec 1, purpose 2, we agree that the Board question but disagree with how to address it. See email from Margie’s email. Separate the purposes, one for ICANN purpose and one for third party purpose. EPDP Team should come up with a revised version of purpose. · Rec 12 part of the concern is the inaccuracy of the org field. That is related to inaccurate records but not general concept of the org field. The rec be modified to allow the contracted parties to update any inaccuracies. · NCSG: · Rec 1, Purpose 2: the proposed second part of purpose 2 Margie propose was considered and soundly rejected during Phase 1. The only reason of getting consensus is rejecting idea. Issue should not be relitigated, and it did not address the Board comments. · EC advice is that purpose 2 is not needed. If including this purpose, it is inflating the ICANN purpose with the third party purpose. · IPC: · Not sure how to address EC’s comments, not to inflate ICANN purpose and third party purpose. · ISPCP · Should focus on working on phase 2 and not try to fix to purpose 2 now without legal counsel responses yet. · The data field can be deleted, otherwise it would potentially cause troubles to the legal party involved. · If the new policy is not to have an org field as it is not required, then the data has to be deleted if the user incorrectly populates the field with data that is the only piece of data to identify the registrant. · The org field is optional and therefore it must not contain data that is the only data with which the registrant can be identified. . b. Discuss which of these have support of EPDP Team to be submitted to GNSO Council c. Confirm next steps · ACTION ITEM: Within 2-3 hours after the call, Staff to work with the EPDP Chair to produce an one pager synthesis of concerns and questions the team wishes to provide to the Council regarding the GNSO-Board resolution. Annex all submissions to that synthesis page. Post synthesis page for silent procedure until tomorrow. EPDP Team to only react if there is violent disagreement with concept (not edits, etc.) · Now the EPDP Team should focus on clarifying questions, concerns and comments, then the Team can focus on what to do next. The document should separate out the explanatory background and the clarifying questions, from what should happen and how should the Council deal with these questions. · Leave the window open for feedback and commentary to the GNSO Council. Submit the feedback by Friday. The more information we send to the GNSO Council the better. Clearly there is divergence. Prefer Janis’ initial suggestion. 5. SSAD Priority 1 worksheet (15 minutes) (Marika) a. Overview of input received – see https://docs.google.com/document/d/1uoolznpxb0JxddFZA5n9ueRkB4tjDOQQCoMeQWp… [docs.google.com] · Thank you to all Members who provided feedback thus far. · Following the call, Support Staff would apply the non-controversial changes in redline format. Staff would not apply to the substantive changes, but rather, flag those for future discussion. · Action: Team to review the Priority 1 Worksheet by COB tomorrow, Friday, June 7. Staff will then edit the document based on the suggestion. b. Further comments / questions c. Confirm next steps for finalization of priority 1 worksheet · Action: Team to review the Priority 1 Worksheet by COB tomorrow, Friday, June 7. Staff will then edit the document based on the suggestion. 6. SSAD – Topic c Topic: Define user groups, criteria and purposes / lawful basis per user group (Marika) (60 minutes) a. Review template developed by staff support team (see attached) · Support Staff aimed to kick off the conversation with the user groups and looked at various documents that touched on this topic, and from that review, came up with this document. · The document is a starting point for the Team to begin its deliberations. · After the Team has broad agreement on the user groups, the Team will look at data elements for the purposes identified. b. EPDP Team input · Starting from groups may not be the correct approach; it may be preferable to look at the purposes and then look at the users. · If the Team is looking at which data elements to apply to which requestor, what will happen if there is a new requestor group after the Final Report is delivered? This does not seem like a practical way to go forward. · This approach is backwards, and the categories are bizarre. The RDS Working Group started from the idea of user groups and use cases instead of purposes - this amounted to a lot of wasted time. Confused by the group “end users” - why is this a category? The Team needs to set aside the user groups until we discuss the purposes that require disclosure. · The document is a good attempt at trying to structure the conversation. Having these documents and clearly articulating that it is for discussion purposes is good - this is document is not binding. · There are two challenges related to this document - it is common to start with user groups and profiles to build an engineering group. The failure of the previous PDP may be because they were not trying to design anything. It is also equally valid to look at the purposes. Within the document itself, we may be conflating the lawful bases and the use cases with the ultimate implementation of the system. · The group needs to stop looking at defining the purposes of user groups. If we look under 6(1)(f), it is not about the legitimate purpose or business group, it is the legitimate purpose based on the data the group is seeking. The registrant is the data subject - therefore, they do not need a legal basis. · If the Team starts with the concept that we are building a UAM, then you are building a system to provide access. However, what the Team is doing is trying to implement GDPR in a series of procedures, processes, and management practices. If you approach it from a user group, it will vary on a case-by-case basis. Who is requesting third party disclosure - someone has to authenticate the third party, someone has to parse the request and determine if there is a legitimate interest, and then someone has to figure out how to provide the data and make sure nothing goes awry. · The Team needs to bake in the registrant user group so that registrants can access data that is being processed about them. Unsure if registrants are guaranteed access to data in the registrar portal. · When a large online system is designed, it has to understand who will be doing what and what will be done within the system. It is true that if you define a large aggregate user group and then haphazardly sprinkle in interests that they have, there are problems. Since we have this document, introducing greater granularity is OK, but either method is acceptable. · What the Team should be careful of is not to conflate purposes and users. The definition of law enforcement needs to be refined. · A data subject can go to any controller and ask a question. The controller has a legal obligation to respond to the data subject. · There seems to be a presumption in some interventions that everyone in the same category gets the same data. That is not the case. This is just a way to start the discussion. · The Team should start with purposes. This document should not start with user groups; it should start with purposes. c. Confirm next steps · Proposal to take one user group - there is an identified purpose and a basis. Would 6(1)(e) and 6(1)(f) be the appropriate basis for law enforcement to request information? · No. The purposes for requesting data for law enforcement is on the local law that gives them the right to access the data. If we look to the GDPR, we are looking at the wrong place. · Law enforcement are not able to use 6(1)(f) within the EU. · It is not for this Team to decide on a third party’s legal basis. · This Team is supposed to be developing a global policy. If we are creating a global policy, we should create user groups that are jurisdictional in nature, i.e., law enforcement in the jurisdiction of the registrant/Rr/Ry. Accordingly, the distinction b/w EU law enforcement and non-EU law enforcement makes no sense here. · The Team has a lot of work to do here - the investment now will cut down on the 6(1)(f) requests down the road. · The Team should be making use of the wisdom of the groups implicated in this chart - ask law enforcement to provide their lawful basis and what they need. · Action item: All members to put down purposes they believe are relevant, then we will identify who will be the requestor. · A lot of this work has already been done in the calzone model - the group should consider what of this could be used rather than reinventing the wheel. Please see: https://www.icann.org/en/system/files/files/gdpr-dataflow-matrix-responses-… · Support Staff can put the previous list of purposes into a Google Doc and Team Members can add to it. We can then take the list of purposes and match it to the requestors. 7. Any other business a. Priority 2 small team meetings update · The updated worksheets for PPSAI and Legal vs. Natural have been updated and will be posted to the list after this call. · Following the already-scheduled meetings, we will endeavor to schedule meetings only on Tuesdays and Thursdays going forward. b. Reminder - Call schedule remaining priority 2 worksheets Wednesday, 12 June - 20:00 – 21.30 UTC City field redaction Data Retention Monday 17 June – 13:00 – 14:30 UTC Potential OCTO Purpose Feasibility of unique contacts to have a uniform anonymized email address TBC (post ICANN65) Accuracy and WHOIS ARS 8. Wrap and confirm next meeting to be scheduled for Thursday, 13 June at 14.00 UTC (5 minutes) a. Confirm action items b. Confirm questions for ICANN Org, if any

1 0

For your review - Input to Council on EPDP Team Phase 1 consultation process with ICANN Board
by Marika Konings 06 Jun '19

06 Jun '19

Dear EPDP Team, Per today’s discussion, please find attached for your review the proposed communication to Keith Drazek, GNSO Chair concerning the feedback received from EPDP Team members in relation to the non-adoption by the ICANN Board of parts of two of the EPDP Team Phase 1 recommendations. Please make it know by end of day tomorrow, Friday 7 June, if your group has any serious concerns about the synopsis on page 1. Best regards, Caitlin, Berry and Marika Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<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

Meeting Invitation: Observers GNSO Temp Spec gTLD RD EPDP - Phase 2 call / Thursday, 13 June 2019 at 14:00 UTC
by Terri Agnew 06 Jun '19

06 Jun '19

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, 13 June 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/y48z4mrm Agenda Wiki: https://community.icann.org/x/7ISGBg 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 Telephone numbers: 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, Terri

1 0

Proposed Agenda EPDP Team meeting #5 - Thursday 6 June at
by Marika Konings 06 Jun '19

06 Jun '19

Dear EPDP Team, Please see below the proposed agenda for Thursday’s EPDP Team meeting. Due to unforeseen circumstances, Steve Crocker will not be able to attend so his presentation to the EPDP Team will be rescheduled for another time. Please review the attached document prior to the meeting in preparation for agenda item 6. Best regards, Caitlin, Berry and Marika EPDP Phase 2 - Meeting #5 Proposed Agenda Thursday, 6 June 2019 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (10 minutes) * SG/C/SO/AC input requests have been sent – deadline for input 21 June * Working definitions * Legal advisory group 4. Review of clarifying questions, concerns and/or background information submitted in relation to GNSO Council -Board consultation in relation to Board action on Phase 1 recommendations - see https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.b (Chair) (15 minutes) * Overview of clarifying questions, concerns and/or background information put forward * Discuss which of these have support of EPDP Team to be submitted to GNSO Council * Confirm next steps 5. SSAD Priority 1 worksheet (15 minutes) (Marika) * Overview of input received – see https://docs.google.com/document/d/1uoolznpxb0JxddFZA5n9ueRkB4tjDOQQCoMeQWp… * Further comments / questions * Confirm next steps for finalization of priority 1 worksheet 6. SSAD – Topic c Topic: Define user groups, criteria and purposes / lawful basis per user group (Marika) (60 minutes) * Review template developed by staff support team (see attached) * EPDP Team input * Confirm next steps 7. Any other business * Priority 2 small team meetings update Reminder - Call schedule remaining priority 2 worksheets: · Wednesday, 12 June - 20:00 – 21.30 UTC City field redaction Data Retention · Monday 17 June – 13:00 – 14:30 UTC Potential OCTO Purpose Feasibility of unique contacts to have a uniform anonymized email address · TBC (post ICANN65) Accuracy and WHOIS ARS 8. Wrap and confirm next meeting to be scheduled for Thursday, 13 June at 14.00 UTC (5 minutes) * Confirm action items * 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…>.

4 5

BC Input on the Board resolution
by Margie Milam 05 Jun '19

05 Jun '19

Dear All- With regard the recent Board action on the Phase 1 Report – here are a few observations from the BC: * Rec 1:Purpose 2: The BC agrees that Purpose 2 should be reworked in light of the recent EU Correspondence. As such, the consultation with the GNSO should determine how to accomplish this change. Under the current circumstances, it seems the EPDP is in the best position to suggest a change. We propose to split Purpose 2 into two separate purposes: * Enabling ICANN to maintain the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission and Bylaws through the controlling and processing of gTLD registration data * Enabling third parties to address consumer protection, cybersecurity, intellectual property, cybercrime and DNS abuse involving the use or registration of domain names * Recommendation 12: The BC agrees with the Board’s concerns regarding the ORG Field, and suggests that the EPDP update its Phase 1 recommendations to remove the deletion option. Instead, the recommendation could be modified to allow the contracted parties to update any inaccuracies in the ORG field, as appropriate. All the best, Margie and Mark, On behalf of the BC

1 0

BC Comments to the User Groups
by Margie Milam 05 Jun '19

05 Jun '19

Dear All, On behalf of the BC, here are our comments to the Proposed User Groups: Registrants: * We agree that Registrant Access is necessary. For example, one common use case is where the registrant may be a company whose former employee may have registered the domain name in a personal account, and the company may not have access to the registrar account. Another is where someone has purchased or transferred a domain name and needs to confirm that the acquisition or transfer has been properly completed. * We note that this user group has an additional legal basis, and suggest that this section be updated to include Article 15 (right of access for data subject). Endusers: * We agree that end users need access for consumer protection purposes. This is consistent with the EU Data Protection Board’s letter last year that recognized ICANN’s mandate under its Bylaws to assess whether WHOIS meets the “legitimate needs of law enforcement, promoting consumer trust and safeguarding registrant data”, and also recognized ICANN’s commitment to adequately address issues of competition, consumer protection, security and stability, malicious abuse, sovereignty concerns and rights protection prior to authorizing an increase in new GTLDs. * The legal basis should also include 6(1)(e) (public interest), and 6(1)(b) – performance of contract, as referenced in the EC letter dated March 19th. EU & Non-EU Law Enforcement: * These should be combined into one user group * The legal basis should include 6(1)(b) performance of contract, and public interest 6(1)(e), and should not include 6(1)(f) since the EC letter states that “[i]t is also worth recalling that under the GDPR legitimate interest cannot be used as a legal basis for data processing by public authorities (including law enforcement authorities) in the performance of their tasks.” It should also be 6(1)(c) in some instances, as per the EC’s comments on the Phase 1 Final Report. Intellectual Property: * We support each of the purposes listed in c) and should add another bullet: To support investigations to facilitate usage of ICANN’s rights protection mechanisms * The legal basis should include 6(1)(b) performance of contract and 6(1)(e) public interest. * b) self- certification of the owner, attorney, agent, analyst as representing an IP rights holder Commercial: We support this user group. Security Researchers: * This purpose should be renamed “Security Practitioners.” * The definition is too narrow and should include “individual or entity involved investigating, analyzing and mitigating security, fraud and cybercrime” * The legal basis should include 6(1)(b) performance of contract and 6(1)(e) public interest. * b) self-certification as a member a recognized security mitigation group such as APWG, MAAAWG, CAUCE, and required recertification on an annual basis; Academic Researcher: * This purpose should be updated to include cybercrime and abuse research. * The legal basis should include 6(1)(e) public interest. * c) Employees, professors, and students in post-secondary education institutions conducting research or studies involving domain names Additional user - ICANN: We need to address ICANN’s use of WHOIS, as well as those entities under contract with ICANN, such as to conduct security-related studies, or to allow ICANN to continue with the WHOIS Accuracy Reporting System. All the best, Margie and Mark On behalf of the BC

1 0