Dear EPDP Team, Please find below the notes and action items from today’s call. The next EPDP Phase 2A call will be Tuesday, 17 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 to review the draft section 3 (see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#), focusing on the tables that have been inserted for recs #1 - #5 and use the orange tables to provide your group’s input by COB Monday, 16 August. 2. Reminder: 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. 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) a. EPDP Team Question for Community Input #5 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pcrt-Initial-Report-Recommendations_Rec5_v0.1.docx?version=1&modificationDate=1626787692000&api=v2> and Discussion Table<https://docs.google.com/document/d/18_TwHMQSnV9fWryJZJdTP0awO-FRUZ5L/edit> · #2 * Public comment from ICANN org: Should the EPDP Team decide to change its recommendation from guidance to a requirement, there may be difficulties enforcing this without full access to registration data. * In the Phase 1 Report, thought that ICANN can have access to the information * Recommendation 1, Purpose 5 covers the compliance purpose – do not think additional language is needed at this time to let compliance do their job · #4 * Input received from SSAC – further suggestions for registrars who would deploy these methods * Should incorporate additional safeguards into the recommendation * The use of this is not yet fleshed out completely – more work is needed to sort out the details. The business of email contacts has a conflation of two separate and distinct objections: contacting and correlating. These need to be disentangled and worked through separately. * Realistically, there are a lot of registrars that are already doing this via their privacy/proxy services – a registrant-based email contact. Why can this not be accepted as published since registrars are already doing this? * Do not understand the above point with respect to privacy/proxy – please clarify. * There are a number of P/P services that are affiliated with registrars that already publish an anonymized registrant-based email address and are doing so in compliance with GDPR. Because a number of registrars are doing this already, do not understand why registrant-based email publication cannot be recommended. * Rec. 5 – any suggestion that the email address is the only way to do this without also including the webform option is problematic. The recommendation on the screen is OK as is. * There is a consideration to think about changing from a “should” to a “must” – consider changing it * The pseudonymized email address should be public if it is being used by the registrar * Should be careful not to assume that just because a registrar is doing something that the behavior is lawful * Support Staff will include this recommendation in table format, and EPDP Team members may propose updated language if there are suggestions 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 * Thank you to all who have commenced review of the tables. * The first comment BC provided and the RySG provided refer to the preceding sections of the report. Suggest to park that language for now and refer to the language in the table instead. * The positions outlined in the report were mainly intended to help inform the public comment forum. Would it make sense to remove that part and instead have the minority statements reflect the differing views? · EPDP Team discussion * Recommendation 1 * It may be useful to go through the suggestions for further consideration and see if the group supports any of them. For example, can the group discuss the change from may to “encouraged”. The words matter, and the output would be the same, but prefer the use of encouraged. * Agree to take out the background commentary and keep the recommendations and report clean. * Agreement to remove the commentary. * BC proposed text: Delete this: “In their view, no evidence has been presented identifying the problems that mandatory differentiation would solve, or indeed if mandatory differentiation would solve them at all.” Delete: “Therefore, no changes are recommended, which means that the EPDP Phase 1 recommendation will remain as is.” and replace with: “Following up on Recommendation 17.3 of the EPDP’s Phase 1 Final Report, the EPDP Team was unable to resolve the Legal vs. Natural issue in Phase 2.” * Not sure that this new text is necessary – the team was asked to determine if any updates are needed to the EPDP Phase 1 recommendation – the answer is no * The way this text currently reads is that optional is the default. The report would be incomplete if the last part of this suggested is not included. There are many groups in this Team that believe there should be a change – the report would be incomplete without reference to 17.3. * There is a paradox – if we say the rec. stands as written, it is a paradox. Need to say that the issue was not resolved since Rec. 17 says – the issue will be resolved in Phase 2. To say the recommendation stands, which made a prediction that turned out to be false, is incorrect. * Do not understand what would resolve this issue. * Note that the team erred in Phase 1 – not asking for substantive change in how this will be treated but believe the historical record should be correct. * Do not think the recommendation say it would be resolved, said it would be addressed. * This is a pedantic logic problem – in Phase 1, it was not addressed and not resolved. If you say in Phase 2A, there is no change to not addressed and not resolved. * The recommendation should not be written in a way that there is consensus to that statement – it won’t actually change anything. * Noting that 17.3 is a separate part of the recommendation means that permissive differentiation is not the end state * This was a 3-part recommendation to highlight that the second part of the recommendation was the request for ICANN org to undertake a study on the topic. From the staff perspective – 1 is where we currently stand, 2 is expected to help inform further considerations, 3 – having reviewed the study and further discussions – are further changes needed – whether or not this is resolved or not is not something the Staff Support Team should opine on. * What is the issue to be resolved? The way that 17.3 is being read does not do justice to what the recommendation – 1. A rec is made. 2. There is an outstanding element to review, 3. Based on the element to be reviewed, does a change need to be made? This is resolved. * The report should accurately describe what happened – that is what this updated language is trying to get at. * Some of this discussion may need to be relegated to minority statements. There was not consensus to change 17.1 – * Groups to propose language in the Google Doc. * Consider recommending that an update is made to the EPDP Phase 1 recommendation to say that Contracted Parties are encouraged to differentiate instead of “may differentiate”. (leadership team assessment: this is a new suggestion that has not been discussed in detail. Leadership team proposes to assess at one of the upcoming meetings whether there is interest to further consider this suggestion and whether there is a likelihood that it would receive broad support) * Is anyone opposed to the inclusion of the language “encouraged to”? * Do not support this – this is an opinion and is more appropriate for a minority statement. * There are different opinions of what should be in a report and what shouldn’t * There does not appear to be support for this suggestion * Staff Support Team is aware of the concerns in the Initial Report, but thought that it was a concern over the use of the term recommendation. This has now been changed to a response to the GNSO Council. · Confirm next steps b. Recommendation #2 · Consider input provided · EPDP Team discussion * With respect to Recommendation 2, the Staff Support Team proposed edits based on the Team’s discussion. * BC Suggestions Support the trigger that would restart the EPDP once the NIS2 Directive is adopted, with the recommendation of forming a scoping team, as per the third bullet above. * The language as written does not bind the Council to a specific action. * Even if the Council adopts this, it does not create a requirement to the Council – it’s an encouragement, but the decision to form a scoping team or EPDP ultimately rests with the GNSO Council. * Appreciate the rewording and captures a compromise following the mediated discussion – important to respect GNSO processes · Confirm next steps c. Recommendation #3 (if time allows) · Consider input provided · EPDP Team discussion * We are likely to agree on the existence of an element but not the use of the element. If we consider it as a package, it’s likely that most cannot support. * There is a technical RDAP working group, and that would be the group that would work on this, provided they are giving appropriate direction from a policy recommendation. Is there sufficient language in here to allow them to take action on this? * In Rec. 4, there is language that overlaps slightly with Rec. 3. The standardized element discussed in Rec. 4 is more workable and directional. Still working on a proposal for new language and will share with the group as soon as there is something that there is agreement on. * Do not believe the kind element is a good fit. · Confirm next steps - If you believe there should be a standardized data element, please explain the benefits. What would the benefit be for the specific proposal that is being considered. - Continue to review the tables, factoring in the discussion today. By working through the Google Doc, hope the group can find common areas of agreement. Staff Support has also worked on the table for rec. 4 – have seen some suggestions on the list – will post them there. - Support Staff Team will post the table from Rec. 5 – we do not have suggestions based on the discussion today, but please continue to post proposals. 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 1. Please continue to review the draft section 3 (see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#), focusing on the tables that have been inserted for recs #1 - #5 and use the orange tables to provide your group’s input by COB Monday, 16 August. 2. Reminder: 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. c. Confirm questions for ICANN Org, if any