Dear all, Please find below the notes from today’s meeting on Thursday, 21 October 2021 at 13:00 UTC. Best regards, Ariel, Steve, and Emily Action Items: Action Item #1: Leadership Team to follow up with WG regarding transition to 90-minute meetings in November. Notes – IDNs EPDP Call – 21 October 2021 Welcome & Chair Updates * Thanks to Anil and Justine for volunteering for the Vice Chair role. The election has been completed and Justine has been elected as Vice Chair. * Anil was appointed as Liaison from the ccPDP4. * Letter to ICANN Board to GNSO Council: Council had asked for a deferral on the implementation of IDN Guidelines v4. The Board responded asking the GNSO Council which specific items in the Guidelines the GNSO believes need to be deferred pending policy development. * If the Council wants input from the EPDP on the response to the Board, next steps will be discussed: https://mm.icann.org/pipermail/council/2021-October/025100.html Introduction to working documents for this group * Wiki page for IDNs EPDP working documents: https://community.icann.org/x/XwyHCg * One working document has been created for the charter questions in each topic, managed in Google docs with archived versions in MS Word/Excel * Staff will maintain the documents, with the goal of capturing main agreements/takeaways to support development of draft responses to charter questions and draft recommendations * Members have permission to add comments in “suggestion mode” (redline) * There is an additional working document containing Action Items coming out of WG meetings Brief review of deliberations on charter question a3 & review of the challenge mechanism recommended by SubPro Staff presentation on the Limited Challenge/Appeal Mechanism (slides<https://community.icann.org/download/attachments/174457008/EPDP%20on%20IDNs%...>) * Background on the Limited Challenge/Appeal Mechanism – SubPro deliberations and community inputs * Types of challenges of evaluation outcomes & types of appeals of formal objections decisions * Principles: Narrow scope (in most cases, subject to “clearly erroneous” standard); Arbiter is generally the same panel/entity but different individuals; The party that initiates the challenge is generally responsible for costs & for appeals it is the losing party * For each challenge/appeal type, SubPro looked at the outcome that might warrant challenge, potential affected parties, parties with standing, arbiter of the challenge, likely result of a successful challenge, and party bearing the cost * Annex on page 329 of the SubPro Final Report summarizes the details of each potential challenge/appeal. It is considered implementation guidance: https://mm.icann.org/pipermail/council/2021-October/025100.html Discussion * Question: Why did SubPro recommend that challenger bears the cost of a challenge? * Response: The alternative is that the panel pays in certain cases, and this may deter potential vendors from participating. SubPro did not want to make the assumption that vendor or ICANN org could bear the cost, although it is possible in implementation that ICANN org will be able to negotiate contracts to this end. * Clarification: The job of this group is to determine the applicability of processes recommended by SubPro for cases involving evaluation using RZ-LGR. This does not mean that this group will come to the same conclusion. * Potential outcomes that might warrant challenge: Applied-for gTLD is found invalid; Applied-for variant gTLD is found NOT allocatable; Applied-for variant gTLD is found NOT to be a blocked variant * Comment: Regarding the case of Applied-for gTLD is found invalid -- The online tool is an application of the RZ-LGR. An issue with the tool itself could be a potential use case for a challenge. Therefore there are two possibilities: encoding/transition error OR fundamental error with the RZ-LGR * Question: When the RZ-LGR panel finalizes its work, what is the authoritative document that comes out of the GP? * Response: All proposals are integrated into a single file by the Integration Panel. That is the authoritative XML file. But the tool allows it to be used in a user-friendly way. The online tool is an implementation of the RZ-LGR. There is a possibility of human error in the implementation, which is a potential case for a challenge. * Comment: The broader language community does not get to test the outcome of the work of the GP. Is there a way that we could introduce testing of the outputs of the Integration Panel? * Response: This may be out of scope for this EPDP. * Response: There is testing done by IP and GP. GPs are asked by the IP to develop test cases. These are included in a test file that the GP provides to the IP. The IP does three levels of testing: 1. The test label file is tested; 2. There is testing against the gTLDs that have been delegated; 3. Word lists that are available online for different languages are run through the XML and see if there are rules that are causing too many to be invalided. These are sent back to the GP for review. There is an ongoing discussion between the IP and GP throughout the process. * Comment: Because there are potentially different sources of errors, some challenges, such as an error with the tool, could potentially be handled within the ICANN processes. Others, for example that require a change to the RZ-LGR, might require additional investigation. The applicants should not need to understand processes around development and amendment of RZ-LGR to go through the application process. * Comment: If the policy is that strings need to comply with RZ-LGR, applicants must be aware of these rules. * Comment: If this challenge process requesting an update to the RZ-LGR can happen at any time outside of the application process, maybe we should call it something else, for example a “change request.” * Comment: For the RZ-LGR challenge, the DNS Stability Panel is doing the evaluation, but the GP is potentially handling the appeal. This is different from many of the other challenge processes outlined in SubPro where the same entity that conducted the evaluation will also handle the challenge. * Suggestion: A single version of the RZ-LGR is used during the application window. Perhaps all challenges should be taken at the same time to the Panel. Handling cases one-by-one might result in a chaotic outcome as each update may impact other parts of the RZ-LGR. * Comment: There should be a challenge process that can trigger a review of the RZ-LGR outside of the new gTLD process. * Comment: We can’t set up requirements for the RZ-LGR process that only serve New gTLD processes. ccTLDs also utilize the RZ-LGR and this needs to be taken into consideration. * Next steps: Unpack circumstances in which a challenge may be appropriate. Potential issue: what goes on with the development of the RZ-LGR and what goes on in the application process. AOB * IDNs EPDP ICANN72 session: Tuesday 26 October at 23:30 UTC * Working Group to transition to 90-minute meetings in at some point in November.