Dear EPDP Team, Please find below the notes and action items from today’s meeting. The next EPDP Phase 2A meeting will be Thursday, 5 August at 14:00 UTC. Best regards, Marika, Berry, and Caitlin 🚨‼️ 📣 Action Items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdVdrRIdrw/edit#gid=0> 📣 ‼️🚨 Please find a link to outstanding action items: https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV.... EPDP Phase 2A - Meeting #32 Proposed Agenda Thursday 29 July 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) a. Status of continuation of mediated conversations - There are three conversations scheduled for next week around Council monitoring and uncertainty. - The group has done a good job trying to understand the nuances of others’ points of view. There are differences in the way terms are defined. There has been acknowledgement from groups that they may not have done the best job in explaining positions. - Hoping to engage in more specific conversations around the benefits of changing the status quo. 3. Initial Report Public Comment Review (75 minutes) a. EPDP Team Question for Community Input #1 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pcrt-Initial-Report-Recommendations_Rec1_v0.1.docx?version=1&modificationDate=1626782536000&api=v2> and Discussion Table<https://docs.google.com/document/d/17LQV0ELcmzgvUyUSxLcekNf32V_pa2Hi/edit> b. Review items flagged for further discussion - We will begin by focusing on comments that were received by the deadline. If time allows, we will go through the comments received after the deadline. * Prelim. Rec. 1. – No changes are recommended at this time to the Phase 1 rec. on the differentiation of legal and natural persons. * The Team was asked to review the table and see if any of the comments need to be further considered by the group. · Item #6 * The left-hand side shows the summarized version of the comment. For the purpose of this table, an abbreviated comment is provided. By now, all EPDP Team members are expected to have read all comments in full. * The comment flagged is from ICANN org re: what language is expected to be included for purposes of implementation. * Feedback from RrSG – the EPDP Team should consider what policy language is required. Need to make sure that whatever is settled on is clear to an implementation team. * A recommendation saying that no change is recommended is slightly obtuse – this is not something that needs to be implemented, but merely noted. * Do not like how this recommendation is worded as there is no agreement that no changes should be made. It’s likely the Team will not get to consensus on this, and having a recommendation that says no change is recommended is not correct as some groups do recommend a change. * At the time of publication of the Initial Report, there was not consensus that a change was needed. * There is no consensus in relation to this recommendation. Some groups do not agree that no changes are not required. Also, some groups do believe that future work is required. Perhaps the recommendation could be changed to CPs are encouraged but not obligated. * Could say the group discussed this and there is no agreement * The Phase 1 recommendation is a three-part recommendation. The answer needs to be that the EPDP Team cannot resolve and determine the legal v. natural issue based on the information received at this time – this accurately explains what the Team has been done. * It is a well-known fact that if there is no consensus, there is no policy. The only thing coming out of Phase 1 is that CPs would be allowed but not required to differentiate. Need to accept the fact that we cannot come to agreement on this and move on. Proposed change to wording: The EPDP Team could not reach a consensus to change the recommendation, therefore no change will be made. * The recommendation being discussed now is a response to instruction (i) from the Council: whether any updates are required (“Registrars and Registry Operators are permitted to differentiate between registrations of legal and natural persons, but are not obligated to do so”. It does not make sense to have a recommendation that does not make a recommendation. * Need to look at Rec. 17 as a whole * The instructions from the Council were not within the Charter, so the Team is still perfectly in its charter to resolve the legal v. natural issue. Would like to specifically add – the team cannot resolve the issue of legal v. natural at this time. * Item #10 * There are ongoing discussions around benefits of differentiation – perhaps those conversations conclude before we further discuss this issue. c. EPDP Team Question for Community Input #2 – see PCRT<https://community.icann.org/download/attachments/169444210/gnso-EPDP-P2A-pcrt-Initial-Report-Recommendations_Rec2_v0.1.docx?version=1&modificationDate=1626783075000&api=v2> and Discussion Table<https://docs.google.com/document/d/114D2KDJnU05rjzYyXXFY2lQ4tXQNRiAj/edit> This recommendation relates to the GNSO Council monitoring legislative changes. Is this recommendation necessary? · Item #5 * Registrar Team understands that ICANN already tracks legislative developments – do not think the GNSO Council should have its purview expanded in this way. ICANN org should continue to monitor and relevant changes could be flagged to the community. * Need to consider whether this is an ICANN org function that is already being carried out – this may be above and beyond the remit of the GNSO Council. * ICANN org has a role in tracking legislative and regulatory developments around the world. With the advent of GDPR, it became clear that early warning of regulatory developments that may affect global policy is important – ICANN org clearly has a role. A possible recommendation could be that the Council engage with or check in with ICANN org on the monitoring of these developments. There could be future developments. * The language in NIS2 is relevant to this Team’s work – it creates a stronger legal basis for that this group is doing in policy development. The recommendation should not be monitored – the language should be that the EPDP Team be reengaged when the NIS2 is adopted. * Is there a trigger or date the team should be considering? There is no downside in communicating to the Council or community that there could be future regulatory (or otherwise) impacts that need to be considered. * There is no harm in giving a reminder, but that does not mean a recommendation is necessary for this. * The only reason these recommendations are showing up now is to immediately implement laws that curb the impact of the GDPR. Cannot start introducing deliberations in the GNSO Council the laws that certain stakeholders like and ignore others. * The downside to this prelim. rec is that this process is being prolonged unnecessarily and allowing groups that were unhappy with the results to try to keep it going. Maybe these groups will be successful in pressuring the EC to get what they want. If a new law comes along that requires a change in ICANN policy, then the GNSO will start a new policy process. Need to be very concerned with efforts that allow other groups to regulate what ICANN does and tilt the scales of the multi-stakeholder process. * This recommendation does not keep the EPDP2A work open, alive, or in a stand-by mode. EPDP2A effort will conclude, but based on the conversations had over the last few months, there are potential regulatory impacts to these conversations, and an acknowledgement of that to the Council is not out of bounds. * NIS2 is very specific to this work, so this should be specifically called out – propose restarting EPDP once NIS2 is adopted b/c would not want to start all over again * The GDPR has been applied correctly to avoid liability · Item #6 · Item #7 * Does this mean the action if approved would be for the Council to approve or not approve and it would end there? * This will depend on how the Council and Board treat the recommendations. Generally, the Council will pass on the whole set of recommendations, and generally the Board will vote on the whole set of recommendations. If a recommendation is directed to the Council, the Council will be expected to deal with this. A recommendation of this nature will not result in future implementation directed to ICANN org. * Do not see monitoring international legal changes to be part of the qualifications for GNSO Councilors – this should be tasked to ICANN legal. This rec, if passed, would assign work to the Council that it is not equipped to take on. · Item #10 * RrSG provided a very specific suggestion regarding the ICANN org role- standardized regulatory impact assessment. · Item #11 * Existing processes already allow the GNSO to enact on new developments · Item #13 * This is an attempt to make sure this gets done. * In terms of process, if the GNSO is asked to do something and the GNSO votes on it, that is the onus to get them to do it. d. Looking ahead at next assignments: * There are still four documents remaining that require review. Looking ahead to the next meeting, please at least complete tables for Questions 3 and 4, and if possible, 5 and 6 and the additional discussions table. * If you believe a comment requires further review, providing specific language to address the concern is very helpful. * Feedback: Are we now finished with Rec. 1? * As a general statement, we need to take on the conversations of the group today and factor in next steps. * That question is ultimately for the group. Staff created a tool to assist in the review, but it’s ultimately up for the group to consider. If the group thinks there is more to consider, please flag. From staff’s perspective, this concludes the review of 1 and 2, but it is up to the group to consider what, if anything, needs to be additionally considered. * If, during offline conversations, new recommendations or suggestions emerge that can reach consensus, the group will discuss it. * The ALAC spent a lot of time on its comment – it would be nice if the words used were mentioned in the discussion. * The homework assignment is for groups to flag comments that require further discussion – if a comment was not flagged, it was not put on the agenda. If there is a comment to come back to during the next call, but please flag the relevant comments by the deadline. * Not sure how these items are getting resolved. * From staff’s perspective, we are following a similar approach to Phase 1 and Phase 2. Staff can write up different proposals and go back to the Initial Report – how will these be reflected in the Final Report – it could be that making specific suggestions for the group to consider. The focus should be: what has this comment added to the conversation or what new suggestion is added that the group needs to consider? * The public comment asked for new information. * Was not notified soon enough of the homework assignment – will go back and include comments on questions 1 and 2 · EPDP Team Question for Community Input #3 · EPDP Team Question for Community Input #4 · EPDP Team Question for Community Input #5 · Additional Comments 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #33 Thursday 5 August at 14.00 UTC (tentative) b. Confirm action items - Action Item: EPDP team to review the public comments<https://community.icann.org/pages/viewpage.action?pageId=169444210> received for Preliminary Recommendations 3 and 4. Groups to use the Discussion Table Google Docs to indicate if new ideas are presented that warrant further discussion by the full team by COB Wednesday, 4 August. If EPDP Members believe a recommendation should be amended based on a public comment, EPDP Team members are strongly encouraged to provide proposed updates in the Google docs by COB Wednesday, 4 August. Groups are also encouraged to commence their review of 5, 6, and the additional comments discussion table. c. Confirm questions for ICANN Org, if any