Dear all, Please find below the notes and action items from today’s meeting on Thursday, 6 July 2023 at 12:00 UTC. Kind regards, Ariel, Emily, and Steve Notes and Action Items - IDNs EPDP Call – 6 July 2023 Action Items Action Item 1: Leadership will inform Council of the comments and seek their guidance on whether or not the issue should be considered and if so, how. Action Item 2: Revise language in a manner consistent with the comments and discussion. Staff to make suggested edits to Rec 1.1. Action Item 3: Leverage RySG comment to modify Rec 2.1 and remove the asterisk language (globally). Action Item 4: Add a note in the introductory section to recommend that readers to review the glossary prior to reading recommendations. Action Item 5: Come back to Rec 3.4 during a future meeting and look at the second part of the ICANN Org comment in particular. Action Item 6: EPDP Team to review the comments received prior to the next meeting, to help facilitate further review in the coming weeks Notes Roll Call and SOI Updates * None Welcome and Chair Updates * Thanks to those that completed the midpoint WG survey. The results are intended for the Council, but seeking to share with the EPDP Team as well. * Reminder that there is also a survey for scheduling the F2F session. Start reviewing Phase 1 Initial Report public comments * Starting review with .quebec – leadership view is that they are in the scope of the charter. Unless there are objections, the intention of leadership is to inform Council and ask them for suggestions on how to approach the topic, or not. * Background: .quebec is already registered but the registry has always been interested in registering .québec. However, because this group is recommending RZ-LGR as the sole source and the Latin GP does not recognize the two strings as variants. The registry could apply for .québec but it would be highly likely to be found as confusingly similar and would not be allowed to proceed. The registry is looking for some form of an exception procedure to allow confusingly similar strings if they adhere to a same entity principle. * Nacho Amadoz helped develop the comment and it has been a longtime issue for Core. Agreement that elevating to the Council is the right approach. * One small addition: there is a possibility for exceptions in the ccTLD world and can maybe be leveraged. * No objections to reaching out to Council for guidance. Action Item: Leadership will inform Council of the comments and seek their guidance on whether or not the issue should be considered and if so, how. * Having made good progress with Phase 2, we will be starting review of Phase 1 public comments, using this review tool: https://docs.google.com/spreadsheets/d/13s_6L-bRx6fsII34QR-65lbqjmqFU8GH2_b8... * However, since there are a handful of open items, we do not want to pause all Phase 2 work for several months. * Another note is that leadership is reviewing the timeline since the IDNs EPDP is a part of the critical path for the SubPro launch. Will come back to the group before informing the Council. * Reviewing Snapshot tab: there are links to each of the recommendation tabs. There is a summary of which recommendations have significant concerns or objections raised. However, this is a combination of self-assessment from the commenter, but also an initial staff designation where the commenters did not designate. * Reviewing tab for Rec 1.1: Parking the .quebec comment for now, as noted above. Suggestions for non-substantive wording changes from ALAC, to substitute 2012 round gTLDs for ALL gTLDs. ICANN org comment also had concerns about existing gTLDs from the 2012 round. The combination of the recommendation and the asterisk are conflicting – should not be limited to just IDN gTLDs. Suggestion is therefore to not constrain to just the 2012 round and existing IDN gTLDs. * Reminder that column D and E should be completed as the EPDP Team reviews the comments. * There may also be an issue using the word “delegated” since 2012 applications may not yet be delegated. * Support from RySG. Overall global comment is to apply the RZ-LGR globally, not just carve out existing gTLDs. * Suggestion to also remove “existing” which would essentially make it a global requirement. But this may overlap with the SubPro recommendation. * Reminder for why this recommendation is so specific: “existing delegated gTLDs from the 2012 round” is to differentiate from the SubPro recommendation. Suggestion to use allocated instead of delegated. * Agreement to revise the language with specifics to be determined. * There is an asterisk to highlight the 8 recommendations that only apply to existing IDN gTLDs. The purpose of having this footnote is because only existing Arabic and Chinese gTLDs have allocatable variants. The footnote may be overly limiting since the RZ-LGR can change over time. Suggestion to remove the “footnote”. For any qualifying information, it should not be captured as a footnote – it should be incorporated into the recommendation itself. Note that the RZ-LGR identifies allocatable AND blocked, so it can be applicable to all, not just IDNs. * Question about why the asterisk language was included in the first place – because the recommendation was drafted in consideration of allocatable variants from the 2012 round. * RrSG said they support all recommendations but it is not captured in 1.1. It is only captured in the overall comments on the last tab. Action Item: Revise language in a manner consistent with the comments and discussion. Staff to make suggested edits to Rec 1.1. Action Item: Staff to replicate the RrSG for every recommendation as Support Recommendation as Written * Reviewing tab for Rec 2.1: Recommended non-substantive changes from the RySG, ALAC, and ICANN org. Suggestion to remove “IDN”, “from the 2012 round”, and “of the existing IDN gTLD” to make less limiting. This is similar to the comment to Rec 1.1. The ALAC has a specific suggestion which is generally in line with the RySG comment. ICANN org notes similar concern about the asterisk language and identifies similar concerns as RySG and ALAC. Action Item: Leverage RySG comment to modify Rec 2.1 and remove the asterisk language (globally). * Noted that ICANN org did not use the guided form. Staff has applied the comments where it believes they belong. Part of why the org did not designate its comments was because it is not appropriate for the org to “support” a recommendation. * Reviewing tab for Rec 3.1: Suggestion to suggest that readers review the glossary prior to reading the recommendations. It does not make sense to add to the recommendation language itself. Perhaps it makes more sense to add to the introductory text. Action Item: Add a note in the introductory section to recommend that readers to review the glossary prior to reading recommendations. * Reviewing tab for Rec 3.2: only support. * Reviewing tab for Rec 3.3: likely a global change to remove “IDN” from all recommendations. Suggestion from Org is to not apply extra emphasis on the immediate next round. It seems that the recommendation language itself is already clear. * Removing “IDN” might make sense since as noted, the RZ-LGR can theoretically change that may allow Latin scripts to have allocatable variants. * Before making changes, need to carefully consider the charter question and rationale. There may be reasons that recommendations are so specific. * It MAY apply to 3.3 to adjust “IDN gTLDs from the 2012 round”. Park it for now to make sure that changes are done in a purposeful way. * Reviewing tab for Rec 3.4: The second part of the ICANN org comment is substantive, asking whether adding, removing, or modifying variants should be possible during the application process. Question about string similarity – does a similar variant cause the entire set to be placed in a contention set (against another applied-for gTLD) or knocked out (existing gTLD)? The hybrid model says that string similarity for allocatable strings can result in string contention or a string being knocked out. * The ICANN org comment does not sound like it is limited to just considering the cases of string contention. It does make reference to SubPro Rec 20.8 which just applies to .Brand strings. * The recommendation as worded makes it sound like the applicant can only apply for variants in the next immediate round. However, applicants may apply for additional variants in a subsequent round. Unclear why this is problematic. * The terminology "must be required" might be what Org sees as problematic. Adjusting it to something like "must be allowed to submit..." could potentially address the Org comment. * The suggestion was to require applicants to not submit multiple applications. * Can perhaps address in implementation guidance. * As a reminder for 3.4 and in relation to string similarity, the hybrid model considers allocatable strings that are NOT applied for, so the impact of the string changes may not be severe. Action Item: Come back to Rec 3.4 during a future meeting and look at the second part of the ICANN Org comment in particular. * Reviewing tab for Rec 3.5: Suggestion from RySG is to not just limit to future rounds. Need to assess whether the limitation to IDN gTLDs is appropriate. Comment from ICANN org should be read in conjunction with input to IG 3.6. Rec 3.5 sounds like it is unscored whereas 3.6 makes it sound like it should be scored. This seems inconsistent. * If “IDN” is to be maintained, then 2012 round reference may not be needed, since there were no IDNs before. * Applying change from RySG removes ambiguity and does not seem to change the intent. Remove “IDN” and “from the 2012 round”, even if the suggestion to remove “IDN” is not captured in the comment. * Reviewing tab for IG 3.6: This is directly connected to Rec 3.5 and is potentially the source of inconsistency from the ICANN org perspective. * Perhaps changing IG to no longer refer to criteria may make it less likely to be interpreted to being a scored question. * Why have an unscored question? * Also unclear who the target is for developing criteria. Presumably this would be completed by ICANN org and the IRT. * The purpose of this recommendation was to help limit the number of applied-for allocatable variants. This was supposed to be seen in conjunction of having not hard limit on variants. * Approach could be to answer Org questions or “disregard” if the EPDP Team does not see it as critical. * Reviewing tab for Rec 3.7: Similar comments from RySG. ICANN org is pointing out that the questions may change substantively since IDN variants were not allowed previously, so the rationale may not be accurate * Removing “IDN” may be challenging. May need to capture assumptions since there are complex nuances. For instance, an IDN can have allocatable ASCII variants, but currently, ASCII gTLDs do not have allocatable variants. It’s a good reminder that the premise of this EPDP is generally about IDNs and variants. Trying to future proof the recommendations may be confusing or dilute the purpose of this EPDP. Action Item: EPDP Team to review the comments received prior to the next meeting, to help facilitate further review in the coming weeks 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...>