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/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdVdrRIdrw/edit#gid=0>⚠️ 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#he...>, 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-pcr...> 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-pcr...> 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-pcr...> 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#he...>, 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