Dear EPDP Team, Please find below the notes and action items from today’s meeting. Best regards, Berry, Marika, and Caitlin ‼️💥 📣 🛎 🚨 Action Items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV...> 💥 📣 🛎 🚨 ‼️ Please find a link to outstanding action items: https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdV... As a reminder, please provide suggested edits (if any) to the proposed community questions via this google form (https://docs.google.com/document/d/195LOzu25ZspprM5b4ECqwb46gLRfP7Ez/edit) by COB today, 1 June. EPDP Phase 2A - Meeting #26 Proposed Agenda Tuesday 1 June 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) a. Latest version of Initial Report & expected next steps, including potentially unresolved items 3. Initial Report Questions for Community Input (30 minutes) a. Consider input / suggestions received in advance of the meeting * Questions re: Rec. 3 (standardized data element) * Do not understand this question as it seems the group agrees to this. Not sure what value there is in posing the question this way. * There was a general recognition that standardization would be good, but there were concerns about requirements around using the data element * In terms of what any registrar does internally is entirely up to them. The only issue is if this will be communicated to someone else. If you communicate it, there should be a standard way of doing it. * Under the impression that where there was disagreement was whether a standardized data element must be used if a CP chooses to differentiate. Was not under the impression about whether a standardized data element should even be available. Could go right to Q3 and skip the first two questions. * We will receive a diverse spread of answers to open-ended questions. The new field was pretty well decided. * Standardized data elements are most useful when communicating with others. Recommend removing the first clause of Q3 – [must CPs use a standardized data element when communicating with all parties?] * RySG has operational concerns and scope concerns. While having the data element available to registrars – this would make it an active requirement for registries. It becomes a mandatory build on the Ry end, even if they are not going to differentiate. Q2 and Q3 – looking here for input so that the Team can discuss it further. RySG is good to go if it’s clear that these issues are still being discussed. * The field is optional. For those who are not going to differentiate are not going to use it. However, if they do choose to differentiate in the future, this makes it easier to do in the future. There are already changes to the RDDS anyway. * If we are in the RDDS making changes already, this is the time to make changes. In the case of Phase 1, where someone can supply consent to publish, we agreed that consent to publish would not be transferred between contracted parties. It seems to be the same concept here. One CP has determined that this party is a legal person and that doesn’t need to be transferred to other parties. This is a field b/w CPs and requestors, and if anyone doesn’t want to do it, they don’t have to do it. * RySG is fine with including these questions. Having the note that this is still open to discussion and look forward to receiving feedback from the community. * There does not appear to be general agreement on this data element. Recommend keeping the questions as is. * With respect to Q3 as drafted is necessary or appropriate – “is it sufficient” rather than how useful is it? * Agree this wording is awkward * Not appropriate to ask the community to opine on legal guidance because do not see what purpose it serves * Do not think what we were trying to do is get the community to opine on substantive legal guidance; this was about concerns about, functionally speaking, the way the excerpts of the legal guidance are included is the question. * Providing a large block of text isn’t very valuable either, providing footnotes would be helpful. Are there legal and regulatory considerations that should inform Rys and Rrs in differentiating? If we remove all references, there should be a comment about how we removed references. * Eliminate Q3 – or replace it. Helpful to provide a framework where commenters can comment about emerging laws and regulations so that when Staff receives the public input, it knows how organize it. * Take an action item for work offline for members who would like to update questions in Section 4 – treatment of Q3. * Feasibility questions – * What is Q2 referring to? (answer: guidance) * Q2 is unnecessary * Q3 is unhelpful, as written. Should ask the question in a way that can be responded to. The words “how useful” will not assist in getting valuable feedback. * Do not think we should ask for the public’s assessment of the legal guidance. Do think it’s a useful question if there is additional information that the public thinks would be useful to consider as well. * Agreement to strike Q3 in this section and in the previous section * Action for Sarah and Laureen for outstanding item 2 b. Confirm next steps 4. Public Comment Forum (15 minutes) a. With focus being on questions for input, should a form approach be used to encourage input on these questions as well as facilitate review of input received? * Google form is not possible for some companies * A word template could be helpful b. Confirm next steps 5. ICANN71 (15 minutes) a. Session has been scheduled for Wednesday 16 June at 14.30 UTC, focused on presenting findings and soliciting community input. Chair expected to present. EPDP Team members encouraged to attend and participate – with focus on how to encourage submissions of new information / ideas that will help inform the EPDP Team’s deliberations. b. Questions / Comments 6. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #27 Thursday 3 June at 14.00 UTC (if necessary) b. Confirm action items c. Confirm questions for ICANN Org, if any