Dear all, Please find below the notes from the meeting on Thursday, 26 May 2022 at 13:30 UTC. Best, Ariel, Emily, and Steve Notes – IDNs EPDP Call – 02 June 2022 Roll Call & SOI * None Welcome & Chair Updates * Reviewing calendar, cancelled meeting #39 and #40. Takes into account ICANN74, which includes two sessions. * During ICANN74 session – to receive an update from liaison on ccPDP4, update from small team, working session on charter questions. The sessions will be open to the public. * Reminder that room capacities are limited. Discuss charter question E7, parking lot item – evaluating variants of restricted gTLD (e.g., .brand, geographic names, etc.) * This parking lot item came from discussing the evaluation of variants of restricted gTLDs. * Connection to B5, which was about the principle for treatment of non-standard TLDs. Preliminary agreement there is that at a principle level, the variants should be considered different versions of the same string, and be bound by the same restrictions. * Only considered the topic from the perspective of new gTLDs, not existing gTLDs. Also did not discuss at the evaluation process, which is why it was added to the parking lot. * Slide 7 – Community-based TLDs * Slide 8 – Geographic Names * Slide 9 – Brand TLDs * Slide 10 – TLDs Subject to Category 1 Safeguards * Slide 11 – Questions for Discussion * 1. Bound by same eval process 2) must meet same criteria and 3) if not possible to meet criteria, how should variants be treated? * Complicated topic, so this may be a challenging conversation. * Noted that the group has agreed that the primary and variants should be considered a single application. Therefore, it may make sense that the evaluation requirements should be applied against the variants. * Some agreement from members. And further, that if a variant does not meet the requirements, it should not pass evaluation. * For a community application in particular, it may not always be possible for a community applicant to meet the stringent requirements for Community Priority Evaluation. Therefore, may be better to consider the strings as a set, not individually require each to pass CPE. * Noting the principles this group has agreed to (e.g., RZ-LGR, same-entity, atomicity, conservativeness), they should serve as a lens to look at this topic through. * The primary string may potentially be subject to the heaviest, full requirements, and perhaps variants can be subject to a lighter weight evaluation process/requirements. * Noted the expectation of updating the process flow to include preliminary recommendations, which may help understand requirements. * For geographic names, the process should take into account the different levels (1, 2, 3) for comparison purposes. As in, should the letter of support be required for level 1, 2, or 3. * Some suggestions that the letter of support should also apply to allocatable variants (requested variants). * For .brand, a TM is required. In some cases, the variants may not have TMs. We may need additional expertise for some of these questions. * There are entry conditions, evaluation conditions, and in some cases, contractual requirements. Maybe helpful to look at each. And perhaps there are general treatment for all. * Three questions to shape discussion: * Should each requested variant label be subject to the same evaluation process as the primary string? * Should the variant labels meet the same criteria as the primary string in order to pass evaluation? * In the event where it is not possible for the variant labels to meet the same criteria as the primary string, how should such variant labels be treated? * Geographic Names – the variant may not strictly meet the requirements of a geographic name as defined in the AGB. Is this possible? * For a city name in Arabic, the variant may be in Urdu, Pashto, etc. * Requiring letters of support for variants potentially protects relevant governmental entity. * Question about multiple applications for the same term, with different spellings. Or even same spelling, with multiple applicants (with adequate support). * For a city in China, it may be politically sensitive to request the traditional Chinese as a variant and say it supports/non-objects. Or vice versa, asking other regions to endorse a simplified string may be problematic where they typically use traditional Chinese. As such, this is an argument to emphasize the primary string. * There are implications here, where the variants may still be subject to objection processes. * Noted that the example above, where a government is not in a position to endorse (even if it may not actually object. * For Brands, it is similar to Geos, where the variants may not have a TM. * Suggestion to block (or disallow from application) variants that are not trademarks. No standing to treat as a brand name if it doesn’t have TM backing. * Community-based TLDs, would be relative to CPE. If not in contention, the claim to support a community is accepted as a matter of faith. * Concern about scoring system for CPE. Explanation of applicability of scoring (i.e., to award priority over others). * Question for this group is relevance of variants to CPE scoring. * What makes these conversation more difficult is that it requires a deep understanding of the process to understand implications. * Question about whether the 2012 round experienced challenging situations as it relates to variants. Clarification that variants were not allowed in 2012. AOB * None Steven Chan Senior Director, Policy Development Support & GNSO Relations Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 Email: steve.chan@icann.org<mailto:steve.chan@icann.org> Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=o7Auz997kA-HPv9PHJCjFVZw7Pgo8krw4MxfqCwBrIU&e=> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=kWw4fQPNjw2lVKy1UjTxS2F0BmjEAzaDFWNmsYywbmE&e=> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_group...>