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

**REMINDER** Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Thursday, 12 August 2021 at 14:00 UTC
by Julie Bisland Aug. 11, 2021

Aug. 11, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 12 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/4oMZCg * Check your time zone: https://tinyurl.com/4d4mtx94 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4d4mtx94__;!!PtGJab4!pJXi5Wm…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz)’before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Andrea

1 0

Proposed Agenda - EPDP Team meeting #35 on Thursday 12 August at 14.00 UTC
by Marika Konings Aug. 10, 2021

Aug. 10, 2021

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting, which has been scheduled for Thursday 12 August at 14.00 UTC. As a reminder, please review the draft section 3 that now has been posted (see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#) focusing on the tables that have been inserted for recs #1 - #3 and using the orange tables to provide your group’s input in advance of Thursday’s meeting. Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #35 Proposed Agenda Thursday 12 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Initial Report Public Comment Review (15 minutes) * EPDP Team Question for Community Input #5 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/18_TwHMQSnV9fWryJZJdTP0awO-FRUZ5L/edit> · #2 · #4 * Additional Comments – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/1ido40sJSe2p1bRQirUg8wJ02DWL-me1-/edit> · None 4. Commence review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (60 minutes) – see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit> As a reminder: proposed timeline to get to Final Report 10 August – complete review of public comments 12 August – delivery of action items mediated conversations, confirm possible suggestions for further consideration. 17 & 19 August – consider suggestions for further consideration & agree on updates to report 24 & 26 August – consider suggestions for further consideration & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. a. Recommendation #1 · Consider input provided · EPDP Team discussion · Confirm next steps b. Recommendation #2 · Consider input provided · EPDP Team discussion · Confirm next steps c. Recommendation #3 (if time allows) · Consider input provided · EPDP Team discussion · Confirm next steps d. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #36 Tuesday 17 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

Notes and action items - EPDP Phase 2A Meeting #34 - 10 Aug 2021
by Caitlin Tubergen Aug. 10, 2021

Aug. 10, 2021

Dear EPDP Team, Please find below the notes and action items from today’s meeting. The next EPDP Phase 2A meeting will be Thursday, 12 August at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- ⚠️ Action Items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…>⚠️ 1. EPDP Team members to indicate benefits and operational challenges of a (i) legal v. natural differentiation and (ii) standardized data element within the dedicated Google Doc<https://docs.google.com/document/d/1L-SdgAb0tJlGJoBbuRWHuKSuZRIdXnia/edit> by COB Friday, 13 August. ⚠️⚠️Note: this is an extension from the original due date of Wednesday, 11 August.⚠️⚠️ 2. EPDP to review Section 3 of the Draft Final Report document<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#h…>, particularly the tables associated with Recommendations 1 - 3, in advance of our next meeting on Thursday, 12 August. Note: if EPDP Team Members have comments on the tables, please provide feedback IN COMMENT FORM and please do not redline or provide comments on the rest of the document at this time. EPDP Phase 2A - Meeting #34 Proposed Agenda Tuesday 10 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) - The Leadership Team did not receive any requests for a project change request extension. Leadership requested the if anyone believed an extension was necessary, they needed to put a request and accompanying rationale in writing. - Accordingly, the Team will be working to the dates shown on the screen – with a goal of submitting the Final Report by 2 September. - We will go back to focusing on the public comment review. When we get to the later parts of the agenda, we have a new template and document review to share. 3. Initial Report Public Comment Review (65 minutes) a. EPDP Team Question for Community Input #4 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/111EAx9BuJphPwM22wsvG_oRxj27-r20r/edit> * There are still some comments to go through – we will pick up where we left off (Preliminary Recommendation #4 – the specific guidance for contracted parties who choose to differentiate.) There were four questions asked for community input – 1. Does this guidance as written provide sufficient information and resources to Registrars and Registry Operators who wish to differentiate? If not, what is missing and why? 2. Are there additional elements that should be included? 3. Are there legal and regulatory considerations not yet considered in this Initial Report, that may inform Registries and Registrars in deciding whether and how to differentiate, and if so, how? 4. If a Registrar or Registry Operator decides to differentiate, should this guidance become a requirement that can be enforced if not followed ("MUST, if Contracted Party decides to differentiate")? · #2 (GAC, BC, ALAC) * Should this be referred to as best practices instead of guidance? * BC would like the language changed from guidance to best practices. Remind the group that the GNSO PDP manual does not list guidance as an appropriate outcome of a PDP but does list best practices. * The concern about best practices is that the word has a specific legal meaning in certain jurisdictions – specifically, if a CP chooses not to follow a best practice in certain jurisdictions, they will be subjected to liability. * Can accept guidance of a voluntary nature, but this is a restatement of the law – not sure how this could be considered “best practices” – it is not clear what is best or good here. More input is needed. * Agree that a code of conduct should be pursued as part of the outcomes of this policy process. The notion of guidance came along after the EPDP was started. The Board’s instructions were to create consensus policy, not to create guidance. * Thought we were going through public comments and flagging new information – do not see additional or new information here – this is simply rehashing an issue that we debated months ago. Suggest making a note and moving on. * PDP Manual does allow for guidance, contrary to previous comments, as the list is not exhaustive. · #3 (ALAC, BC) * ICANN org notes that if there are requirements in this guidance (for example must if), they need to be specifically called out, or the guidance would not be enforced. * When looking at the Initial Report – one question is the team is not recommending requirements, but from org’s perspective – if a registry or registrar chooses to follow the best practices, do they have to follow some or all of the guidance, or if they differentiate, do they have to follow them at all? · #5 (BC, ALAC) * There should be a requirement to classify a registrant as natural or legal, and until the time comes for all registrations, an unspecified classification could be used until a specific time in the domain name lifecycle, such as renewal or WDRP notice. * If differentiation occurs, this should happen during registration. If it happens after registration, it puts a burden on contracted parties and registrants. Many CPs do not engage with the registrant again after registration happens. They may engage during the renewal of the domain name. * This is problematic because if there is one thing that is helpful for implementation it is having options. There is no need to necessitate a determination at the point of registration. * Registries do not have contact with registrants in this process, and this is asking registries to process more data. This statement by SSAC – registrants being classified as legal vs. natural persons ignores the concept that legal persons can still have personal information in their registration data. * SSAC is recommending that there be a classification regardless of it is used by the registrant/registrar. If that is correct, this makes sense, given that the NIS2 directive will require a designation. * The idea of including the data element in the data dictionary is straightforward – the data dictionary is not owned by the GNSO or Contracted Parties. There ought to be a data element that defines this. The separate question is whether this should be required or even offered – this is something that needs to be settled within these discussions. Some colleagues may fervently wish that this be required – there is greater complexity – even if you know it’s a natural person, that does not tell you if the data should be redacted. There are three parts to this: should it be in the data dictionary? Yes. Should it be required? Open question. How is this available via public inquiries? This is also an open question that is thus far not very well sorted out. · #7 (IPC, BC, ALAC) * The guidance does not recognize the differentiation b/w legal and natural person data. The guidance does not state that the GDPR does not apply to the data of natural persons. Adding this guidance would be very beneficial – making it clearer that legal person data is not covered under GDPR. * What does ICANN do when NIS2 is approved? That discussion will focus on mandatory differentiation. It makes sense to anticipate this – state what the GDPR already says and set the table to what we will eventually have to do – address NIS2 requirements. * As guidance, it would be useful to registrars who do not actively follow this work to have it clear that GDPR does not apply to legal persons. * Do not find this useful – what would find useful is an explanation of what data is required to be protected and what the consequences of getting it wrong are. Willing to review suggested text; however, difficult to respond to the suggestion without seeing suggested text. * Action: GAC colleagues to put forward specific text · #9 (BC, RySG) * This comment is incorrect – there is nothing in the Chinese law that requires a differentiation between legal and natural persons. It requires a real name, but does not require stating legal v. natural. * No one is advocating for the release of all personal information. · #12 (BC) * Have not dug into what contractually could reduce risk. This is an area where the Team could do additional work to increase the safeguards. * In response to comments from the RrSG, this is the appropriate place to consider changes to Phase 1 policy recommendations. · #14 (BC) * The NIS2 is something that should be factored in as part of these recommendations. · #16 (BC) * Comment from the GAC – importance of stating benefits of releasing data to the public. * The GDPR states this best in terms of proposed language. It would be acceptable to quote article 14. Explicitly states that the regulation does not cover the processing of personal data of legal persons. * How do we reconcile ambiguity in recital 14 with letter from DPAs to ICANN re personal data contained in legal person’s registration data? * This recital is part of the GDPR, and do not think that a letter can trump the explicit language of the regulation. * Recital 14 talks about no protections afforded to legal entities. When there are details of natural persons enshrined in the data of a legal person – acknowledge once and for all that recital 14 does not help with this policy discussion. * A letter does not trump a regulation, but the regulation states that personal information of private individuals must be protected, irrespective of where it is maintained * Recital 14 forms the basis of why we are asking to differentiate between legal and natural persons * Action: proposal for further text on the list · #17 (BC) * Important to highlight why it would be useful to adopt the guidance · #18 (BC) · #20 (BC) * ICANN should have policy that support NIS2 – the policy restart would require a new PDP, and that PDP could be blocked by parties in the GNSO that do not agree. When NIS2 is adopted by the parliament, this should be a trigger to restart the PDP. Do not know the right mechanism to restart the PDP when NIS2 is adopted. Best to resume the work at the appropriate time and cannot be blocked from doing the work at the appropriate time. * Ask that members stop imputing statements regarding what they expect other parties to be doing. Given the current drafting of the NIS2, what actually in policy of ICANN prevents CPs from following NIS2? * The Team should be laying the appropriate groundwork for future GNSO action; this would show that the team’s intentions are correct. * GAC supports requirement of differentiation · #21 (BC) b. EPDP Team Question for Community Input #5 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/18_TwHMQSnV9fWryJZJdTP0awO-FRUZ5L/edit> · #2 (BC) · #4 (BC) c. Additional Comments – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/1ido40sJSe2p1bRQirUg8wJ02DWL-me1-/edit> · None 1. Next Steps & Approach (10 minutes) * The proposed timeline to get to the Final Report is included in the agenda -- the only addition is the deadline for minority statements of 30 August. * Hope to cover the remaining public comments during Thursday’s meeting. * On Monday, Staff Support circulated the draft Final Report minus Section 3 – most changes were of an administrative nature. What we will review separately is Section 3. * Based on the conversations from the group, the Support Staff Team has included tables into Section 3 of the report. * Support Staff created a table that includes initial report language and underneath that is a list of possible suggestions based on public comment review and mediated conversation. From that, Leadership Team has made an assessment based on the support a suggestion had. This assessment has resulted in proposed updates to the recommendation language. For Rec. 1, for example, there was a suggestion that as nothing is recommended in Rec. 1, this should be labelled as a response rather than a recommendation. As a reminder: proposed timeline to get to Final Report 10 August – complete review of public comments 12 August – delivery of action items mediated conversations, confirm possible suggestions for further consideration. 17 & 19 August – consider suggestions for further consideration & agree on updates to report 24 & 26 August – consider suggestions for further consideration & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. a. Proposed approach for reviewing possible suggestions and updates to recommendations b. Final Report minus section 3 available for review c. EPDP Team input d. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #35 Thursday 12 August at 14.00 UTC b. Confirm action items * EPDP Team members to indicate benefits and operational challenges of a (i) legal v. natural differentiation and (ii) standardized data element within the dedicated Google Doc<https://docs.google.com/document/d/1L-SdgAb0tJlGJoBbuRWHuKSuZRIdXnia/edit> by COB Friday, 13 August. Note: there has been an extension from the original due date of Wednesday, 11 August. * EPDP to review Section 3 of the Draft Final Report document<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#h…>, particularly the tables associated with Recommendations 1 - 3, in advance of our next meeting on Thursday, 12 August. Note: if EPDP Team Members have comments on the tables, please provide feedback IN COMMENT FORM and please do not redline or provide comments on the rest of the document at this time. c. Confirm questions for ICANN Org, if any

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2A | Tuesday, 10 August 2021 at 14:00 UTC
by Andrea Glandon Aug. 10, 2021

Aug. 10, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Tuesday, 10 August 2021 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/9QEuCg> and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a panelist, observers can join as an attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Andrea

1 0

Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Thursday, 12 August 2021 at 14:00 UTC
by Andrea Glandon Aug. 10, 2021

Aug. 10, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 12 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/4oMZCg * Check your time zone: https://tinyurl.com/4d4mtx94 ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz)’before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Andrea

1 0

**Meeting begins in 15 minutes** Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Tuesday, 10 August 2021 at 14:00 UTC
by Andrea Glandon Aug. 10, 2021

Aug. 10, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Tuesday, 10 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/9QEuCg * Check your time zone: https://tinyurl.com/2txhts9s [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/2txhts9s__;!!PtGJab4!sh3uEyr…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz)’before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Re: [Gnso-epdp-team] Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Tuesday, 10 August 2021 at 14:00 UTC
by Jan Janssen Aug. 10, 2021

Aug. 10, 2021

Please accept my apologies, as I won’t be able to join today’s call. Best regards, Jan Janssen* jjanssen(a)petillion.law<mailto:jjanssen@petillion.law> +32 486 48 39 94 www.petillion.law [cid:image001.png@01D78DD5.9BC41B70]<https://www.petillion.law/> Attorneys – Advocaten – Avocats *Standing representative of Anlirosu bv, a private company with limited liability performing the legal services From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Terri Agnew via Gnso-epdp-team <gnso-epdp-team(a)icann.org> Reply to: Terri Agnew <terri.agnew(a)icann.org> Date: Thursday, 5 August 2021 at 17:29 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Cc: ICANN ITSM via Gnso-secs <gnso-secs(a)icann.org> Subject: [Gnso-epdp-team] Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Tuesday, 10 August 2021 at 14:00 UTC Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Tuesday, 10 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/9QEuCg * Check your time zone: https://tinyurl.com/2txhts9s ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz)’before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Re: [Gnso-epdp-team] Proposed Agenda - EPDP Team meeting #34 on Tuesday 10 August 2021 at 14.00 UTC
by Marika Konings Aug. 10, 2021

Aug. 10, 2021

Dear EPDP Team, Please find below the updated agenda which now includes the items that have been flagged by the deadline for recommendation #5 and the additional comments. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings via Gnso-epdp-team <gnso-epdp-team(a)icann.org> Reply to: Marika Konings <marika.konings(a)icann.org> Date: Monday, 9 August 2021 at 17:01 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Agenda - EPDP Team meeting #34 on Tuesday 10 August 2021 at 14.00 UTC Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 10 August at 14.00 UTC. As a reminder, input on the discussion document for community question #5 and the additional comments is due by COB, today (Monday 9 August). Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #34 Proposed Agenda Tuesday 10 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Initial Report Public Comment Review (65 minutes) * EPDP Team Question for Community Input #4 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/111EAx9BuJphPwM22wsvG_oRxj27-r20r/edit> · #2 (GAC, BC, ALAC) · #3 (ALAC, BC) · #5 (BC, ALAC) · #7 (IPC, BC, ALAC) · #9 (BC, RySG) · #12 (BC) · #14 (BC) · #16 (BC) · #17 (BC) · #18 (BC) · #20 (BC) · #21 (BC) * EPDP Team Question for Community Input #5 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/18_TwHMQSnV9fWryJZJdTP0awO-FRUZ5L/edit> · #2 (BC) · #4 (BC) * Additional Comments – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pc…> and Discussion Table<https://docs.google.com/document/d/1ido40sJSe2p1bRQirUg8wJ02DWL-me1-/edit> · None 4. Next Steps & Approach (10 minutes) As a reminder: proposed timeline to get to Final Report 10 August – complete review of public comments 12 August – delivery of action items mediated conversations, confirm possible suggestions for further consideration. 17 & 19 August – consider suggestions for further consideration & agree on updates to report 24 & 26 August – consider suggestions for further consideration & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. a. Proposed approach for reviewing possible suggestions and updates to recommendations b. Final Report minus section 3 available for review c. EPDP Team input d. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #35 Thursday 12 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

EPDP-P2A // 31 Jul 2021 Project Package
by Berry Cobb Aug. 9, 2021

Aug. 9, 2021

Dear EPDP-P2A Team, On behalf of the EPDP-P2A leadership team, please find a link to the EPDP-P2A’s 31 Jul 2021 project package. As you will see, the Status/Health remain the same as “On-Schedule” and “On-Target” respectively. Of point, there was no notice or rationale submitted to the mailing list to request a deliverable extension by the deadline of last Friday. Therefore, no PCR will be submitted to the GNSO Council. The P2A team will continue to work towards it committed deliverable date of 2 Set. 2021 for its Final Report. Link: https://community.icann.org/x/dggNCQ 1. Page 01 – Summary timeline 2. Page 02 – Project Sitrep – an extract from the Council’s Project List 3. Page 03 – Group roster 4. Page 04 – Group attendance for plenary and legal committee 5. Page 05 – Work and activity metrics 6. Page 06 – Project Plan, Gannt chart 7. Page 07 – Work plan & Action items for the period Key points: * As with the previous edition, the remaining tasks on page 2 are flagged with a red status corresponding to the identified risk of getting to consensus for the final report. Please let us know if you have any questions. Thank you B Berry Cobb Policy Development Program Manager Internet Corporation for Assigned Names and Numbers (ICANN) berry.cobb(a)icann.org

1 0

Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified
by Hadia Abdelsalam Mokhtar EL miniawi Aug. 9, 2021

Aug. 9, 2021

Hi Volker, I totally agree with you that we should not tell CPs that a certain amount of risk is part of their business calculation. However, I certainly assume that risk is already part of their calculation, remember CPs are allowing registrants to consent to the publication of their data, also I think we all agree that zero risk does not exist. However let me clarify, if the registrar either requires the registrant to provide and answer to the type field (the answer could be unspecified) or offers the designation field as an option to the registrant, that does not mean that it will necessary publish this data. Disclosure falls under a different set of rules. Kind regards Hadia From: Volker Greimann [mailto:vgreimann@key-systems.net] Sent: Monday, August 09, 2021 6:24 PM To: Hadia Abdelsalam Mokhtar EL miniawi Cc: Steve Crocker; gnso-epdp-team(a)icann.org Subject: Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified Hi Hadia, yes, we have had this discussion before. And I appreciate it has less risk, but less risk is not no risk and therefore it has to boil down to the individual contracted party to evaluate their own risk appetite. It is not for us to tell them that a certain amount of risk of being found in violation of standing legislation is now part of their business calculation. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Mon, Aug 9, 2021 at 5:20 PM Hadia Abdelsalam Mokhtar EL miniawi <Hadia(a)tra.gov.eg<mailto:Hadia@tra.gov.eg>> wrote: All, As a reminder according to Bird & Bird memo, if personal information is disclosed by mistake due to the disclosure of a legal person's data that includes personal information, the risk in relation to fines is much less than if third parties personal information is disclosed by mistake based on the consent of the registrant. I stop now because I know this was discussed before, but this is just to reply to the possibility issue raised by Volker. Kind regards Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>] On Behalf Of Steve Crocker via Gnso-epdp-team Sent: Monday, August 09, 2021 5:04 PM To: Volker Greimann Cc: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified Volker, Is it your position that even if the registrant declares they are a business, i.e. a Legal Person, it is nonetheless necessary to restrict access to their contact data because it might contain personal information? If so, then it would seem there's no reason to ask the status and all registrant data should be treated as if it contains personal information. I'm not arguing whether this is a good or bad policy. I'm just asking if this is your interpretation. If so, it's a very clean, simple and easy to administer policy. I would also imagine it would engender an increase in efforts to obtain non-public data. Thanks, Steve On Mon, Aug 9, 2021 at 9:57 AM Volker Greimann <vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net>> wrote: All, please bear in mind that this group is not tasked with achieving a result "we like to see" but with determining whether a change from the previous result is possible, and if so, necessary. So far, no necessity has been demonstrated and even with regard to the possibility the issue of legal risk due to personal information being contained in legal entity data still remains. As such, the default stands. Sincerely, -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Mon, Aug 9, 2021 at 1:50 PM Hadia Abdelsalam Mokhtar EL miniawi via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Thanks Steve for this work and this brief. In relation to the collection rules and just to note, ultimately we would have liked to see rule number one {C} applied. Bearing in mind that rule number one does not necessary need to say "Legal" or " Natural" it can also say " unspecified". However, we do recognize that no consensus in this regard is possible. Therefore our compromised position is rule number 4 {C, O} and honestly speaking I do not understand why we cannot agree to this. The difference between 4 {C,O} and 7 {C,O,N} is that 7 allows the registrar to not offer the registrant the ability to specify. GDPR as we all know makes this distinction and therefore it is only fair to give the data subject the ability to specify if it wishes and please note here that we should not conflate what is being offered by the registrar or collected from the registrant with what is going to be available through the public RDDS. What is going to be available through the public RDDS and the rules associated with any type of disclosure, are governed by a different set of rules which we could discuss and possibly agree to. As for option 8, my understanding is that this option refers to a deadlock position, which is an uncommon position, however it is not 7. Best Hadia From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org<mailto:gnso-epdp-team-bounces@icann.org>] On Behalf Of Steve Crocker via Gnso-epdp-team Sent: Monday, August 09, 2021 12:06 AM To: EPDP Subject: Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified On Fri, Aug 6, 2021 at 10:05 AM Mueller, Milton L <milton(a)gatech.edu<mailto:milton@gatech.edu>> wrote: I also appreciate the nice logical summary of options, Steve. A slightly revised version of my memo is attached. The content is exactly the same, but I have included a table showing which the three possible registrar rules are consistent with each of the eight possible GNSO rules. I have also introduced "ø" as the notation for the empty set instead of "{}." This is purely a change in notation, not in meaning. Like Volker, however, I believe that you are overlooking the fact that we have debated these options for months and have arrived firmly at option 7 (there is no distinction between 7 and 8, by the way). In 7, each registrar is permitted to have whichever rule it chooses. In 8, no rule is acceptable. 8 is a logical possibility but, quite obviously, it leads to an impossible situation. If such a policy were ever adopted, everyone would most likely ignore it. In that event, yes, 7 and 8 would have similar effects, i.e. impose no constraint. However, when we take into account the effect of multiple policies, the combined effects of multiple rules might indeed be 8. Detecting that in advance is important. See more on this below. In the meantime, the current state of agreement is 7, i.e. the GNSO will not impose any constraint on whether a registrar always collects the registrant's status, never collects the registrant's status, or makes it optional for the registrant to state its status. Only 7 is possible, because that was the agreed outcome of phase 1 while we explored other options in Phase 2. In Phase 2 we discovered we cannot attain sufficient agreement to move off of that equilibrium. Some EPDP members will recall that I personally indicated a willingness to move toward something like #6. This did not fly. Neither the Contracted Parties nor my own SG would accept it, and the GAC, ALAC and two CSG constituencies still wanted something more like 1 or 2. "Something like #6," eh? Well, 6 is: 6 = {O, N}, a registrar must either make it optional or not collect it but may not require it Meanwhile, 1 = C, i.e. every registrar collects this value 2 = O, i.e. every registrar is required to make this optional I wonder if they might have wanted 4 = {C, O}, a registrar must either collect it or make it optional I'll come back to this later in this note, but first let's look at two other parts of this puzzle. First, there are logically four possible values regarding the status. * "Natural," indicating the registrant has declared itself to be a natural person, i.e. an individual * "Legal," indicating the registrant has declared itself to be a legal person, i.e. a business * "Unspecified," indicating the registrant has affirmatively refused to declare as either a Natural or Legal person * "Blank," indicating the question has not been asked. Is there a distinction between the third and fourth status, and does it matter? In some cases it could well matter. In cases where it doesn't matter, there's no harm in allowing for both possibilities and then treating them the same. Second, we come to the really big question: How will this piece of information be used? I think we all expect this may play a role in what data is returned when there is a request for registration data, but this hasn't been fleshed out. In very approximate terms, the general thinking is that data about Legal persons will be publicly available and data about Natural persons will not be. But this is only the beginning of the conversation, not the end. It is helpful to think in terms of two distinct processes. One is the process of collecting the data during the time of registration. The other is the process of responding to requests for information about the registration. Let's begin with the second process. The Request Process Requests for registration data will come from many different parties. Some will come from the general public, and the requester will not be required to identify itself nor adhere to any rules governing use or protection of the data. Others will come from identified, authenticated and authorized requesters who have agreed to abide by a set of rules governing the use and protection of the data they receive. Requesters in the latter category are not all the same. The data they receive will likely depend on who they are and how they will be using the data. Examples of different subgroups of requesters are network operators, individual researchers, law enforcement, and IP attorneys, and within each of these subgroups there will likely be different kinds of requests. For example, we know from interviewing the members of the Public Safety Working Group they can identify five different kinds of requests, one of which is a request available to anyone and four others that request more data and come with a specific set of rules governing use and protection. At least one kind of request will come with legal paperwork, e.g. a warrant or subpoena, but other kinds of requests will not. And they aren't the only subgroup that might have different kinds of requests. What distinguishes these various kinds of requests? In the work we've been doing, it appears reasonable to express requests in terms of two concepts. One is some way of specifying which data elements are being requested. The other is to specify the level of sensitivity, a term we've been using to include whether data is marked "public" or "private." Are there more than just two levels? Well, yes, it seems so. In listening to the extended policy discussions, we have heard that if a requester is only authorized to see data elements marked "public" and the actual data element existings but is not publicly available, the response will be "redacted." However, we have also heard there are some data elements that are more sensitive, and requests from someone not authorized to see them will not be told anything about the data element. This suggests there are at least three levels of sensitivity. As a working hypothesis, we use four levels. If this turns out to be too many, it's easy to reduce the number. To recap, we think of a request as specifying the set of data elements requested and the authorized sensitivity level. The response will not include any data elements outside of the requested set nor any data elements more sensitive than the authorized sensitivity level. Of course, all of this is in addition to the identification of the requester, the statement of purpose, a pointer to the requester's credential, and agreement regarding use and protection of the requested data. Specifying the requested data elements is not a small matter. The data dictionary has around 100 distinct data elements. Each contact is a dozen or data elements, with the name, organization, phone number, fax number, email, street address, city, province or state, postal code and country treated separately. Added to these are the data elements for the DNS records, for the payment data, for the IP address used at the time of registration, the dates of registration and expiration, register locks, etc. To make it more manageable, each data element is grouped into one of several categories. A request then specifies which of these categories are requested. The Registration Process With the above description of the request process, we can now fill in a few details of the registration process. In broad terms, the registration process consists of collecting data from the registrant and assigning a sensitivity level to each of the collected data elements. (And, of course, reserving the domain name and getting it delegated if the registrant wants to put the domain name into service.) To accomplish this process, the registrar has a set of rules governing which data elements are required, optional or not to be collected, and what sensitivity level to assign to each collected data element. Once this process is complete, the registrar then stores the data elements and is then in a position to process requests in accordance with the agreed upon terms in a request. A further and all important addition to this short description is the registrar might have one set of rules for registrants that are Natural Persons, a different set of rules for registrants that are Legal Persons, and perhaps even a different set of rules for registrants of Unspecified status. Moreover, the status of the registrant might not be the only factor that determines which set of rules the registrant will use to complete the registration. For example, some registrars may treat registrants that need a higher level of protection differently from ordinary registrants. Celebrities and public figures are examples of Natural Persons who may need extra protection. Registrations associated with an impending business deal, e.g. product announcements, tentative mergers, etc. are examples of registrations by Legal Persons that may need extra protection. Taking the above into account, the registration process can be thought of as having an initial phase to determine which set of rules to use for the registration, and then the main phase to collect and label the rest of the registration data. So What About Natural vs Legal? The putative purpose in collecting the registrant's status is to restrict the disclosure of some portion of a Natural Person's registration data from being publicly accessible. In the terms described above, this means marking those data elements as more sensitive than "public." But what happens if... 1. ... the registrar doesn't collect the status? 2. ... the registrant refuses to give its status, i.e. responds "Unspecified?"As As was stated at the beginning of this note, the current GNSO policy leaves the decision about collecting the status up to the registrar, so there's no guarantee the registrar will have this data. Even so, we might imagine a GNSO policy that says something to the effect of: if you collect the registrant's status, if the registrant's status is Natural, then apply rule set 1, otherwise, if the registrant's status is Legal, the apply rule set 2, otherwise, if the registrant's status is Unspecified, apply rule set 3 if you don't collect the registrant's status, apply rule set 4 So far, I haven't seen any discussion that goes into this level of detail, nor have I seen any discussion about taking into account other aspects of the registrant such as whether they require a higher level of protection. The GNSO is not the only source of rules The GNSO is the venue for setting the rules included in ICANN's contracts with the contracted parties. The registrars and registries are obligated to adhere to the terms of the contract. However, there are other bodies that can also set rules. Governments are the obvious examples, but there might be others. Suppose a registrar is beholden to three authorities, ICANN, Government 1 (G1) and Government 2 (G2). Further, let's suppose that each body imposes its own rule. The ICANN rule will be {C, O, N}, i.e. anything is ok. Let's suppose G1's rule is {O, N}, i.e. registrars are permitted but not required to make it optional. And let's suppose G2's rule is {C}, i.e. every registrar subject to this government's rules must collect this data. The combined effect of all three rules is ø, i.e. the empty set, and there is no way a registrar can be in compliance with all of them. On the other hand, if G2's rule were loosened to {C, O}, a registrar would be in compliance if its rule were O, i.e. making it optional for the registrant to supply this data. Conclusion The process of specifying the rules for collection and responses to requests has only just begun. As we noted in prior comments and in our SSAC report, the focus on which data is to be marked "public" is just a small part of the overall puzzle. The extended discussions about Natural vs Legal are motivated, at least in part, by the attempt to make as much of the registration data publicly accessible because there is not yet any credible path toward an efficient and effective access system for non-public data. Steve ________________________________ From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Volker Greimann via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Sent: Thursday, August 5, 2021 4:41 PM To: Steve Crocker <steve(a)shinkuro.com<mailto:steve@shinkuro.com>> Cc: EPDP <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] A short note on possible outcomes re Natural, Legal or Unspecified Hi Steve, I fail to see how this admittedly succinct summary of the existing options helps us move ahead the discussion as this basically only reflects the discussions we have over the past months. At this point, we are likely either at option 7 or 8, which incidentally also describe the status quo. The real issues start after making these basic definitions as there are complexities down the line following from the designations: a) In case of C or O, does that lead to partial publication based on the designation? Does it lead to forwarding the designation to the registries? How would/should the registries treat those designations received? Can they rely on them? Will they rely on them without burdening registrars with further liability and indemnification requirements? b) What happens down the road? Will agreeing to optional fields immediately lead to calls for them to be made into requirements by future work? Best, -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Aug 5, 2021 at 5:26 PM Steve Crocker via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: The attached note is a summary of the possible policies regarding Natural vs Legal vs Unspecified _______________________________________________ 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.

1 0