Dear all, Please find below the notes and action items from today’s meeting on Thursday 9 September 2021 at 13:00 UTC. Best regards, Emily, Steve and Marika Action item #1: RySG and ccNSO members on the IDN EPDP to check with their Stakeholder Group to see if there are any concerns about using the RZ-LGR for existing gTLDs (charter questions a1 and a2). Action item #2: Team to review Data and Metrics requirements in the charter and indicate whether any of the items identified are NOT necessary and/or which items are missing. Action item #3: In advance of the next meeting, in preparation for further review of A3, please review the SubPro Limited Challenge / Appeal Mechanism as well as the appealing via the integration panel in the context of the RZ-LGR. Action item #4: For those that have not done so yet, please review all the introductory materials and sign off via the google sheet (see https://docs.google.com/forms/d/e/1FAIpQLSfbXhd2L4oAb_Cn22FnjkSoDSj0K-HNcijD...). Notes – IDNs EPDP Call – 9 September 2021 Welcome & Chair Updates 1. Workplan is under development, informed by the survey taken during the last meetings. Leadership and staff support team expect to be able to circulate proposed work plan before the next meeting and will set aside time next week for review and discussion. 2. EoI for Chair is still open until September 15. For those interested, please make sure to submit your application. 3. As the team goes through the topics there may be need to collect data and metrics, to inform team’s deliberations/decisions. This could result in having to park certain items until that data is obtained. Team may need to review / discuss what further data may be necessary. ICANN org has agreed to collect any necessary data. 4. Edmon has spoken to ICANN legal and BGC chair who did not express any concern about his chairing this group until taking up his position. Furthermore, if the group is interested, Edmon could be invited back as a Board liaison to this EPDP team. EPDP Team to indicate if there is support and/or concerns about this option. Begin deliberations on Topic A: Consistent definition and technical utilization of RZ-LGR * See charter * First question is whether EPDP Team is willing to accept RZ-LGR as the authoritative source to ensure a consistent approach for reviewing current and future TLDs. For existing delegated gTLD labels, does the Team recommend using the RZ-LGR as the sole source to calculate the variant labels and disposition values? This may require some research to determine whether this would cause any potential issues for existing gTLDs. * Maybe the question should be the other way around – is there any reason NOT to use it? * See also the mapping document – SubPro and the TSG recommendations are consistent in exclusively using the RZ-LGR. * Important to consult technical teams of registries and back-end providers. Suggestion to request the opinion of registries (both gTLD and ccTLD) as previous studies were conducted by technical experts, not registries. * Note that early request for input will take place, which will focus on general questions. Need to consider whether separate targeted outreach is needed, also factoring in that registries are represented in that effort. Those members may be able to bring back any relevant perspectives or input to the group as well. * Is it worth for the staff support team to undertake a bit of data gathering to see which, if any, gTLDs would be affected? * May need to continue with a2 until data has been gathered to respond to question a1? May need further info on potential inconsistencies as the questions in the charter question are hypothetical at the moment? * Probably three data points that would need to be gathered: 1) Are existing top-level domains valid based on the RZ-LGR? 2) Are variants that are identified determined via RZ-LGR and if not how are they different, 3) When variants are allocated to the rootzone LGR, were the self-identified variant labels taken into account? * What is the process for requesting staff to gather this data? Note that the charter already identified data that might be helpful, but also noted that if additional data was needed, the group should request this. There is a form that would need to be completed to request ICANN org to gather this data, outlining what data is needed and why. If an external vendor is required, budget approval may be involved. If the data needed was already identified in the charter, Team can just confirm the data would be helpful and staff support team would action it. * Would it be helpful to identify the overall data needs, or better / easier to do this as the group goes through the charter questions? Might be better to batch them, but helpful for members and participants to go through the charter and identify any required data in advance. * Reminder, homework assignment was for members and participants to identify whether anything was omitted in the Data and Metrics requirements in the charter. Team may want to consider looking at what is in there and sign off on it so that the staff support team can go ahead with collecting the data? Preferred approach is to keep on going through the charter so that the context is clear and specific data needed can be identified and linked to specific questions, but a batch approach may be used so that the data gathering process can already start and doesn’t have to wait until all charter questions have been reviewed. * What if there are inconsistencies with existing gTLDs? Either they have to fix it or team decides that use of RZ-LGR is not required in certain circumstances. May need to look at language on self-identified variants in the applicant guidebook (see (https://newgtlds.icann.org/en/applicants/agb) (pg 1-36). * May need to consider what harm would be caused by a potential inconsistencies. * A3 – Should the appeal process that was developed by SubPro be expanded to existing TLDs (Limited Challenge / Appeal Mechanism – see chart included in the SubPro Final Report on page 329)? On what grounds would the challenge be accepted or would the applicant succeed. Reminder for Team to review the SubPro recommendations on this topic (see also mapping document). Note also process build into RZ-LGR (see https://www.icann.org/en/system/files/files/lgr-procedure-20mar13-en.pdf). Team to consider if, when and how to call upon these existing mechanisms and how these would interact.