Re: String Similarity Assessment of Reserved Names
Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 Follow us on LinkedIn and YouTube From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com
Hello all, Thank you for your questions and comments regarding the String Similarity Assessment of Reserved Names presented during the last IRT call on 4 September. Based on your comments on-list, we have updated the paper to include the relevant Board-adopted recommendations from the PDP Protection of IGO and INGO Identifiers in All gTLDs in the Annex. You can find the updated paper on the wiki page here: https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/460783617/2025-.... The original paper is labeled “Version 1 (5 Sept), and the updated paper is labeled “Version 2 (10 Sept). Looking forward to the discussion tomorrow. Thank you! Best, Michael From: "Pruis, Elaine via SubPro-IRT" <subpro-irt@icann.org> Reply-To: "Pruis, Elaine" <epruis@verisign.com> Date: Wednesday, September 10, 2025 at 8:04 AM To: "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: * In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. * Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: * New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. * String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 [cid:image001.png@01DC226D.D22C71E0] <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...> Follow us on LinkedIn<https://secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AATbHIImNYURcw3_FWuLzTmIZMWug...> and YouTube<https://secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgz...> From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw<https://secure-web.cisco.com/19p0LT0iwpzzYckVQeX0vaIIYWWoQf_NsfxaSjXc-wqWLyDH2PHlguPr5qsEmQyvswd67Mr153kjHFzfXc6XqQFRPmKLVfBI2tyaGxfxQlkPckRrnc67XoB4kveehA22K7WYUe6nwyNK6nI-tA8ak3KN9j9VAIkt0W-gA6LfTeXbKL0P-cFfG38ei-Y3wH54hAkGELmqeosUimHNB_ygFvaiP_geRylKgR1uqpQalOIJSdY3ya26z0qvoJyEQZt9ZA5IsypoAtrFAjVvSjqhnAZvZgNH1EKm06KKQeL5YMfg/https%3A%2F%2Ficann-community.atlassian.net%2Fwiki%2Fx%2FAQB3Gw> Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com<https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...>
Thank you for the additional background. Call me crazy but reading all the relevant policy together, it appears to me that a string that is too similar to one of the protected IGO/NGO strings cannot be delegated at all and that the protected strings have priority regardless of the time (or round) of application. In other words, applicants who do not officially represent these organizations will be able to see the relevant strings in advance and should not make a choice to apply for a string that would result in a string similarity review with one of these strings that is ineligible for delegation EXCEPT to an official organization named by the string. So string similarity review would have to occur, but only in the sense of rejecting a string that is too similar to one of these names. Does that already occur where an applied-for name comes too close to a reserved name? In other words, what happens to the new applicant for (dot)oniony? (Surely we are not saying it is never compared to .onion, which cannot be delegated.) Apologies as I will not be able to make today's meeting, but will catch up with the Zoom later. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Wed, Sep 10, 2025 at 4:13 PM Next Round Policy Implementation via SubPro-IRT <subpro-irt@icann.org> wrote:
Hello all,
Thank you for your questions and comments regarding the String Similarity Assessment of Reserved Names presented during the last IRT call on 4 September. Based on your comments on-list, we have updated the paper to include the relevant Board-adopted recommendations from the PDP Protection of IGO and INGO Identifiers in All gTLDs in the Annex.
You can find the updated paper on the wiki page here: https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/460783617/2025-.... The original paper is labeled “Version 1 (5 Sept), and the updated paper is labeled “Version 2 (10 Sept).
Looking forward to the discussion tomorrow.
Thank you!
Best,
Michael
*From: *"Pruis, Elaine via SubPro-IRT" <subpro-irt@icann.org> *Reply-To: *"Pruis, Elaine" <epruis@verisign.com> *Date: *Wednesday, September 10, 2025 at 8:04 AM *To: *"ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[SubPro-IRT] Re: String Similarity Assessment of Reserved Names
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check *was limited to the string on the Reserved list and applications for VARIANTS of that string*, as ICANN provided this example in their paper:
re̱dcross vs. redcross
But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs-
So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore,
“Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
*From: *Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Ashley Roberts <ashley.roberts@comlaude.com> *Date: *Monday, September 8, 2025 at 9:59 AM *To: *Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
- In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. - Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and *thus are not part of the string similarity review conducted for names on that list*.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report:
- *New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list.* - *String Ineligible for Delegation:* *A string that is ineligible for delegation in order to provide special protections at the top**-**level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). *
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards,
Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 264
<https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...>
*Follow us on LinkedIn <https://secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AATbHIImNYURcw3_FWuLzTmIZMWug...> **and YouTube <https://secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgzn_hcvUbfq5pd917cvS6TS_TslThXSUniGh-ugiNDcFBUoNU6fEwBKFGe_mjI6YIi32YHYpRHncUDwkImjz3MZyC0W6x-nc5VP9a-ld9X9W2LeDkQa-RHbUQEGfzXbHfxrkjlBYTMzA4qDxR-sD_qkHeNZjNkE9VDWras0KhXCdlVCQ70UejeyPoGZs9QVgnHDn8-65KUfxo8svFYGZBd511dmmPxE3zlbgEpvbCrsx15F1SP0NOnVxsM8iLOk/https%3A%2F%2Ft-uk.xink.io%2FTracking%2FIndex%2FbhkAAGVfAADD_RQA0>*
[image: Image removed by sender.]
*From:* Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> *Sent:* 05 September 2025 12:10 *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw <https://secure-web.cisco.com/19p0LT0iwpzzYckVQeX0vaIIYWWoQf_NsfxaSjXc-wqWLyD...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks,
Elisa ------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 
On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org> wrote:
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org <mailto:subpro-irt@icann.org>> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com <mailto:ashley.roberts@comlaude.com>> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org <mailto:elisa.busetto@icann.org>>, "subpro-irt@icann.org <mailto:subpro-irt@icann.org>" <subpro-irt@icann.org <mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC).
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards, Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...> Follow us on LinkedIn <https://secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AATbHIImNYURcw3_FWuLzTmIZMWug...> and YouTube <https://secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgz...>
From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org <mailto:subpro-irt@icann.org>> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org <mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw <https://secure-web.cisco.com/19p0LT0iwpzzYckVQeX0vaIIYWWoQf_NsfxaSjXc-wqWLyD...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks, Elisa The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0uswrgVv643zdjaofhePoBuaOKVyJBaAcRWHS8AD1YnC5D963r9P-Cgo67vieGOdipLzuLh_IcC7WwkzJ3N2Gyyx03dNivAU60dzBnXsYKaeyW2eVcN_TbXZI-0ay96aE-faQZaea1RASxPmw_tGskNK4BwgqygPv-m9f1ZLh4y-yvXwiZIEF-FgA5txbmdwnZSJgYTyWftrzON_QxFCkk-cvxB-dSNBfnhVQdM39lNuxBlVZTVCpCB033gb-81s/https%3A%2F%2Fcomlaude.com%2F>_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org <mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org <mailto:subpro-irt-leave@icann.org>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT < subpro-irt@icann.org> wrote:
I agree with Ashley and Elaine.
Cheers,
CD
Chris Disspain
+44 7880 642456
[image: AIorK4xWevLg7DM8FNJKXERnsV06zXuazaQVoJFTyAE5wjxp9tzIfz3Z3HM-Zvrkyy72U8Iwybs6ZGY.jpeg]
On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT < subpro-irt@icann.org> wrote:
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check *was limited to the string on the Reserved list and applications for VARIANTS of that string*, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
*From: *Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Ashley Roberts <ashley.roberts@comlaude.com> *Date: *Monday, September 8, 2025 at 9:59 AM *To: *Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
- In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. - Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and *thus are not part of the string similarity review conducted for names on that list*.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report:
- *New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list.* - *String Ineligible for Delegation:* *A string that is ineligible for delegation in order to provide special protections at the top**-**level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). *
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards, Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 264
<image001.png> <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...>
*Follow us on LinkedIn <https://secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AATbHIImNYURcw3_FWuLzTmIZMWug...> **and YouTube <https://secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgzn_hcvUbfq5pd917cvS6TS_TslThXSUniGh-ugiNDcFBUoNU6fEwBKFGe_mjI6YIi32YHYpRHncUDwkImjz3MZyC0W6x-nc5VP9a-ld9X9W2LeDkQa-RHbUQEGfzXbHfxrkjlBYTMzA4qDxR-sD_qkHeNZjNkE9VDWras0KhXCdlVCQ70UejeyPoGZs9QVgnHDn8-65KUfxo8svFYGZBd511dmmPxE3zlbgEpvbCrsx15F1SP0NOnVxsM8iLOk/https%3A%2F%2Ft-uk.xink.io%2FTracking%2FIndex%2FbhkAAGVfAADD_RQA0>* [image: Image removed by sender.] *From:* Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> *Sent:* 05 September 2025 12:10 *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw <https://secure-web.cisco.com/19p0LT0iwpzzYckVQeX0vaIIYWWoQf_NsfxaSjXc-wqWLyD...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks, Elisa ------------------------------ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross. ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules. I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be. Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross. Elaine From: Anne ICANN <anneicanngnso@gmail.com> Date: Friday, September 12, 2025 at 11:14 AM To: Chris Disspain <chris.disspain@identity.digital> Cc: Elaine Pruis <epruis@verisign.com>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT <subpro-irt@icann.org> wrote: I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org> wrote: Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> Follow us on LinkedIn and YouTube Error! Filename not specified. From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated. Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string? Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not? And do applicants know this when they read the Reserved Names List? How is the Reserved Names List determined? It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct? Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected? I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com> wrote:
I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross.
ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules.
I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be.
Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross.
Elaine
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Friday, September 12, 2025 at 11:14 AM *To: *Chris Disspain <chris.disspain@identity.digital> *Cc: *Elaine Pruis <epruis@verisign.com>, "ashley.roberts@comlaude.com" < ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org
*Subject: *[EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks Chris, Elaine, and Ashley,
Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity?
Are you saying the policy is:
1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round?
2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded?
Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying?
Still need to listen to the Thursday Zoom on this.
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT < subpro-irt@icann.org> wrote:
I agree with Ashley and Elaine.
Cheers,
CD
Chris Disspain
+44 7880 642456
On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT < subpro-irt@icann.org> wrote:
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check *was limited to the string on the Reserved list and applications for VARIANTS of that string*, as ICANN provided this example in their paper:
re̱dcross vs. redcross
But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs-
So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore,
“Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
*From: *Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Ashley Roberts <ashley.roberts@comlaude.com> *Date: *Monday, September 8, 2025 at 9:59 AM *To: *Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
- In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. - Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and *thus are not part of the string similarity review conducted for names on that list*.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report:
- *New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list.* - *String Ineligible for Delegation:* *A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). *
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards,
Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 264
<image001.png> <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...>
*Follow us on** LinkedIn <https://secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AATbHIImNYURcw3_FWuLzTmIZMWug...> * *and** YouTube <https://secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgzn_hcvUbfq5pd917cvS6TS_TslThXSUniGh-ugiNDcFBUoNU6fEwBKFGe_mjI6YIi32YHYpRHncUDwkImjz3MZyC0W6x-nc5VP9a-ld9X9W2LeDkQa-RHbUQEGfzXbHfxrkjlBYTMzA4qDxR-sD_qkHeNZjNkE9VDWras0KhXCdlVCQ70UejeyPoGZs9QVgnHDn8-65KUfxo8svFYGZBd511dmmPxE3zlbgEpvbCrsx15F1SP0NOnVxsM8iLOk/https%3A%2F%2Ft-uk.xink.io%2FTracking%2FIndex%2FbhkAAGVfAADD_RQA0>*
*Error! Filename not specified.*
*From:* Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> *Sent:* 05 September 2025 12:10 *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw <https://secure-web.cisco.com/19p0LT0iwpzzYckVQeX0vaIIYWWoQf_NsfxaSjXc-wqWLyD...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks,
Elisa ------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com <https://secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcwu5Hua3xar66-YT6yjp6Zef4q0us...>
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwFAobANPF5A63cRLuSuXBj4Ng8Frq...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4sz5cygGCDTCMobqvbFM1lSTnfde...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwFAobANPF5A63cRLuSuXBj4Ng8Frq...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4sz5cygGCDTCMobqvbFM1lSTnfde...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Anne, A few answers to your questions in blue below, I am inviting @Sarmad Hussain<mailto:sarmad.hussain@icann.org>and @Michael Karakash<mailto:michael.karakash@icann.org> to chime in on Monday, too. Best. Lars From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org> Reply to: Anne ICANN <anneicanngnso@gmail.com> Date: Saturday, 13 September 2025 at 20:22 To: "Pruis, Elaine" <epruis@verisign.com> Cc: "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated. Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed. The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed. Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string? Yes, there is a clear difference between blocked and reserved names (see above). See also above. Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not? Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012. And do applicants know this when they read the Reserved Names List? Yes, it is a list that is determined by policy How is the Reserved Names List determined? Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct? Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list. Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected? Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can. I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com<mailto:epruis@verisign.com>> wrote: I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross. ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules. I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be. Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross. Elaine From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Friday, September 12, 2025 at 11:14 AM To: Chris Disspain <chris.disspain@identity.digital> Cc: Elaine Pruis <epruis@verisign.com<mailto:epruis@verisign.com>>, "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 [cid:image001.jpg@01DC24F0.99F73BE0] On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org<mailto:elisa.busetto@icann.org>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: * In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. * Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: * New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. * String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> Follow us on LinkedIn [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> and YouTube [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Z...> Error! Filename not specified. From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...> Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?) Again, apologies for my lack of background on this but really need to understand the facts. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org> wrote:
Hi Anne,
A few answers to your questions in blue below, I am inviting @Sarmad Hussain <sarmad.hussain@icann.org>and @Michael Karakash <michael.karakash@icann.org> to chime in on Monday, too.
Best. Lars
*From: *Anne ICANN via SubPro-IRT <subpro-irt@icann.org> *Reply to: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Saturday, 13 September 2025 at 20:22 *To: *"Pruis, Elaine" <epruis@verisign.com> *Cc: *"ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[SubPro-IRT] Re: String Similarity Assessment of Reserved Names
Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated.
Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed.
The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed.
Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string?
Yes, there is a clear difference between blocked and reserved names (see above). See also above.
Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not?
Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012.
And do applicants know this when they read the Reserved Names List?
Yes, it is a list that is determined by policy
How is the Reserved Names List determined?
Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm...
It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct?
Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list.
Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected?
Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can.
I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help.
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com> wrote:
I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross.
ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules.
I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be.
Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross.
Elaine
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Friday, September 12, 2025 at 11:14 AM *To: *Chris Disspain <chris.disspain@identity.digital> *Cc: *Elaine Pruis <epruis@verisign.com>, "ashley.roberts@comlaude.com" < ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org
*Subject: *[EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks Chris, Elaine, and Ashley,
Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity?
Are you saying the policy is:
1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round?
2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded?
Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying?
Still need to listen to the Thursday Zoom on this.
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT < subpro-irt@icann.org> wrote:
I agree with Ashley and Elaine.
Cheers,
CD
Chris Disspain
+44 7880 642456
On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT < subpro-irt@icann.org> wrote:
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check *was limited to the string on the Reserved list and applications for VARIANTS of that string*, as ICANN provided this example in their paper:
re̱dcross vs. redcross
But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs-
So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore,
“Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
*From: *Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Ashley Roberts <ashley.roberts@comlaude.com> *Date: *Monday, September 8, 2025 at 9:59 AM *To: *Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
- In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. - Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and *thus are not part of the string similarity review conducted for names on that list*.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report:
- *New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list.* - *String Ineligible for Delegation:* *A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). *
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards,
Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 264
<image001.png> [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
*Follow us on** LinkedIn [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> * *and** YouTube [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgzn_hcvUbfq5pd917cvS6TS_TslThXSUniGh-ugiNDcFBUoNU6fEwBKFGe_mjI6YIi32YHYpRHncUDwkImjz3MZyC0W6x-nc5VP9a-ld9X9W2LeDkQa-RHbUQEGfzXbHfxrkjlBYTMzA4qDxR-sD_qkHeNZjNkE9VDWras0KhXCdlVCQ70UejeyPoGZs9QVgnHDn8-65KUfxo8svFYGZBd511dmmPxE3zlbgEpvbCrsx15F1SP0NOnVxsM8iLOk/https*3A*2F*2Ft-uk.xink.io*2FTracking*2FIndex*2FbhkAAGVfAADD_RQA0__;JSUlJSUl!!PtGJab4!6kIuEt51tWx3ozk4MWys07lKSI6D2xLVnRS33mUWDbOHOpzfX5oR4o4jDr7NL5bRvvaeDCD067ocYzvL6axCNiMDkudqoQ$>*
*Error! Filename not specified.*
*From:* Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> *Sent:* 05 September 2025 12:10 *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks,
Elisa ------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com> wrote:
Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?)
Again, apologies for my lack of background on this but really need to understand the facts. Anne
Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com
On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org> wrote:
Hi Anne,
A few answers to your questions in blue below, I am inviting @Sarmad Hussain <sarmad.hussain@icann.org>and @Michael Karakash <michael.karakash@icann.org> to chime in on Monday, too.
Best. Lars
*From: *Anne ICANN via SubPro-IRT <subpro-irt@icann.org> *Reply to: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Saturday, 13 September 2025 at 20:22 *To: *"Pruis, Elaine" <epruis@verisign.com> *Cc: *"ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[SubPro-IRT] Re: String Similarity Assessment of Reserved Names
Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated.
Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed.
The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed.
Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string?
Yes, there is a clear difference between blocked and reserved names (see above). See also above.
Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not?
Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012.
And do applicants know this when they read the Reserved Names List?
Yes, it is a list that is determined by policy
How is the Reserved Names List determined?
Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm...
It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct?
Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list.
Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected?
Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can.
I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help.
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com> wrote:
I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross.
ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules.
I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be.
Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross.
Elaine
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Friday, September 12, 2025 at 11:14 AM *To: *Chris Disspain <chris.disspain@identity.digital> *Cc: *Elaine Pruis <epruis@verisign.com>, "ashley.roberts@comlaude.com" < ashley.roberts@comlaude.com>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks Chris, Elaine, and Ashley,
Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity?
Are you saying the policy is:
1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round?
2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded?
Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying?
Still need to listen to the Thursday Zoom on this.
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT < subpro-irt@icann.org> wrote:
I agree with Ashley and Elaine.
Cheers,
CD
Chris Disspain
+44 7880 642456
On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT < subpro-irt@icann.org> wrote:
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check *was limited to the string on the Reserved list and applications for VARIANTS of that string*, as ICANN provided this example in their paper:
re̱dcross vs. redcross
But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs-
So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore,
“Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
*From: *Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Ashley Roberts <ashley.roberts@comlaude.com> *Date: *Monday, September 8, 2025 at 9:59 AM *To: *Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
- In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. - Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and *thus are not part of the string similarity review conducted for names on that list*.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report:
- *New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list.* - *String Ineligible for Delegation:* *A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). *
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards,
Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 264
<image001.png> [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
*Follow us on** LinkedIn [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> * *and** YouTube [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgzn_hcvUbfq5pd917cvS6TS_TslThXSUniGh-ugiNDcFBUoNU6fEwBKFGe_mjI6YIi32YHYpRHncUDwkImjz3MZyC0W6x-nc5VP9a-ld9X9W2LeDkQa-RHbUQEGfzXbHfxrkjlBYTMzA4qDxR-sD_qkHeNZjNkE9VDWras0KhXCdlVCQ70UejeyPoGZs9QVgnHDn8-65KUfxo8svFYGZBd511dmmPxE3zlbgEpvbCrsx15F1SP0NOnVxsM8iLOk/https*3A*2F*2Ft-uk.xink.io*2FTracking*2FIndex*2FbhkAAGVfAADD_RQA0__;JSUlJSUl!!PtGJab4!6kIuEt51tWx3ozk4MWys07lKSI6D2xLVnRS33mUWDbOHOpzfX5oR4o4jDr7NL5bRvvaeDCD067ocYzvL6axCNiMDkudqoQ$>*
*Error! Filename not specified.*
*From:* Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> *Sent:* 05 September 2025 12:10 *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks,
Elisa ------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hi Anne, In the AGB for the strings on the Reserved Names list we say: “The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in 6.2.2.2 below: * Names added based on recommendations from the IGO-INGO PDP Working Group regarding the protections of IGO-INGO identifiers in all gTLDs, including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) – International Non-Governmental Organizations (INGO) Names.” We also include multiple footnotes to clarify the source of the lists (in text). We can look at the IGO-INGO PDP policy recommendations which is more specific as to what strings are on the Reserved Names lists. The GNSO Council Report to the ICANN Board lays it out clearly in Scope 1 of each recommendation: https://gnso.icann.org/sites/default/files/filefield_43533/council-board-igo... The recommendations point to the source of the strings (the GAC list), the ECOSOC General Consultative status list maintained by the UN, and the Red Cross/Red Crescent strings. ICANN has also included these strings on the bottom of this page here (Bullets 1 and 2): https://www.icann.org/en/contracted-parties/registry-operators/services/rese.... Hope this helps and let us know if you have any further questions. Thank you! Best, Michael From: Anne ICANN <anneicanngnso@gmail.com> Date: Monday, September 15, 2025 at 8:22 AM To: Lars Hoffmann <lars.hoffmann@icann.org> Cc: "Pruis, Elaine" <epruis@verisign.com>, Sarmad Hussain <sarmad.hussain@icann.org>, Michael Karakash <michael.karakash@icann.org>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> wrote: Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?) Again, apologies for my lack of background on this but really need to understand the facts. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org<mailto:lars.hoffmann@icann.org>> wrote: Hi Anne, A few answers to your questions in blue below, I am inviting @Sarmad Hussain<mailto:sarmad.hussain@icann.org>and @Michael Karakash<mailto:michael.karakash@icann.org> to chime in on Monday, too. Best. Lars From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply to: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Saturday, 13 September 2025 at 20:22 To: "Pruis, Elaine" <epruis@verisign.com<mailto:epruis@verisign.com>> Cc: "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated. Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed. The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed. Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string? Yes, there is a clear difference between blocked and reserved names (see above). See also above. Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not? Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012. And do applicants know this when they read the Reserved Names List? Yes, it is a list that is determined by policy How is the Reserved Names List determined? Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... [forum.icann.org]<https://urldefense.com/v3/__https:/forum.icann.org/lists/comments-igo-ingo-i...> It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct? Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list. Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected? Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can. I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com<mailto:epruis@verisign.com>> wrote: I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross. ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules. I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be. Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross. Elaine From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Friday, September 12, 2025 at 11:14 AM To: Chris Disspain <chris.disspain@identity.digital> Cc: Elaine Pruis <epruis@verisign.com<mailto:epruis@verisign.com>>, "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 [cid:image001.jpg@01DC2624.07648AA0] On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org<mailto:elisa.busetto@icann.org>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: * In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. * Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: * New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. * String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> Follow us on LinkedIn [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> and YouTube [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Z...> Error! Filename not specified. From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...> Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
THanks Michael. In the policy document relative to names which are reserved at the second level, the following language appears: *3.1. Reserve* means to withhold from registration or to allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available a character string within the TLD. Does it then follow that at the Top Level, no string applied for at any time could include the actual string that is listed in Reserved Names? For example, is "(dot)myredcross" prohibited by the Top Level Policy on Reserved Names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Mon, Sep 15, 2025 at 9:35 AM Michael Karakash <michael.karakash@icann.org> wrote:
Hi Anne,
In the AGB for the strings on the Reserved Names list we say:
“The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in 6.2.2.2 below:
- Names added based on recommendations from the IGO-INGO PDP Working Group regarding the protections of IGO-INGO identifiers in all gTLDs, including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) – International Non-Governmental Organizations (INGO) Names.”
We also include multiple footnotes to clarify the source of the lists (in text).
We can look at the IGO-INGO PDP policy recommendations which is more specific as to what strings are on the Reserved Names lists. The GNSO Council Report to the ICANN Board lays it out clearly in Scope 1 of each recommendation: https://gnso.icann.org/sites/default/files/filefield_43533/council-board-igo...
The recommendations point to the source of the strings (the GAC list), the ECOSOC General Consultative status list maintained by the UN, and the Red Cross/Red Crescent strings. ICANN has also included these strings on the bottom of this page here (Bullets 1 and 2): https://www.icann.org/en/contracted-parties/registry-operators/services/rese... .
Hope this helps and let us know if you have any further questions.
Thank you!
Best,
Michael
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Monday, September 15, 2025 at 8:22 AM *To: *Lars Hoffmann <lars.hoffmann@icann.org> *Cc: *"Pruis, Elaine" <epruis@verisign.com>, Sarmad Hussain < sarmad.hussain@icann.org>, Michael Karakash <michael.karakash@icann.org>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names?
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com> wrote:
Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?)
Again, apologies for my lack of background on this but really need to understand the facts.
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org> wrote:
Hi Anne,
A few answers to your questions in blue below, I am inviting @Sarmad Hussain <sarmad.hussain@icann.org>and @Michael Karakash <michael.karakash@icann.org> to chime in on Monday, too.
Best. Lars
*From: *Anne ICANN via SubPro-IRT <subpro-irt@icann.org> *Reply to: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Saturday, 13 September 2025 at 20:22 *To: *"Pruis, Elaine" <epruis@verisign.com> *Cc: *"ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[SubPro-IRT] Re: String Similarity Assessment of Reserved Names
Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated.
Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed.
The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed.
Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string?
Yes, there is a clear difference between blocked and reserved names (see above). See also above.
Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not?
Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012.
And do applicants know this when they read the Reserved Names List?
Yes, it is a list that is determined by policy
How is the Reserved Names List determined?
Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... [forum.icann.org] <https://urldefense.com/v3/__https:/forum.icann.org/lists/comments-igo-ingo-i...>
It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct?
Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list.
Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected?
Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can.
I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help.
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com> wrote:
I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross.
ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules.
I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be.
Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross.
Elaine
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Friday, September 12, 2025 at 11:14 AM *To: *Chris Disspain <chris.disspain@identity.digital> *Cc: *Elaine Pruis <epruis@verisign.com>, "ashley.roberts@comlaude.com" < ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org
*Subject: *[EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks Chris, Elaine, and Ashley,
Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity?
Are you saying the policy is:
1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round?
2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded?
Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying?
Still need to listen to the Thursday Zoom on this.
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT < subpro-irt@icann.org> wrote:
I agree with Ashley and Elaine.
Cheers,
CD
Chris Disspain
+44 7880 642456
On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT < subpro-irt@icann.org> wrote:
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check *was limited to the string on the Reserved list and applications for VARIANTS of that string*, as ICANN provided this example in their paper:
re̱dcross vs. redcross
But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs-
So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore,
“Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
*From: *Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Ashley Roberts <ashley.roberts@comlaude.com> *Date: *Monday, September 8, 2025 at 9:59 AM *To: *Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
- In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. - Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and *thus are not part of the string similarity review conducted for names on that list*.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report:
- *New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list.* - *String Ineligible for Delegation:* *A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). *
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards,
Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 264
<image001.png> [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
*Follow us on** LinkedIn [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> * *and** YouTube [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgzn_hcvUbfq5pd917cvS6TS_TslThXSUniGh-ugiNDcFBUoNU6fEwBKFGe_mjI6YIi32YHYpRHncUDwkImjz3MZyC0W6x-nc5VP9a-ld9X9W2LeDkQa-RHbUQEGfzXbHfxrkjlBYTMzA4qDxR-sD_qkHeNZjNkE9VDWras0KhXCdlVCQ70UejeyPoGZs9QVgnHDn8-65KUfxo8svFYGZBd511dmmPxE3zlbgEpvbCrsx15F1SP0NOnVxsM8iLOk/https*3A*2F*2Ft-uk.xink.io*2FTracking*2FIndex*2FbhkAAGVfAADD_RQA0__;JSUlJSUl!!PtGJab4!6kIuEt51tWx3ozk4MWys07lKSI6D2xLVnRS33mUWDbOHOpzfX5oR4o4jDr7NL5bRvvaeDCD067ocYzvL6axCNiMDkudqoQ$>*
*Error! Filename not specified.*
*From:* Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> *Sent:* 05 September 2025 12:10 *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks,
Elisa ------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Thanks, Anne. The protection is about the string itself. So .redcross. As per the paper, the question is now whether confusingly similar strings to .redcross (and all other strings that are explicitly protected at the top level) can be delegated or whether all applied-for string should be evaluated against the reserved list (as they are against the blocked list and already delegated TLDs). While I am not a string similarity evaluator, based on the string similarity evaluation outcomes of the 2012, my educated guess it that .myredcross would pass string similarity (though not sure it’ll pass without GAC advice and/or objections). I hope this helps. One important point re: timing. During last week’s call, and as far as I can tell also on list, all but three IRT members believe that Option 1 aligns with the IGO/INGO PDP recommendations. Therefore, I would urge that the Council takes this up as soon as practicable, to ensure we can meet our timeline. Maybe you can work with the co-Chairs to have it added to the agenda for Thursday’s call – I know it’s late in the process but maybe there is a chance? The question to the Council is whether Option 1 aligns with the intent of the IGO/INGO recommendations 3.1.1, 3.1.2, 3.2.1, 3.2.2, 3.3.1, and 3.3.2. Until/unless the Council weighs in, we are at an impasse between IRT and Org’s interpretation and cannot move forward with Board consideration as planned. Best. Lars From: Anne ICANN <anneicanngnso@gmail.com> Date: Monday, 15 September 2025 at 18:57 To: Michael Karakash <michael.karakash@icann.org> Cc: Lars Hoffmann <lars.hoffmann@icann.org>, "Pruis, Elaine" <epruis@verisign.com>, Sarmad Hussain <sarmad.hussain@icann.org>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: Re: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names THanks Michael. In the policy document relative to names which are reserved at the second level, the following language appears: 3.1. Reserve means to withhold from registration or to allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available a character string within the TLD. Does it then follow that at the Top Level, no string applied for at any time could include the actual string that is listed in Reserved Names? For example, is "(dot)myredcross" prohibited by the Top Level Policy on Reserved Names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Mon, Sep 15, 2025 at 9:35 AM Michael Karakash <michael.karakash@icann.org<mailto:michael.karakash@icann.org>> wrote: Hi Anne, In the AGB for the strings on the Reserved Names list we say: “The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in 6.2.2.2 below: * Names added based on recommendations from the IGO-INGO PDP Working Group regarding the protections of IGO-INGO identifiers in all gTLDs, including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) – International Non-Governmental Organizations (INGO) Names.” We also include multiple footnotes to clarify the source of the lists (in text). We can look at the IGO-INGO PDP policy recommendations which is more specific as to what strings are on the Reserved Names lists. The GNSO Council Report to the ICANN Board lays it out clearly in Scope 1 of each recommendation: https://gnso.icann.org/sites/default/files/filefield_43533/council-board-igo... [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/filefi...> The recommendations point to the source of the strings (the GAC list), the ECOSOC General Consultative status list maintained by the UN, and the Red Cross/Red Crescent strings. ICANN has also included these strings on the bottom of this page here (Bullets 1 and 2): https://www.icann.org/en/contracted-parties/registry-operators/services/rese.... Hope this helps and let us know if you have any further questions. Thank you! Best, Michael From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Monday, September 15, 2025 at 8:22 AM To: Lars Hoffmann <lars.hoffmann@icann.org<mailto:lars.hoffmann@icann.org>> Cc: "Pruis, Elaine" <epruis@verisign.com<mailto:epruis@verisign.com>>, Sarmad Hussain <sarmad.hussain@icann.org<mailto:sarmad.hussain@icann.org>>, Michael Karakash <michael.karakash@icann.org<mailto:michael.karakash@icann.org>>, "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> wrote: Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?) Again, apologies for my lack of background on this but really need to understand the facts. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org<mailto:lars.hoffmann@icann.org>> wrote: Hi Anne, A few answers to your questions in blue below, I am inviting @Sarmad Hussain<mailto:sarmad.hussain@icann.org>and @Michael Karakash<mailto:michael.karakash@icann.org> to chime in on Monday, too. Best. Lars From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply to: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Saturday, 13 September 2025 at 20:22 To: "Pruis, Elaine" <epruis@verisign.com<mailto:epruis@verisign.com>> Cc: "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated. Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed. The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed. Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string? Yes, there is a clear difference between blocked and reserved names (see above). See also above. Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not? Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012. And do applicants know this when they read the Reserved Names List? Yes, it is a list that is determined by policy How is the Reserved Names List determined? Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... [forum.icann.org]<https://urldefense.com/v3/__https:/forum.icann.org/lists/comments-igo-ingo-i...> It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct? Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list. Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected? Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can. I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com<mailto:epruis@verisign.com>> wrote: I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross. ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules. I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be. Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross. Elaine From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Friday, September 12, 2025 at 11:14 AM To: Chris Disspain <chris.disspain@identity.digital> Cc: Elaine Pruis <epruis@verisign.com<mailto:epruis@verisign.com>>, "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 [cid:image001.jpg@01DC2676.262222C0] On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org<mailto:elisa.busetto@icann.org>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: * In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. * Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: * New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. * String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> Follow us on LinkedIn [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> and YouTube [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Z...> Error! Filename not specified. From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...> Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Lars, I agree with getting this issue to the Council as soon as possible, but getting a definitive answer this Thursday seems unlikely. After all, the Councilors are not going to know. The Council will need to check with the experts (i would assume) that worked on the PDP, many of whom are on this IRT telling you that Option 1 is the one that aligns with what the report stated. I hope you didn't intend this message, but it seems like the message below is somewhat of a threat. "Unless the Council weighs in.......we cannot move forward with Board consideration as planned. We could also state that unless the Council weighs in otherwise, we go with option 1 AND move forward with Board consideration as planned. After all, you have the IRT telling you what was intended and the IRT consists of most of the active participants in the PDP. Shouldn't it be YOUR burden to prove that YOUR interpretation is in line with the recommendations as opposed to us having to prove that yours is NOT in line with the recommendations. That seems backwards. I really hope that at this stage you are moving forward with Board consideration and will not cause a delay simply because staff is taking a different position than the community. Sincerely, Jeff On 9/15/2025 1:23:08 PM, Lars Hoffmann via SubPro-IRT <subpro-irt@icann.org> wrote: Thanks, Anne. The protection is about the string itself. So .redcross. As per the paper, the question is now whether confusingly similar strings to .redcross (and all other strings that are explicitly protected at the top level) can be delegated or whether all applied-for string should be evaluated against the reserved list (as they are against the blocked list and already delegated TLDs). While I am not a string similarity evaluator, based on the string similarity evaluation outcomes of the 2012, my educated guess it that .myredcross would pass string similarity (though not sure it’ll pass without GAC advice and/or objections). I hope this helps. One important point re: timing. During last week’s call, and as far as I can tell also on list, all but three IRT members believe that Option 1 aligns with the IGO/INGO PDP recommendations. Therefore, I would urge that the Council takes this up as soon as practicable, to ensure we can meet our timeline. Maybe you can work with the co-Chairs to have it added to the agenda for Thursday’s call – I know it’s late in the process but maybe there is a chance? The question to the Council is whether Option 1 aligns with the intent of the IGO/INGO recommendations 3.1.1, 3.1.2, 3.2.1, 3.2.2, 3.3.1, and 3.3.2. Until/unless the Council weighs in, we are at an impasse between IRT and Org’s interpretation and cannot move forward with Board consideration as planned. Best. Lars From: Anne ICANN <anneicanngnso@gmail.com> Date: Monday, 15 September 2025 at 18:57 To: Michael Karakash <michael.karakash@icann.org> Cc: Lars Hoffmann <lars.hoffmann@icann.org>, "Pruis, Elaine" <epruis@verisign.com>, Sarmad Hussain <sarmad.hussain@icann.org>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: Re: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names THanks Michael. In the policy document relative to names which are reserved at the second level, the following language appears: 3.1. Reserve means to withhold from registration or to allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available a character string within the TLD. Does it then follow that at the Top Level, no string applied for at any time could include the actual string that is listed in Reserved Names? For example, is "(dot)myredcross" prohibited by the Top Level Policy on Reserved Names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com] On Mon, Sep 15, 2025 at 9:35 AM Michael Karakash <michael.karakash@icann.org [mailto:michael.karakash@icann.org]> wrote: Hi Anne, In the AGB for the strings on the Reserved Names list we say: “The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in 6.2.2.2 below: * Names added based on recommendations from the IGO-INGO PDP Working Group regarding the protections of IGO-INGO identifiers in all gTLDs, including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) – International Non-Governmental Organizations (INGO) Names.” We also include multiple footnotes to clarify the source of the lists (in text). We can look at the IGO-INGO PDP policy recommendations which is more specific as to what strings are on the Reserved Names lists. The GNSO Council Report to the ICANN Board lays it out clearly in Scope 1 of each recommendation: https://gnso.icann.org/sites/default/files/filefield_43533/council-board-igo... [gnso.icann.org] [https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/filefi...] The recommendations point to the source of the strings (the GAC list), the ECOSOC General Consultative status list maintained by the UN, and the Red Cross/Red Crescent strings. ICANN has also included these strings on the bottom of this page here (Bullets 1 and 2): https://www.icann.org/en/contracted-parties/registry-operators/services/rese... [https://www.icann.org/en/contracted-parties/registry-operators/services/rese...]. Hope this helps and let us know if you have any further questions. Thank you! Best, Michael From: Anne ICANN <anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com]> Date: Monday, September 15, 2025 at 8:22 AM To: Lars Hoffmann <lars.hoffmann@icann.org [mailto:lars.hoffmann@icann.org]> Cc: "Pruis, Elaine" <epruis@verisign.com [mailto:epruis@verisign.com]>, Sarmad Hussain <sarmad.hussain@icann.org [mailto:sarmad.hussain@icann.org]>, Michael Karakash <michael.karakash@icann.org [mailto:michael.karakash@icann.org]>, "ashley.roberts@comlaude.com [mailto:ashley.roberts@comlaude.com]" <ashley.roberts@comlaude.com [mailto:ashley.roberts@comlaude.com]>, "subpro-irt@icann.org [mailto:subpro-irt@icann.org]" <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Subject: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com] On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com]> wrote: Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?) Again, apologies for my lack of background on this but really need to understand the facts. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com] On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org [mailto:lars.hoffmann@icann.org]> wrote: Hi Anne, A few answers to your questions in blue below, I am inviting @Sarmad Hussain [mailto:sarmad.hussain@icann.org]and @Michael Karakash [mailto:michael.karakash@icann.org] to chime in on Monday, too. Best. Lars From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Reply to: Anne ICANN <anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com]> Date: Saturday, 13 September 2025 at 20:22 To: "Pruis, Elaine" <epruis@verisign.com [mailto:epruis@verisign.com]> Cc: "ashley.roberts@comlaude.com [mailto:ashley.roberts@comlaude.com]" <ashley.roberts@comlaude.com [mailto:ashley.roberts@comlaude.com]>, "subpro-irt@icann.org [mailto:subpro-irt@icann.org]" <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Subject: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated. Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed. The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed. Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string? Yes, there is a clear difference between blocked and reserved names (see above). See also above. Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not? Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012. And do applicants know this when they read the Reserved Names List? Yes, it is a list that is determined by policy How is the Reserved Names List determined? Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... [forum.icann.org] [https://urldefense.com/v3/__https:/forum.icann.org/lists/comments-igo-ingo-i...] It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct? Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list. Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected? Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can. I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com] On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com [mailto:epruis@verisign.com]> wrote: I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross. ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules. I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be. Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross. Elaine From: Anne ICANN <anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com]> Date: Friday, September 12, 2025 at 11:14 AM To: Chris Disspain <chris.disspain@identity.digital> Cc: Elaine Pruis <epruis@verisign.com [mailto:epruis@verisign.com]>, "ashley.roberts@comlaude.com [mailto:ashley.roberts@comlaude.com]" <ashley.roberts@comlaude.com [mailto:ashley.roberts@comlaude.com]>, "subpro-irt@icann.org [mailto:subpro-irt@icann.org]" <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Subject: [EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com] On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> wrote: I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> wrote: Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com [mailto:ashley.roberts@comlaude.com]> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org [mailto:elisa.busetto@icann.org]>, "subpro-irt@icann.org [mailto:subpro-irt@icann.org]" <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: * In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. * Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: * New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. * String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...] Follow us on LinkedIn [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...] and YouTube [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Z...] Error! Filename not specified. From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org [mailto:subpro-irt@icann.org] Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...] Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...] _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org [mailto:subpro-irt@icann.org] To unsubscribe send an email to subpro-irt-leave@icann.org [mailto:subpro-irt-leave@icann.org] _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...]) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...]). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org [mailto:subpro-irt@icann.org] To unsubscribe send an email to subpro-irt-leave@icann.org [mailto:subpro-irt-leave@icann.org] _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...]) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] [https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...]). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. [1cc6278c-3866-4985-8aab-8450e9f950a7]
Hi Jeff – Thanks for your message. I just wanted to be clear that there is no threat involved or implied. I apologize if my comment came across in any other way then just laying out the facts. To be clear, the team is working flat out to achieve the Dublin deadline, to which we remain fully committed. On the issue at hand: as staff, we are given policies to implement. We proposed a way forward to implement, including a rationale, which is our role. The IRT’s role to ensure it aligns with the intent of the policy. The issue here is about a policy from 2013, and the SubPro IRT does not agree with org’s proposed path forward. Therefore, it goes back to the Council. I think the CPIF<https://www.icann.org/uploads/ckeditor/CPIF_v2.0_2019CLEAN.pdf> and the IRT Guidelines<https://www.icann.org/en/system/files/files/irt-principles-guidelines-23aug1...> are clear about this. If the Council provides input or delegates its authority to the IRT on this issue, then we will move forward accordingly. I hope you and everyone else can also understand our point of view: if a protected organization can no longer apply for their string because a confusingly similar string was delegated in a previous round, then they will likely raise concerns with ICANN. You noted on the call last week, I think, that the National Red Cross and Red Crescent Society submitted a comment<https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm...> on the IGO/INGO Initial Report. In this document they raise concerns about confusingly similar strings to ‘their’ strings being delegated, citing Article 53 of the Geneva Convention (with which I am not familiar). So, I think it is fair to assume that they will raise concerns with ICANN in such a case – however hypothetical it may be. Therefore, having the Council confirm the intent of the recommendation seems the prudent and right thing to do at this stage. I have been asked to participate in Thursday’s GNSO Council call and will of course do so. We can then continue the discussion with the IRT during Thursday’s IRT call that is scheduled a few hours after the Council meeting. Best. Lars From: "Jeffrey J. Neuman" <jeff@jjnsolutions.com> Date: Monday, 15 September 2025 at 22:49 To: Lars Hoffmann <lars.hoffmann@icann.org>, Anne ICANN <anneicanngnso@gmail.com>, Michael Karakash <michael.karakash@icann.org> Cc: Ashley Roberts <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: Re: [SubPro-IRT] Re: [Ext] Re: Re: String Similarity Assessment of Reserved Names Lars, I agree with getting this issue to the Council as soon as possible, but getting a definitive answer this Thursday seems unlikely. After all, the Councilors are not going to know. The Council will need to check with the experts (i would assume) that worked on the PDP, many of whom are on this IRT telling you that Option 1 is the one that aligns with what the report stated. I hope you didn't intend this message, but it seems like the message below is somewhat of a threat. "Unless the Council weighs in.......we cannot move forward with Board consideration as planned. We could also state that unless the Council weighs in otherwise, we go with option 1 AND move forward with Board consideration as planned. After all, you have the IRT telling you what was intended and the IRT consists of most of the active participants in the PDP. Shouldn't it be YOUR burden to prove that YOUR interpretation is in line with the recommendations as opposed to us having to prove that yours is NOT in line with the recommendations. That seems backwards. I really hope that at this stage you are moving forward with Board consideration and will not cause a delay simply because staff is taking a different position than the community. Sincerely, Jeff [Image removed by sender.] On 9/15/2025 1:23:08 PM, Lars Hoffmann via SubPro-IRT <subpro-irt@icann.org> wrote: Thanks, Anne. The protection is about the string itself. So .redcross. As per the paper, the question is now whether confusingly similar strings to .redcross (and all other strings that are explicitly protected at the top level) can be delegated or whether all applied-for string should be evaluated against the reserved list (as they are against the blocked list and already delegated TLDs). While I am not a string similarity evaluator, based on the string similarity evaluation outcomes of the 2012, my educated guess it that .myredcross would pass string similarity (though not sure it’ll pass without GAC advice and/or objections). I hope this helps. One important point re: timing. During last week’s call, and as far as I can tell also on list, all but three IRT members believe that Option 1 aligns with the IGO/INGO PDP recommendations. Therefore, I would urge that the Council takes this up as soon as practicable, to ensure we can meet our timeline. Maybe you can work with the co-Chairs to have it added to the agenda for Thursday’s call – I know it’s late in the process but maybe there is a chance? The question to the Council is whether Option 1 aligns with the intent of the IGO/INGO recommendations 3.1.1, 3.1.2, 3.2.1, 3.2.2, 3.3.1, and 3.3.2. Until/unless the Council weighs in, we are at an impasse between IRT and Org’s interpretation and cannot move forward with Board consideration as planned. Best. Lars From: Anne ICANN <anneicanngnso@gmail.com> Date: Monday, 15 September 2025 at 18:57 To: Michael Karakash <michael.karakash@icann.org> Cc: Lars Hoffmann <lars.hoffmann@icann.org>, "Pruis, Elaine" <epruis@verisign.com>, Sarmad Hussain <sarmad.hussain@icann.org>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: Re: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names THanks Michael. In the policy document relative to names which are reserved at the second level, the following language appears: 3.1. Reserve means to withhold from registration or to allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available a character string within the TLD. Does it then follow that at the Top Level, no string applied for at any time could include the actual string that is listed in Reserved Names? For example, is "(dot)myredcross" prohibited by the Top Level Policy on Reserved Names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Mon, Sep 15, 2025 at 9:35 AM Michael Karakash <michael.karakash@icann.org<mailto:michael.karakash@icann.org>> wrote: Hi Anne, In the AGB for the strings on the Reserved Names list we say: “The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in 6.2.2.2 below: * Names added based on recommendations from the IGO-INGO PDP Working Group regarding the protections of IGO-INGO identifiers in all gTLDs, including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) – International Non-Governmental Organizations (INGO) Names.” We also include multiple footnotes to clarify the source of the lists (in text). We can look at the IGO-INGO PDP policy recommendations which is more specific as to what strings are on the Reserved Names lists. The GNSO Council Report to the ICANN Board lays it out clearly in Scope 1 of each recommendation: https://gnso.icann.org/sites/default/files/filefield_43533/council-board-igo... [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/filefi...> The recommendations point to the source of the strings (the GAC list), the ECOSOC General Consultative status list maintained by the UN, and the Red Cross/Red Crescent strings. ICANN has also included these strings on the bottom of this page here (Bullets 1 and 2): https://www.icann.org/en/contracted-parties/registry-operators/services/rese.... Hope this helps and let us know if you have any further questions. Thank you! Best, Michael From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Monday, September 15, 2025 at 8:22 AM To: Lars Hoffmann <lars.hoffmann@icann.org<mailto:lars.hoffmann@icann.org>> Cc: "Pruis, Elaine" <epruis@verisign.com<mailto:epruis@verisign.com>>, Sarmad Hussain <sarmad.hussain@icann.org<mailto:sarmad.hussain@icann.org>>, Michael Karakash <michael.karakash@icann.org<mailto:michael.karakash@icann.org>>, "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> wrote: Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?) Again, apologies for my lack of background on this but really need to understand the facts. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org<mailto:lars.hoffmann@icann.org>> wrote: Hi Anne, A few answers to your questions in blue below, I am inviting @Sarmad Hussain<mailto:sarmad.hussain@icann.org>and @Michael Karakash<mailto:michael.karakash@icann.org> to chime in on Monday, too. Best. Lars From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply to: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Saturday, 13 September 2025 at 20:22 To: "Pruis, Elaine" <epruis@verisign.com<mailto:epruis@verisign.com>> Cc: "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated. Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed. The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed. Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string? Yes, there is a clear difference between blocked and reserved names (see above). See also above. Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not? Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012. And do applicants know this when they read the Reserved Names List? Yes, it is a list that is determined by policy How is the Reserved Names List determined? Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... [forum.icann.org]<https://urldefense.com/v3/__https:/forum.icann.org/lists/comments-igo-ingo-i...> It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct? Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list. Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected? Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can. I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com<mailto:epruis@verisign.com>> wrote: I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross. ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules. I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be. Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross. Elaine From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Friday, September 12, 2025 at 11:14 AM To: Chris Disspain <chris.disspain@identity.digital> Cc: Elaine Pruis <epruis@verisign.com<mailto:epruis@verisign.com>>, "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 [cid:image001.jpg@01DC270C.BF992D90] On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org<mailto:elisa.busetto@icann.org>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: * In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. * Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: * New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. * String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> Follow us on LinkedIn [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> and YouTube [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Z...> Error! Filename not specified. From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...> Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Thanks Lars. I will check with Susan but even if she feels it's appropriate to raise in AOB, there is no way to get an answer this quickly from Council as we must always allow sufficient time for Council members to consult their Constituencies and Stakeholder Groups. I will confer with Susan at her earliest convenience but I am traveling all day Tuesday. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Mon, Sep 15, 2025 at 10:23 AM Lars Hoffmann <lars.hoffmann@icann.org> wrote:
Thanks, Anne.
The protection is about the string itself. So .redcross. As per the paper, the question is now whether confusingly similar strings to .redcross (and all other strings that are explicitly protected at the top level) can be delegated or whether all applied-for string should be evaluated against the reserved list (as they are against the blocked list and already delegated TLDs). While I am not a string similarity evaluator, based on the string similarity evaluation outcomes of the 2012, my educated guess it that .myredcross would pass string similarity (though not sure it’ll pass without GAC advice and/or objections).
I hope this helps.
One important point re: timing. During last week’s call, and as far as I can tell also on list, all but three IRT members believe that Option 1 aligns with the IGO/INGO PDP recommendations. Therefore, I would urge that the Council takes this up as soon as practicable, to ensure we can meet our timeline. Maybe you can work with the co-Chairs to have it added to the agenda for Thursday’s call – I know it’s late in the process but maybe there is a chance? The question to the Council is whether Option 1 aligns with the intent of the IGO/INGO recommendations 3.1.1, 3.1.2, 3.2.1, 3.2.2, 3.3.1, and 3.3.2. *Until/unless the Council weighs in, we are at an impasse between IRT and Org’s interpretation and cannot move forward with Board consideration as planned*.
Best. Lars
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Monday, 15 September 2025 at 18:57 *To: *Michael Karakash <michael.karakash@icann.org> *Cc: *Lars Hoffmann <lars.hoffmann@icann.org>, "Pruis, Elaine" < epruis@verisign.com>, Sarmad Hussain <sarmad.hussain@icann.org>, " ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *Re: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
THanks Michael. In the policy document relative to names which are reserved at the second level, the following language appears:
*3.1. Reserve* means to withhold from registration or to allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available a character string within the TLD.
Does it then follow that at the Top Level, no string applied for at any time could include the actual string that is listed in Reserved Names? For example, is "(dot)myredcross" prohibited by the Top Level Policy on Reserved Names?
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Mon, Sep 15, 2025 at 9:35 AM Michael Karakash < michael.karakash@icann.org> wrote:
Hi Anne,
In the AGB for the strings on the Reserved Names list we say:
“The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in 6.2.2.2 below:
- Names added based on recommendations from the IGO-INGO PDP Working Group regarding the protections of IGO-INGO identifiers in all gTLDs, including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) – International Non-Governmental Organizations (INGO) Names.”
We also include multiple footnotes to clarify the source of the lists (in text).
We can look at the IGO-INGO PDP policy recommendations which is more specific as to what strings are on the Reserved Names lists. The GNSO Council Report to the ICANN Board lays it out clearly in Scope 1 of each recommendation: https://gnso.icann.org/sites/default/files/filefield_43533/council-board-igo... [gnso.icann.org] <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/filefi...>
The recommendations point to the source of the strings (the GAC list), the ECOSOC General Consultative status list maintained by the UN, and the Red Cross/Red Crescent strings. ICANN has also included these strings on the bottom of this page here (Bullets 1 and 2): https://www.icann.org/en/contracted-parties/registry-operators/services/rese... .
Hope this helps and let us know if you have any further questions.
Thank you!
Best,
Michael
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Monday, September 15, 2025 at 8:22 AM *To: *Lars Hoffmann <lars.hoffmann@icann.org> *Cc: *"Pruis, Elaine" <epruis@verisign.com>, Sarmad Hussain < sarmad.hussain@icann.org>, Michael Karakash <michael.karakash@icann.org>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names?
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com> wrote:
Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?)
Again, apologies for my lack of background on this but really need to understand the facts.
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org> wrote:
Hi Anne,
A few answers to your questions in blue below, I am inviting @Sarmad Hussain <sarmad.hussain@icann.org>and @Michael Karakash <michael.karakash@icann.org> to chime in on Monday, too.
Best. Lars
*From: *Anne ICANN via SubPro-IRT <subpro-irt@icann.org> *Reply to: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Saturday, 13 September 2025 at 20:22 *To: *"Pruis, Elaine" <epruis@verisign.com> *Cc: *"ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, " subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[SubPro-IRT] Re: String Similarity Assessment of Reserved Names
Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated.
Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed.
The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed.
Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string?
Yes, there is a clear difference between blocked and reserved names (see above). See also above.
Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not?
Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012.
And do applicants know this when they read the Reserved Names List?
Yes, it is a list that is determined by policy
How is the Reserved Names List determined?
Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... [forum.icann.org] <https://urldefense.com/v3/__https:/forum.icann.org/lists/comments-igo-ingo-i...>
It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct?
Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list.
Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected?
Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can.
I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help.
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com> wrote:
I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross.
ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules.
I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be.
Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross.
Elaine
*From: *Anne ICANN <anneicanngnso@gmail.com> *Date: *Friday, September 12, 2025 at 11:14 AM *To: *Chris Disspain <chris.disspain@identity.digital> *Cc: *Elaine Pruis <epruis@verisign.com>, "ashley.roberts@comlaude.com" < ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org
*Subject: *[EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks Chris, Elaine, and Ashley,
Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity?
Are you saying the policy is:
1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round?
2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded?
Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying?
Still need to listen to the Thursday Zoom on this.
Thank you,
Anne
Anne Aikman-Scalese
GNSO Councilor
NomCom Non-Voting 2022-2026
anneicanngnso@gmail.com
On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT < subpro-irt@icann.org> wrote:
I agree with Ashley and Elaine.
Cheers,
CD
Chris Disspain
+44 7880 642456
On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT < subpro-irt@icann.org> wrote:
Hello
ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check *was limited to the string on the Reserved list and applications for VARIANTS of that string*, as ICANN provided this example in their paper:
re̱dcross vs. redcross
But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs-
So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.)
I agree with Ashely that is not the intention of the policy and we are not to create new policy.
Therefore,
“Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”.
Is the best way forward
Elaine
*From: *Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Ashley Roberts <ashley.roberts@comlaude.com> *Date: *Monday, September 8, 2025 at 9:59 AM *To: *Elisa Busetto <elisa.busetto@icann.org>, "subpro-irt@icann.org" < subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names
*Caution:* This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Elisa and Sarmad,
Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy.
Option 2 proposes to:
- In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. - Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review.
The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and *thus are not part of the string similarity review conducted for names on that list*.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review.
Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.”
Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper.
Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper.
* Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report:
- *New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list.* - *String Ineligible for Delegation:* *A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). *
I hope that makes sense. Please shout if anything in my explanation is unclear.
Kind regards,
Ashley
Ashley Roberts Head of New TLD Consultancy Com Laude *T* +44 (0) 20 7421 8250 *Ext* 264
<image001.png> [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
*Follow us on** LinkedIn [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1q4YfKXzX_bl2ew6J1AA...> * *and** YouTube [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1nfqoNBEIIxsxHS2yJ9Zs6tHwTtrxgNMnucEcQOQetOlWgzn_hcvUbfq5pd917cvS6TS_TslThXSUniGh-ugiNDcFBUoNU6fEwBKFGe_mjI6YIi32YHYpRHncUDwkImjz3MZyC0W6x-nc5VP9a-ld9X9W2LeDkQa-RHbUQEGfzXbHfxrkjlBYTMzA4qDxR-sD_qkHeNZjNkE9VDWras0KhXCdlVCQ70UejeyPoGZs9QVgnHDn8-65KUfxo8svFYGZBd511dmmPxE3zlbgEpvbCrsx15F1SP0NOnVxsM8iLOk/https*3A*2F*2Ft-uk.xink.io*2FTracking*2FIndex*2FbhkAAGVfAADD_RQA0__;JSUlJSUl!!PtGJab4!6kIuEt51tWx3ozk4MWys07lKSI6D2xLVnRS33mUWDbOHOpzfX5oR4o4jDr7NL5bRvvaeDCD067ocYzvL6axCNiMDkudqoQ$>*
*Error! Filename not specified.*
*From:* Elisa Busetto via SubPro-IRT <subpro-irt@icann.org> *Sent:* 05 September 2025 12:10 *To:* subpro-irt@icann.org *Subject:* [SubPro-IRT] String Similarity Assessment of Reserved Names
Hello IRT,
We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/19p0LT0iwpzzYckVQeX0...>
Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list.
Many thanks,
Elisa ------------------------------
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1CAnsWQHLkb7p6WWwbcw...>
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org To unsubscribe send an email to subpro-irt-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1j2v_u7xDhfLmGyNvGwF...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com] <https://urldefense.com/v3/__https:/secure-web.cisco.com/1pNqMOJfh9DBtDVWqss4...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Sorry to be daft, but which strings exactly are reserved at the top level? The list of strings at the link below are in the many hundreds and say (reserved at the second level” Would you kindly paste the top level Reserved List in reply? Thanks. Elaine On Sep 15, 2025, at 6:35 PM, Michael Karakash <michael.karakash@icann.org> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Anne, In the AGB for the strings on the Reserved Names list we say: “The following Limited International IGO-INGOs strings are on the Reserved Names list and may be applied for through an exception process only by the relevant entity, provided it submits appropriate documentation as detailed in 6.2.2.2 below: * Names added based on recommendations from the IGO-INGO PDP Working Group regarding the protections of IGO-INGO identifiers in all gTLDs, including their allocatable variant strings, are eligible for delegation upon verification. These include: Red Cross Red Crescent (RCRC), International Olympic Committee (IOC), and International Governmental Organization (IGO) – International Non-Governmental Organizations (INGO) Names.” We also include multiple footnotes to clarify the source of the lists (in text). We can look at the IGO-INGO PDP policy recommendations which is more specific as to what strings are on the Reserved Names lists. The GNSO Council Report to the ICANN Board lays it out clearly in Scope 1 of each recommendation: https://gnso.icann.org/sites/default/files/filefield_43533/council-board-igo-ingo-23jan14-en.pdf<https://secure-web.cisco.com/1bOSQ8cVhtOxN7bJqx6A6JRyucr9okMcc9GyoSPXzfWAZCJ1nHimAYDfb3skvo1jY0tBPJQ_2bJ_n2a3LGfJxSWiKaTdkw3LGb-Mjq_xmwzGI7IvlzrzUYbk8amUN_ziMdSSatNkbHdCrFXlOsyf-UVYA83L7I7w543naOPvrqKXdWtqnBYoKO9003eRY20ufLJcWFtaHO8SN_leyPhBW3_7uhcgxWG3mHze1H0kSIvkDACqFEB1TG98NWjDJ0rwRxayOg2vidkW8cyJXs9lsHV41V3ID6wv8ivsM56Gt8bw/https%3A%2F%2Fgnso.icann.org%2Fsites%2Fdefault%2Ffiles%2Ffilefield_43533%2Fcouncil-board-igo-ingo-23jan14-en.pdf> The recommendations point to the source of the strings (the GAC list), the ECOSOC General Consultative status list maintained by the UN, and the Red Cross/Red Crescent strings. ICANN has also included these strings on the bottom of this page here (Bullets 1 and 2): https://www.icann.org/en/contracted-parties/registry-operators/services/reserved-names<https://secure-web.cisco.com/1us3RRZeXM0rqjS4-rAZvyl6NG1DjSt3rVitt-8JgzpTkXCukO2Psn1n55FW7nGwlqauqj-QGxJemShqxXbTtsyQm8J00p1Qz3RQTsUpKEKfxu2n4erjl8M87pNQu8Jr5_u5wShSIFZetdii9kZVtqNnrSvQRN-Ws2FgoSF7TbL0sCbnAgpURbDIAc3AT0ARa584nmN-ZstszUoaFrhr-CCwJ5JRFIR8UUFKkle0q7azsINOjuscnzVFeTowjpGWyEj79uPSgnn74vo-M3DRzTSeFvdHj1wP8db_vrWTDMaA/https%3A%2F%2Fwww.icann.org%2Fen%2Fcontracted-parties%2Fregistry-operators%2Fservices%2Freserved-names>. Hope this helps and let us know if you have any further questions. Thank you! Best, Michael From: Anne ICANN <anneicanngnso@gmail.com> Date: Monday, September 15, 2025 at 8:22 AM To: Lars Hoffmann <lars.hoffmann@icann.org> Cc: "Pruis, Elaine" <epruis@verisign.com>, Sarmad Hussain <sarmad.hussain@icann.org>, Michael Karakash <michael.karakash@icann.org>, "ashley.roberts@comlaude.com" <ashley.roberts@comlaude.com>, "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [Ext] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names P.S. Of course I know that we are talking about Top Level Reserved Names whereas the second level names which registries can reserve in the next round are completely different. Just trying to figure out if there are any other Top Level Reserved Names other than these particular IGO/NGO names? Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Mon, Sep 15, 2025 at 8:05 AM Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> wrote: Many thanks Lars - very helpful. Are the IGO/NGO names the ONLY Reserved Names? (I may be confused with second level names that a registry is allowed to reserve - which went from 100 to 500 names in the next round?) Again, apologies for my lack of background on this but really need to understand the facts. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Sat, Sep 13, 2025 at 11:54 AM Lars Hoffmann <lars.hoffmann@icann.org<mailto:lars.hoffmann@icann.org>> wrote: Hi Anne, A few answers to your questions in blue below, I am inviting @Sarmad Hussain<mailto:sarmad.hussain@icann.org>and @Michael Karakash<mailto:michael.karakash@icann.org> to chime in on Monday, too. Best. Lars From: Anne ICANN via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply to: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Saturday, 13 September 2025 at 20:22 To: "Pruis, Elaine" <epruis@verisign.com<mailto:epruis@verisign.com>> Cc: "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Thanks Elaine and staff. Where I am a bit hung up is as follows: I cannot conclude from the approved policy language that no other blocked name policy/procedure will apply to these "protected strings". In other words, I thought that based on past policy re blocked string status (ineligible for delegation), a string that is confusingly similar to a blocked string will not be delegated. Important to bear in mind that blocked names are different to what was referred to as ‘strings not eligible for delegation’ – the former are still called blocked names. these cannot be applied for by anyone, and all applied-for strings will be evaluated against these block names for string similarity. In case an applied-for string is found confusingly similar with a blocked name, the applied-for string cannot proceed. The question of whether reserved names, so names that can only be obtained by a specific organization for which the name has been in fact reserved (and these used to be called ‘strings ineligible for delegation’) should be part of the string similarity evaluation, too, is what is now being discussed. Are we distinguishing between Blocked Names and Reserved Names and saying that Reserved Names are not subject to a policy which prohibits delegation of a similar string? Yes, there is a clear difference between blocked and reserved names (see above). See also above. Generally speaking, is a new string that is judged to be similar to a Reserved Name string ineligible for delegation or not? Reminder that the terminology has changed. A reserved name is what the 2012 AGB referred to as a ‘string ineligible for delegation’. The IGO INGO identifiers are no reserved names and ICANN proposed to evaluate all applied-for strings against the reserved names list as these strings are ‘protected’ per 2013 policy recommendations. The clear majority of the IRT (of those who have spoken up) disagrees with this, arguing that only the exact name is protected and confusingly similar names can be delegated, meaning that applied for strings should NOT be evaluated for string similarity against the reserved names list, because that was the policy in 2012. And do applicants know this when they read the Reserved Names List? Yes, it is a list that is determined by policy How is the Reserved Names List determined? Policy – which, if I recall directly – also built on GAC advice and input from IGO/INGO, e.g., see here the public comment from the Red Cross on the IGO/INGO PDP Initial Report: https://forum.icann.org/lists/comments-igo-ingo-initial-14jun13/msg00000.htm... [forum.icann.org]<https://secure-web.cisco.com/1gFGB4B8b_N3R9mccsBTuO2DbCrxjIC14elSiSOxiiCTrtB...> It sounds as though many IRT participants are saying that Reserved Names do not enjoy any protection from confusingly similar strings. Is that correct? Yes. I would say even that it is a clear majority of those that have spoken up on the call and on list. Or are we saying that Reserved Names are protected against delegation of confusingly similar strings but .redcross, .olympic, etc, are not so protected? Redcross etc. are reserved names because the red cross can apply for .redcross, but no one else can. I could be misunderstanding the deliberations on these "protected organizations" and "protected strings". Definitely need to understand this better. Please help. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Fri, Sep 12, 2025 at 3:46 PM Pruis, Elaine <epruis@verisign.com<mailto:epruis@verisign.com>> wrote: I believe the intention of the policy is to only allow The Red Cross to be the contracted party to operate .redcross. ICANN put forward two options that were developed while considering the policies and establishing the string similarity rules. I do not believe the policy allows for The Red Cross to “block” any applied for string that might “look like” .redcross, which is what the outcome of Option 2 from ICANN would be. Since there has been some discussion on the list since the call, I can support Katrin (and Mike’s) proposal to allow The Red Cross to later acquire .redcross even if there is a similar string delegated in this round. Ie, regardless of string similarity outcomes The Red Cross gets .redcross. Elaine From: Anne ICANN <anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com>> Date: Friday, September 12, 2025 at 11:14 AM To: Chris Disspain <chris.disspain@identity.digital> Cc: Elaine Pruis <epruis@verisign.com<mailto:epruis@verisign.com>>, "ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>" <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] Re: [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks Chris, Elaine, and Ashley, Could you please clarify what you believe to be the intention of the policy? For example, Is it to permit the .redcross string to proceed only if it applied for in the same round as .rodcross (not later) and to allow it to proceed in spite of the string similarity? Are you saying the policy is: 1. .Redcross is permitted to proceed in a concurrent round regardless of Similarity - so both .redcross and .rodcross proceed if applied for in the same round? 2. . Redcross WILL BE SUBJECT to string similarity review and cannot proceed if a prior similar string like .rodcross has in fact been awarded? Is that the policy that protects these names? In other words, the protection applies only if the authorized entity is quick enough? Or am I misunderstanding what you are saying? Still need to listen to the Thursday Zoom on this. Thank you, Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Sep 11, 2025 at 4:53 AM Chris Disspain via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: I agree with Ashley and Elaine. Cheers, CD Chris Disspain +44 7880 642456 <image001.jpg> On 10 Sep 2025, at 16:03, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Hello ICANN’s “Option 2: Reserved Names are protected based on who can apply for them, and also protected against other applied-for strings which are found confusingly similar during String Similarity Evaluation” would make more sense e IF the string similarity check was limited to the string on the Reserved list and applications for VARIANTS of that string, as ICANN provided this example in their paper: re̱dcross vs. redcross But there is no discussion in the proposal about limiting the string similarity check to variants of the reserved TLDs- So rodcross or redcress or redcrocs would be evaluated under Option 2 and most likely not proceed to delegation even if the party the string was reserved for does not apply (…“any similar string to Reserved Name cannot proceed and so cannot be delegated at any time”.) I agree with Ashely that is not the intention of the policy and we are not to create new policy. Therefore, “Option 1: Reserved Names are only protected based on who can apply for them, but go through String Similarity Evaluation like any other applied-for string if it is applied-for. a. Only entities for which Reserved Names are reserved for can apply for them, based on the process noted in AGB. b. Reserved Names will not be given any protection against similar strings”. Is the best way forward Elaine From: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Ashley Roberts <ashley.roberts@comlaude.com<mailto:ashley.roberts@comlaude.com>> Date: Monday, September 8, 2025 at 9:59 AM To: Elisa Busetto <elisa.busetto@icann.org<mailto:elisa.busetto@icann.org>>, "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Re: String Similarity Assessment of Reserved Names Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Elisa and Sarmad, Thanks for summarising the issue and offering two potential solutions. However, I disagree with ICANN’s conclusion that we should adopt option 2, as that would be creating new policy. Option 2 proposes to: * In the case of contention between an IGO/RC/IOC applicant and a non-IGO/RC/IOC applicant, give priority to the IGO/RC/IOC applicant. This would create an entirely new method of priority for resolving contention. * Include the Reserved Names list strings in the standard string similarity review performed by the ICANN evaluators. This is a reversal of the policy from the 2012 round, when Strings Ineligible for Delegation (as Reserved Names were known at the time) were explicitly excluded from the string similarity review. The paper asserts that “…based on remaining recommendations in SubPro and IDN EPDP Phase 1, ICANN proposes to move forward with option 2…”. However, I don’t believe there are any policy recommendations in either SubPro or the IDN EPDP Phase 1 which allow for either of the above rules. The original policy from the 2012 round AGB states in section 2.2.1.2.3 that: “the following [strings ineligible for delegation] names are prohibited from delegation as gTLDs in the initial application round. Future application rounds may differ according to consideration of further policy advice. These names are not being placed on the Top-Level Reserved Names List, and thus are not part of the string similarity review conducted for names on that list.” The SubPro final report affirmed the continuation of the 2012 rules on this topic in Affirmation 24.2: “…the Working Group affirms the standard used in the String Similarity Review from the 2012 round to determine whether an applied-for string is “similar” to any existing TLD, any other applied-for strings, Reserved Names, and in the case of 2-character IDNs, any single character or any 2-character ASCII string.” Note it does not list “strings ineligible for delegation” (i.e. the IGO/RC/IOC names) as a type of string subject to string similarity review. Similarly, section 4.4.1 of the IDN EPDP phase 1 report is clear on the types of name which are subject to string similarity review and “strings ineligible for delegation” are not among them: “If an applied-for primary gTLD string or any of its variant label(s) is confusingly similar to an existing gTLD, an existing ccTLD, a New gTLD Program Reserved Name*, a two-character ASCII string, or any of the variant label(s) of the aforementioned categories of strings, the entire variant label set of the applied-for primary gTLD string will be ineligible to proceed in the application process.” Thus, implementing the two above rules proposed by option 2 would be creating new policy, which is not the job of the IRT. Whereas option 2 would create new policy, the path outlined in option 1 is consistent with existing policy. Therefore, option 1 is the only viable option outlined in your paper. Please note that both the SubPro and EPDP final reports use the old definition of “Reserved Names”, which is a little confusing. In those reports, the relevant term to describe the IOC/RC/IOC names is “strings ineligible for delegation”. For clarity and completeness you may want to make this clear in the annex of your paper. * Definitions of New gTLD Program Reserved Names and Strings Ineligible for Delegation, used by the IDN EPDP per their Final Report: * New gTLD Program Reserved Name: A string that is reserved to maintain the exclusive rights to the names of ICANN, its bodies, or essential related functions of ICANN and IANA. For a full list of New gTLD Program Reserved Names, see Section 2.2.1.2.1 of the 2012 Applicant Guidebook. In addition, the SubPro PDP recommended adding “PTI” to the New gTLD Program Reserved Names list. * String Ineligible for Delegation: A string that is ineligible for delegation in order to provide special protections at the top-level and second-level for the names and acronyms of intergovernmental organizations (IGOs) and international non-governmental organizations (INGOs) which receive protections under treaties and statutes across multiple jurisdictions. Those organizations specifically include the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (IOC). I hope that makes sense. Please shout if anything in my explanation is unclear. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 <image001.png> [secure-web.cisco.com]<https://secure-web.cisco.com/19x6MsWavSn1yMhYQcuR_U0qNsNq0I7So04uqMcwSrwwzoS...> Follow us on LinkedIn [secure-web.cisco.com]<https://secure-web.cisco.com/1NEyu6gxutkaKmInTpRBgf66cLknBZY9PRH3IEhrA776t07...> and YouTube [secure-web.cisco.com]<https://secure-web.cisco.com/1qAnacD7ffLqxsatvIb-bhzQh2uJABMlOz59EiWVqHX7i18...> Error! Filename not specified. From: Elisa Busetto via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: 05 September 2025 12:10 To: subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] String Similarity Assessment of Reserved Names Hello IRT, We have just published a paper concerning the String Similarity Assessment of Reserved Names on the wiki page of meeting #158a: https://icann-community.atlassian.net/wiki/x/AQB3Gw [secure-web.cisco.com]<https://secure-web.cisco.com/1ct049Njp8TEx0FWNd1fosrRffX39c_3D085FgmTV0pDpL3...> Sarmad will go through it during the call, but it would be appreciated if you could already review it and provide any input you may have on list. Many thanks, Elisa ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that Com Laude Group Limited (the “Com Laude Group”) does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group is a limited company registered in England and Wales with company number 10689074 and registered office at 28 Little Russell Street, London, WC1A 2HN England. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 6181291 and registered office at 28 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176 and registered office at 15 William Street, South West Lane, Edinburgh, EH3 7LL Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, a corporation incorporated in the State of Washington and principal office address at Suite 332, Securities Building, 1904 Third Ave, Seattle, WA 98101; Com Laude (Japan) Corporation, a company registered in Japan with company number 0100-01-190853 and registered office at 1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan; Com Laude Domain ESP S.L.U., a company registered in Spain and registered office address at Calle Barcas 2, 2, Valencia, 46002, Spain. For further information see www.comlaude.com [secure-web.cisco.com]<https://secure-web.cisco.com/19x6MsWavSn1yMhYQcuR_U0qNsNq0I7So04uqMcwSrwwzoS...> _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://secure-web.cisco.com/1BNghtlRjM93GXV_hywhHLF3tZRDQ09RpCYgh25raDbCTwp...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://secure-web.cisco.com/1HpVDa9Lgw4tJDHBwKhGQ_NZOzpSSi9-59iN5c3cu8akQGc...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ SubPro-IRT mailing list -- subpro-irt@icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave@icann.org<mailto:subpro-irt-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy [secure-web.cisco.com]<https://secure-web.cisco.com/1BNghtlRjM93GXV_hywhHLF3tZRDQ09RpCYgh25raDbCTwp...>) and the website Terms of Service (https://www.icann.org/privacy/tos [secure-web.cisco.com]<https://secure-web.cisco.com/1HpVDa9Lgw4tJDHBwKhGQ_NZOzpSSi9-59iN5c3cu8akQGc...>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
participants (7)
-
Anne ICANN -
Chris Disspain -
Jeffrey J. Neuman -
Lars Hoffmann -
Michael Karakash -
Next Round Policy Implementation -
Pruis, Elaine