Hi Justine, Thank you for your email and for taking the time to review the recent updates we made to Topic 24: String Similarity Evaluations based on IRT input. While we believe the existing language is clear and sufficiently addressed across multiple sections (including IDNs, the Blocked and Reserved Names section, and Section 2.1.8 of Applicant Journey) we’ve made a few updates for further reinforcement: Two additional footnotes in the String Similarity section (Footnotes 12 and 16), stating: “Reserved Names, as defined in [Section X: Blocked and Reserved Names], are not subject to string similarity analysis. For additional constraints on Reserved Names, see [Section X: IDNs, Sub-section 3.5].” A new row in the Table on pages 9-10 of the String Similarity section explicitly referencing “Reserved Names” with an update to the “same-as” and “variant-of” columns, and referencing the exception process language in the Blocked & Reserved Names section. Since the Applicant Journey section already aligns with the guidance in the IDNs and Blocked and Reserved Names sections, we don’t see a need for further updates there. As you mentioned, these changes should help clarify the distinction between blocked and reserved names. Additionally, Sub-section 3.5 of the IDN module includes language on Reserved Names that is relevant to this discussion. Once we finalize these updates and complete internal review, we’ll circulate the revised language on the IRT mailing list. Please let us know if you have any concerns or further suggestions. As always, we appreciate your thoughtful review! Best, Michael From: Justine Chew <justine.chew.icann@gmail.com> Date: Saturday, March 22, 2025 at 12:23 AM To: Lars Hoffmann <lars.hoffmann@icann.org>, Elisa Busetto <elisa.busetto@icann.org>, Michael Karakash <michael.karakash@icann.org>, Sarmad Hussain <sarmad.hussain@icann.org> Cc: SubPro IRT <subpro-irt@icann.org> Subject: [Ext] Treatment of Reserved Names under Topic 24: String Similarity Evaluations Dear Lars, Elise, Michael and Sarmad, At the SubPro IRT Meeting #121<https://community.icann.org/x/NYDKGQ> during ICANN82, I had requested for the opportunity to review the part of the discussion where a change was proposed in respect of Topic 24: String Similarity Evaluations. Specifically, in Section 1.2 Scope of String Similarity Evaluation on page 3 of Proposed AGB Language_String Similarity Evaluation_v06_2025-03-06.pdf (linked on the SubPro IRT Meeting #121<https://community.icann.org/x/NYDKGQ> wiki page) it was proposed that the reference to "Reserved Names" be changed to "Blocked Names". While I acknowledge that a change is warranted given ICANN org's effort to now re-classify (a) what was known as Reserved Names (in the 2012 AGB) to Blocked Names (in the NR AGB) and (b) what was known as "Strings Ineligible for Delegation (in the 2012 AGB) to Reserved Names (in the NR AGB), I would like to pose a few questions for resolution with the following context. Context 1. As detailed in the Phase 1 Final Report on the Internationalized Domain Names Expedited Policy Development Process [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/policy...> which was put out for public comment by the Board<https://www.icann.org/ru/public-comment/proceeding/phase-1-final-report-of-t...>, the EPDP working group did consider the treatment for (the 2012) Reserved Names separately to Strings Ineligible for Delegation, which resulted in Final Recommendations 3.18, 3.19, 3.20 and 3.21 at page 51. For present purposes, I would like to draw specific attention to: "Final Recommendation 3.20: The list of Strings Ineligible for Delegation must not be expanded to include variant labels."; and "Final Recommendation 3.21: Only the protected organizations on the list of Strings Ineligible for Delegation are allowed to apply for the allocatable variant label(s) of their protected string(s) at the top-level. Consistent with Final Recommendation 3.1, an application for an allocatable variant label of a protected string cannot precede an application for the protected string, which serves as the primary label for generating the variant label." And as a reminder, going forward, "Strings Ineligible for Delegation" are known as "Reserved Names". 2. In Section 2.1.8 Reserved Name Identification on page 6 of Applicant Journey (related to Topic 5: Application Submission Limits and Topic 16: Application Submission Period) [itp.cdn.icann.org]<https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/policy-develop...> currently out for public comment through the Fourth Proceeding for Proposed Language for Draft Sections of Next Round AGB<https://www.icann.org/en/public-comment/proceeding/fourth-proceeding-for-pro...>, there is mention of treatment of Reserved Names. For convenience, I replicate the section below and highlighted in blue the portion of interest. "2.1.8 Reserved Name Identification Certain strings, known as “Reserved Names”, are available as gTLD strings at the top level only through a validation process. These names are designated for specific entities, which are the only ones eligible to apply for them. ICANN org maintains a list of Reserved Names, compiled from various sources, and requires relevant entities to provide appropriate documentation, as outlined in the [Blocked and Reserved Names] section. During application drafting, the system will automatically verify whether the selected string and allocatable variants (where applicable) are a Reserved Name. If there is a positive match, the applicant will be requested to upload supporting documentation proving they are the entity for which the name is reserved, as described in [Reserved Name Identification]." This seems to suggests that each applied-for string and its allocatable variants has to be compared with the list of Reserved Names and exact matches would not be allowed unless the applicant can demonstrate it is the entity for which the name is reserved. And we know that the list of Reserved Names are established separately through an examination of treaties and statutes across multiple jurisdictions. Questions Q1. Coming back to Section 1.2 Scope of String Similarity Evaluation on page 3 of Proposed AGB Language_String Similarity Evaluation_v06_2025-03-06.pdf, in apart from changing "Reserved Names" to "Blocked Names", should we not also make mention of the treatment of Reserved Names? If not, why? Q2. If we don't make mention per Q1, is section 2.1.8 of the Application Journey chapter then sufficiently clear to reconcile the treatment of Blocked Names versus the treatment of Reserved Names as presented in the Application Journey Chapter and in the chapter on String Similarity Evaluation? I suspect not. Q3. Could ICANN org propose a way to rectify any shortcomings I have attempted to highlight here, within the 2 chapters of String Similarity Evaluations and Applicant Journey, and elsewhere in the NR AGB as needed? Thank you, Justine