Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). Example: The DNS root managed by ICANN is the “main” namespace. An alternative namespace might be www.Facebook.com/first-lastname, a twitter handle, etc Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. Example: Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. They each define their own namespace (like .bit for Namecoin, .eth for ENS). Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca.... NCAP Study 1 Report first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. Operational instability for network operators and end-users. User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Reply-To: Jared Erwin <jared.erwin@icann.org> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrN... The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_... Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org
For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3 [https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-e...] and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots] [http://www.dnso.org/clubpublic/ga-roots/Arc00/msg00277.html] Lets not deviate from our exiting policy. Sincerely, Jeff On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment [https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...] (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck [https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025-...]: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra [https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra] m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname [http://www.Facebook.com/first-lastname], a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca... [https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca...]. NCAP Study 1 Report [file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf] first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example [http://www.example] in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example [http://www.example], it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Reply-To: Jared Erwin <jared.erwin@icann.org> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here [https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...]. * The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrN... [https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaX...] * The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_... [https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1R...] Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org [mailto:jared.erwin@icann.org] _______________________________________________ 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. [548ac733-2421-44e9-9a98-4bc13798309b]
Thank you to both Elaine & Jeff for their accurate summations of these positions with which I solidly agree. Respectfully, Karen [cid:b3f2f503-bf81-4bff-8b11-07d09c18906e] Karen L. Day DNS Industry Advisor Elster & McGrady LLC Phone: +1 (984) 335-4067 Email: karen@elstermcgrady.com www.elstermcgrady.com<http://www.elstermcgrady.com/> ________________________________ From: Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> Sent: Thursday, August 21, 2025 9:37 AM To: Pruis, Elaine <epruis@verisign.com>; Jared Erwin <jared.erwin@icann.org>; subpro-irt@icann.org <subpro-irt@icann.org> Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3<https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-e...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots]<http://www.dnso.org/clubpublic/ga-roots/Arc00/msg00277.html> Lets not deviate from our exiting policy. Sincerely, Jeff [https://ci3.googleusercontent.com/meips/ADKq_Na0au3lFoPoPHrWAj8ua-8sA0Kn20-5...] On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment<https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025-...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname<http://www.facebook.com/first-lastname>, a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca.... NCAP Study 1 Report<file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example<http://www.example/> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example<http://www.example/>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Reply-To: Jared Erwin <jared.erwin@icann.org> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here<https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...>. 1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0<https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaXVMYDPhjbEh20lK1MD2emp1xFUbn-uo84JOXyF4PRFYu43pSiKkitABn7WX2N-DIl9P5GY2MzETTovG2-L6jPN7j6CbWSYOdr3kFpDSvxonne0ucxMO68OaCHJ6SMV5sDIk9UOoo6Og1Ktc2MzINI-cPkzFaLtx6HyduNfZsYPk5lHmX5ZrBAeCrHvejef-KkTt8g0W3sFIVzfaZPplxnKskq3M-69D837b7gi8izzsHJ6h2sH0AQtrRcfOxlA/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc%2Fedit%3Ftab%3Dt.0> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE/edit?tab=t.0<https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1Rk62WIaY4J57sV8n_X3P9GCEej6kXniLcgxUJLrV5EdkU2wXQTVFLfnU81fJwmr4ytS1fMOxA6yBvCehgssoAyLeIUdZf5xmcpu11n6vn3l0mhzUmtcNTtyBOCAf1zOe2TzBKlOwedXvClPxyv4X9eJ9cQBebVP4hsrcLN7BASoSc6Xd6-HS5Ehq3XFPGgFckVrjC_ySjc4mhOxfexkLXXfWYBYbVt328nPY1YbIAJ54iNdF4Uth_EquJlK0sQ/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE%2Fedit%3Ftab%3Dt.0> Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ 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. This email originated from outside the firm. Please use caution.
I fully agree with Elaine’s and other’s comments that naming systems other than the DNS should not be in scope for the TRT’s name collision assessment and thus, the SSAC’s recommendation 3 comment should be rejected. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 [cid:image001.png@01DC135C.9170CCC0] <https://comlaude.com/> Follow us on LinkedIn<https://t-uk.xink.io/Tracking/Index/pRkAAGVfAADD_RQA0> and YouTube<https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADD_RQA0> Summer Bank Holiday (25th of August) Due to the public holiday, the Com Laude Group UK offices will be closed on Monday 25 August 2025. Please send your urgent requests to admin@comlaude.com as this is the email box which the team providing cover will be checking and don't forget to copy in your Domain Strategists. We will also continue to provide 24/7 monitoring of our services and servers and emergency cover in the event that you have a critical requirement outside of our "follow the sun" office hours. Please call our emergency helpline on one of the following numbers in such circumstances - UK: +44. (0) 208 213 5922, USA: +1 2064877683 From: Karen Day via SubPro-IRT <subpro-irt@icann.org> Sent: 21 August 2025 14:52 To: Pruis, Elaine <epruis@verisign.com>; Jared Erwin <jared.erwin@icann.org>; subpro-irt@icann.org; Jeffrey J. Neuman <jeff@jjnsolutions.com> Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC Thank you to both Elaine & Jeff for their accurate summations of these positions with which I solidly agree. Respectfully, Karen [cid:image002.png@01DC135C.9170CCC0] Karen L. Day DNS Industry Advisor Elster & McGrady LLC Phone: +1 (984) 335-4067 Email: karen@elstermcgrady.com<mailto:karen@elstermcgrady.com> www.elstermcgrady.com<http://www.elstermcgrady.com/> ________________________________ From: Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: Thursday, August 21, 2025 9:37 AM To: Pruis, Elaine <epruis@verisign.com<mailto:epruis@verisign.com>>; Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>>; subpro-irt@icann.org<mailto:subpro-irt@icann.org> <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3<https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-e...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots]<http://www.dnso.org/clubpublic/ga-roots/Arc00/msg00277.html> Lets not deviate from our exiting policy. Sincerely, Jeff [https://ci3.googleusercontent.com/meips/ADKq_Na0au3lFoPoPHrWAj8ua-8sA0Kn20-5...] On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment<https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025-...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname<http://www.facebook.com/first-lastname>, a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca.... NCAP Study 1 Report<file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example<http://www.example/> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example<http://www.example/>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here<https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...>. 1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0<https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaXVMYDPhjbEh20lK1MD2emp1xFUbn-uo84JOXyF4PRFYu43pSiKkitABn7WX2N-DIl9P5GY2MzETTovG2-L6jPN7j6CbWSYOdr3kFpDSvxonne0ucxMO68OaCHJ6SMV5sDIk9UOoo6Og1Ktc2MzINI-cPkzFaLtx6HyduNfZsYPk5lHmX5ZrBAeCrHvejef-KkTt8g0W3sFIVzfaZPplxnKskq3M-69D837b7gi8izzsHJ6h2sH0AQtrRcfOxlA/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc%2Fedit%3Ftab%3Dt.0> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE/edit?tab=t.0<https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1Rk62WIaY4J57sV8n_X3P9GCEej6kXniLcgxUJLrV5EdkU2wXQTVFLfnU81fJwmr4ytS1fMOxA6yBvCehgssoAyLeIUdZf5xmcpu11n6vn3l0mhzUmtcNTtyBOCAf1zOe2TzBKlOwedXvClPxyv4X9eJ9cQBebVP4hsrcLN7BASoSc6Xd6-HS5Ehq3XFPGgFckVrjC_ySjc4mhOxfexkLXXfWYBYbVt328nPY1YbIAJ54iNdF4Uth_EquJlK0sQ/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE%2Fedit%3Ftab%3Dt.0> Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ 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. This email originated from outside the firm. Please use caution. ________________________________ 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://comlaude.com/>
Jeff and Elaine, Just for clarity, operating systems and networks could constitute alternate naming spaces as they are basically infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data within such operating system or network, right? If so, then weren’t alternate name spaces taken into account for name collision purposes in the first round as that is the basis for the determination that .home and .corp (and others) presented a high risk of name collision because they are used in operating systems and networks and also had a high volume of queries at the DNS root which leaked out of the OS or network? How would it be any different if there was a high level of queries that leaked out from web3/blockchain TLDs in the DNS root? I am not taking a position on what should be considered or not at this time but just seeking clarity so that I (and others) understand and to aid in the discussion. Best regards, Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 360 North Green Street | Suite 1300 | Chicago, IL 60607 T +1 312.456.1020 M +1 773.677.3305 trac@gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig Logo] [Greenberg Traurig Logo] From: Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> Sent: Thursday, August 21, 2025 8:37 AM To: Pruis, Elaine <epruis@verisign.com>; Jared Erwin <jared.erwin@icann.org>; subpro-irt@icann.org Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC *EXTERNAL TO GT* For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/unique-auth...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots]<https://urldefense.com/v3/__http:/www.dnso.org/clubpublic/ga-roots/Arc00/msg...> Lets not deviate from our exiting policy. Sincerely, Jeff [cid:image003.png@01DC127B.F783CE40] On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment<https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/security-and-s...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/spaces...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra<https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/policy-development/new-gtld-progra__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarm47Q5Mng$> m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname<https://urldefense.com/v3/__http:/www.Facebook.com/first-lastname__;!!DUT_TF...>, a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarmjD4rSJ8$>. NCAP Study 1 Report<file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example<https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example<https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here<https://urldefense.com/v3/__https:/secure-web.cisco.com/1XTscfb4Zxbv5y6___al...>. 1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0<https://urldefense.com/v3/__https:/secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaXVMYDPhjbEh20lK1MD2emp1xFUbn-uo84JOXyF4PRFYu43pSiKkitABn7WX2N-DIl9P5GY2MzETTovG2-L6jPN7j6CbWSYOdr3kFpDSvxonne0ucxMO68OaCHJ6SMV5sDIk9UOoo6Og1Ktc2MzINI-cPkzFaLtx6HyduNfZsYPk5lHmX5ZrBAeCrHvejef-KkTt8g0W3sFIVzfaZPplxnKskq3M-69D837b7gi8izzsHJ6h2sH0AQtrRcfOxlA/https*3A*2F*2Fdocs.google.com*2Fdocument*2Fd*2F1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc*2Fedit*3Ftab*3Dt.0__;JSUlJSUlJSUl!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarmKm-tsS8$> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE/edit?tab=t.0<https://urldefense.com/v3/__https:/secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1Rk62WIaY4J57sV8n_X3P9GCEej6kXniLcgxUJLrV5EdkU2wXQTVFLfnU81fJwmr4ytS1fMOxA6yBvCehgssoAyLeIUdZf5xmcpu11n6vn3l0mhzUmtcNTtyBOCAf1zOe2TzBKlOwedXvClPxyv4X9eJ9cQBebVP4hsrcLN7BASoSc6Xd6-HS5Ehq3XFPGgFckVrjC_ySjc4mhOxfexkLXXfWYBYbVt328nPY1YbIAJ54iNdF4Uth_EquJlK0sQ/https*3A*2F*2Fdocs.google.com*2Fdocument*2Fd*2F1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE*2Fedit*3Ftab*3Dt.0__;JSUlJSUlJSUl!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarmx-MTqeM$> Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ 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<https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarm2KU5KyI$>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarm2nn6U3M$>). 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. ---------------------------------------------------------------------- If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate the information.
Marc, I think you answered your own question. There is a difference between naming systems that leak into the DNS and naming spaces which do not. In other words, right now if you look at the root zone data (https://magnitude.research.icann.org/ [https://magnitude.research.icann.org/]), you will not find terms like wallet, crypto, blockchain, btc, etc. There may be millions of "registrations" in these namespaces, but the resolvers for those namespaces have not leaked into the DNS and therefore, should not be considered as "name collisions." If they start leaking into DNS now, we know that such leakage is likely "intentional" to try and game the system (which is one of the qualitative factors that should be looked at by ICANN to figure out whether there is real harm or risk). In short, name collision based on SYSTEMS misconfigured that leak traffic into the DNS root, is very different than considering the fact that there are millions of names in alternate naming systems that do not impact DNS traffic at all. So the Technical Review Team should not consider at all that there may be 1,000,000 names "registered" in an alternate space. But if the resolver system has caused leakage into DNS, then that MAY be considered (but looking at qualitative factors as to why that leakage is occurring). On 8/21/2025 10:14:47 AM, trachtenbergm@gtlaw.com <trachtenbergm@gtlaw.com> wrote: Jeff and Elaine, Just for clarity, operating systems and networks could constitute alternate naming spaces as they are basically infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data within such operating system or network, right? If so, then weren’t alternate name spaces taken into account for name collision purposes in the first round as that is the basis for the determination that .home and .corp (and others) presented a high risk of name collision because they are used in operating systems and networks and also had a high volume of queries at the DNS root which leaked out of the OS or network? How would it be any different if there was a high level of queries that leaked out from web3/blockchain TLDs in the DNS root? I am not taking a position on what should be considered or not at this time but just seeking clarity so that I (and others) understand and to aid in the discussion. Best regards, Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 360 North Green Street | Suite 1300 | Chicago, IL 60607 T +1 312.456.1020 M +1 773.677.3305 trac@gtlaw.com [mailto:trachtenbergm@gtlaw.com] | www.gtlaw.com [http://www.gtlaw.com/] | View GT Biography [https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h] [Greenberg Traurig Logo] [Greenberg Traurig Logo] From: Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> Sent: Thursday, August 21, 2025 8:37 AM To: Pruis, Elaine <epruis@verisign.com>; Jared Erwin <jared.erwin@icann.org>; subpro-irt@icann.org Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC *EXTERNAL TO GT* For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3 [https://urldefense.com/v3/__https:/www.icann.org/resources/pages/unique-auth...] and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots] [https://urldefense.com/v3/__http:/www.dnso.org/clubpublic/ga-roots/Arc00/msg...] Lets not deviate from our exiting policy. Sincerely, Jeff On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment [https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/security-and-s...] (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck [https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/spaces...]: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra [https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/policy-develop...] m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname [https://urldefense.com/v3/__http:/www.Facebook.com/first-lastname__;!!DUT_TF...], a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca... [https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/downlo...]. NCAP Study 1 Report [file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf] first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example [https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...] in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example [https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...], it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Reply-To: Jared Erwin <jared.erwin@icann.org [mailto:jared.erwin@icann.org]> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org [mailto:subpro-irt@icann.org]" <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here [https://urldefense.com/v3/__https:/secure-web.cisco.com/1XTscfb4Zxbv5y6___al...]. * The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrN... [https://urldefense.com/v3/__https:/secure-web.cisco.com/1enaeKYppeVkZojS2Tyv...] * The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_... [https://urldefense.com/v3/__https:/secure-web.cisco.com/1QQniTGIPK1FGCtJxkji...] Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org [mailto:jared.erwin@icann.org] _______________________________________________ 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 [https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DUT_TFPx...]) and the website Terms of Service (https://www.icann.org/privacy/tos [https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DUT_TFPxUQ!...]). 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. [548ac733-2421-44e9-9a98-4bc13798309b] If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate the information. [ecbacd3b-c332-4a0e-82b3-fd8e96941527]
Thanks Jeff. Is there any way for applicants to measure whether a particular string would carry a high risk of alternate naming systems leaking traffic into the DNS root before applying for that string? How would the applicant's technical people (or RSP) be able to estimate this? (It seems that evaluating that risk might be an element of any reasonable risk management aspect of a business plan.) Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com On Thu, Aug 21, 2025 at 8:03 AM Jeffrey J. Neuman via SubPro-IRT < subpro-irt@icann.org> wrote:
Marc,
I think you answered your own question. There is a difference between naming systems that leak into the DNS and naming spaces which do not. In other words, right now if you look at the root zone data ( https://magnitude.research.icann.org/), you will not find terms like wallet, crypto, blockchain, btc, etc. There may be millions of "registrations" in these namespaces, but the resolvers for those namespaces have not leaked into the DNS and therefore, should not be considered as "name collisions." If they start leaking into DNS now, we know that such leakage is likely "intentional" to try and game the system (which is one of the qualitative factors that should be looked at by ICANN to figure out whether there is real harm or risk).
In short, name collision based on SYSTEMS misconfigured that leak traffic into the DNS root, is very different than considering the fact that there are millions of names in alternate naming systems that do not impact DNS traffic at all. So the Technical Review Team should not consider at all that there may be 1,000,000 names "registered" in an alternate space. But if the resolver system has caused leakage into DNS, then that MAY be considered (but looking at qualitative factors as to why that leakage is occurring).
On 8/21/2025 10:14:47 AM, trachtenbergm@gtlaw.com <trachtenbergm@gtlaw.com> wrote:
Jeff and Elaine,
Just for clarity, operating systems and networks could constitute alternate naming spaces as they are basically infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data within such operating system or network, right? If so, then weren’t alternate name spaces taken into account for name collision purposes in the first round as that is the basis for the determination that .home and .corp (and others) presented a high risk of name collision because they are used in operating systems and networks and also had a high volume of queries at the DNS root which leaked out of the OS or network? How would it be any different if there was a high level of queries that leaked out from web3/blockchain TLDs in the DNS root? I am not taking a position on what should be considered or not at this time but just seeking clarity so that I (and others) understand and to aid in the discussion.
Best regards,
*Marc H. Trachtenberg * Shareholder
Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 360 North Green Street | Suite 1300 | Chicago, IL 60607 T +1 312.456.1020
M +1 773.677.3305 trac@gtlaw.com <trachtenbergm@gtlaw.com> | www.gtlaw.com | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h>
[image: Greenberg Traurig Logo]
[image: Greenberg Traurig Logo]
*From:* Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> *Sent:* Thursday, August 21, 2025 8:37 AM *To:* Pruis, Elaine <epruis@verisign.com>; Jared Erwin < jared.erwin@icann.org>; subpro-irt@icann.org *Subject:* [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
**EXTERNAL TO GT**
For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round.
For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP.
Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3 <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/unique-auth...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate.
This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD.
Here is the link to that email: DNSO Archives: [ga-roots] <https://urldefense.com/v3/__http:/www.dnso.org/clubpublic/ga-roots/Arc00/msg...>
Lets not deviate from our exiting policy.
Sincerely,
Jeff
On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT < subpro-irt@icann.org> wrote:
Dear IRT / ICANN
In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment <https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/security-and-s...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response).
*1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision *(per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) *and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS.*
*Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, *as requested in *SSAC130 Recommendation 3: *“The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.”
*ICANN’s initial response* in the IRT deck <https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/spaces...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.”
https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra <https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/policy-develop...> m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191
*NOTE:* Name Space and Name System are not the same and should not be used interchangeably:
* Alternative Name **Space*
- *Definition*: A *name space* is the set of all possible names under a given naming scheme. An *alternative name space* is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). - *Example*:
- The DNS root managed by ICANN is the “main” namespace. - An alternative namespace might be www.Facebook.com/first-lastname <https://urldefense.com/v3/__http:/www.Facebook.com/first-lastname__;!!DUT_TF...>, a twitter handle, etc
- *Key Point*: It’s about the *collection of names* and their structure, regardless of how they’re resolved.
*Alternative Name **System*
- *Definition*: A *name system* is the actual *infrastructure, protocols, and mechanisms* used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). - An *alternative name system* is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. - *Example*:
- Namecoin, ENS (Ethereum Name Service), and Handshake are *alternative name systems*, each with their own rules and technical protocols. - They each define their *own namespace* (like .bit for Namecoin, .eth for ENS).
- *Purpose*: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. - *Key Point*: It’s about the *system that manages, resolves, and governs* the namespace.
From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions*, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems*. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).”
*2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made.*
I believe SSAC’s comment above seem to be referring to their Study 2 Report definition:
*Name collisions are defined in NCAP2 as follows*: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2
Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30:
42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca... <https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/downlo...> .
NCAP Study 1 Report first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example <https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example <https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM)
3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3.
The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope.
*SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems:*
SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems:
- Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. - Operational instability for network operators and end-users. - User confusion due to unpredictable resolution behavior.
The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.”
*The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. *
Elaine
*From: *Jared Erwin via SubPro-IRT <subpro-irt@icann.org> *Reply-To: *Jared Erwin <jared.erwin@icann.org> *Date: *Tuesday, August 19, 2025 at 3:19 PM *To: *"subpro-irt@icann.org" <subpro-irt@icann.org> *Subject: *[EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
*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.
Dear IRT Members,
The deck for tomorrow’s call can be found on the meeting page here <https://urldefense.com/v3/__https:/secure-web.cisco.com/1XTscfb4Zxbv5y6___al...>.
1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrN... <https://urldefense.com/v3/__https:/secure-web.cisco.com/1enaeKYppeVkZojS2Tyv...> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_... <https://urldefense.com/v3/__https:/secure-web.cisco.com/1QQniTGIPK1FGCtJxkji...>
Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments.
Thank you,
Jared
--
Jared Erwin
Senior Director, New gTLD Program
Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)
jared.erwin@icann.org
_______________________________________________ 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://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DUT_TFPx...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DUT_TFPxUQ!...>). 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.
[image: 548ac733-2421-44e9-9a98-4bc13798309b] ------------------------------ If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com, and do not use or disseminate the information.
[image: ecbacd3b-c332-4a0e-82b3-fd8e96941527] _______________________________________________ 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.
You can't predict it, because it is based on someone misconfiguring resolvers in the alternate naming systems to somehow leak into the DNS, which none have to date done in any real manner (if you look at ICANN's reports of its own zone file data). On 8/21/2025 11:16:30 AM, Anne ICANN <anneicanngnso@gmail.com> wrote: Thanks Jeff. Is there any way for applicants to measure whether a particular string would carry a high risk of alternate naming systems leaking traffic into the DNS root before applying for that string? How would the applicant's technical people (or RSP) be able to estimate this? (It seems that evaluating that risk might be an element of any reasonable risk management aspect of a business plan.) Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso@gmail.com [mailto:anneicanngnso@gmail.com] On Thu, Aug 21, 2025 at 8:03 AM Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> wrote: Marc, I think you answered your own question. There is a difference between naming systems that leak into the DNS and naming spaces which do not. In other words, right now if you look at the root zone data (https://magnitude.research.icann.org/ [https://magnitude.research.icann.org/]), you will not find terms like wallet, crypto, blockchain, btc, etc. There may be millions of "registrations" in these namespaces, but the resolvers for those namespaces have not leaked into the DNS and therefore, should not be considered as "name collisions." If they start leaking into DNS now, we know that such leakage is likely "intentional" to try and game the system (which is one of the qualitative factors that should be looked at by ICANN to figure out whether there is real harm or risk). In short, name collision based on SYSTEMS misconfigured that leak traffic into the DNS root, is very different than considering the fact that there are millions of names in alternate naming systems that do not impact DNS traffic at all. So the Technical Review Team should not consider at all that there may be 1,000,000 names "registered" in an alternate space. But if the resolver system has caused leakage into DNS, then that MAY be considered (but looking at qualitative factors as to why that leakage is occurring). On 8/21/2025 10:14:47 AM, trachtenbergm@gtlaw.com [mailto:trachtenbergm@gtlaw.com] <trachtenbergm@gtlaw.com [mailto:trachtenbergm@gtlaw.com]> wrote: Jeff and Elaine, Just for clarity, operating systems and networks could constitute alternate naming spaces as they are basically infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data within such operating system or network, right? If so, then weren’t alternate name spaces taken into account for name collision purposes in the first round as that is the basis for the determination that .home and .corp (and others) presented a high risk of name collision because they are used in operating systems and networks and also had a high volume of queries at the DNS root which leaked out of the OS or network? How would it be any different if there was a high level of queries that leaked out from web3/blockchain TLDs in the DNS root? I am not taking a position on what should be considered or not at this time but just seeking clarity so that I (and others) understand and to aid in the discussion. Best regards, Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 360 North Green Street | Suite 1300 | Chicago, IL 60607 T +1 312.456.1020 M +1 773.677.3305 trac@gtlaw.com [mailto:trachtenbergm@gtlaw.com] | www.gtlaw.com [http://www.gtlaw.com/] | View GT Biography [https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h] [Greenberg Traurig Logo] [Greenberg Traurig Logo] From: Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Sent: Thursday, August 21, 2025 8:37 AM To: Pruis, Elaine <epruis@verisign.com [mailto:epruis@verisign.com]>; Jared Erwin <jared.erwin@icann.org [mailto:jared.erwin@icann.org]>; subpro-irt@icann.org [mailto:subpro-irt@icann.org] Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC *EXTERNAL TO GT* For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3 [https://urldefense.com/v3/__https:/www.icann.org/resources/pages/unique-auth...] and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots] [https://urldefense.com/v3/__http:/www.dnso.org/clubpublic/ga-roots/Arc00/msg...] Lets not deviate from our exiting policy. Sincerely, Jeff On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment [https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/security-and-s...] (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck [https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/spaces...]: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra [https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/policy-develop...] m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname [https://urldefense.com/v3/__http:/www.Facebook.com/first-lastname__;!!DUT_TF...], a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca... [https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/downlo...]. NCAP Study 1 Report first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example [https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...] in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example [https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...], it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Reply-To: Jared Erwin <jared.erwin@icann.org [mailto:jared.erwin@icann.org]> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org [mailto:subpro-irt@icann.org]" <subpro-irt@icann.org [mailto:subpro-irt@icann.org]> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here [https://urldefense.com/v3/__https:/secure-web.cisco.com/1XTscfb4Zxbv5y6___al...]. * The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrN... [https://urldefense.com/v3/__https:/secure-web.cisco.com/1enaeKYppeVkZojS2Tyv...] * The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_... [https://urldefense.com/v3/__https:/secure-web.cisco.com/1QQniTGIPK1FGCtJxkji...] Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org [mailto:jared.erwin@icann.org] _______________________________________________ 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 [https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DUT_TFPx...]) and the website Terms of Service (https://www.icann.org/privacy/tos [https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DUT_TFPxUQ!...]). 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. [548ac733-2421-44e9-9a98-4bc13798309b] If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com [mailto:postmaster@gtlaw.com], and do not use or disseminate the information. [ecbacd3b-c332-4a0e-82b3-fd8e96941527] _______________________________________________ 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 [https://www.icann.org/privacy/policy]) and the website Terms of Service (https://www.icann.org/privacy/tos [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. [516bd902-c41e-466f-b4a1-f3a8082470a0]
Jeff, If there is no material volume of queries in the DNS for web3 TLDs – which appears to be the case at least for the most well-known ones based on the Magnitude numbers – then I think I agree this should not be considered. Best regards, Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 360 North Green Street | Suite 1300 | Chicago, IL 60607 T +1 312.456.1020 M +1 773.677.3305 trac@gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig Logo] [Greenberg Traurig Logo] From: Jeffrey J. Neuman <jeff@jjnsolutions.com> Sent: Thursday, August 21, 2025 10:03 AM To: Trachtenberg, Marc H. (Shld-Chi-IP-Tech) <trachtenbergm@gtlaw.com>; Pruis, Elaine <epruis@verisign.com>; Jared Erwin <jared.erwin@icann.org>; subpro-irt@icann.org Subject: RE: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC Marc, I think you answered your own question. There is a difference between naming systems that leak into the DNS and naming spaces which do not. In other words, right now if you look at the root zone data (https://magnitude.research.icann.org/<https://urldefense.com/v3/__https:/magnitude.research.icann.org/__;!!DUT_TFPxUQ!GrBxuMmysspofGweLqkKgUsVoqwDqS-EY_DbovJ-n55WiY_2O1HXNfd3CRkN5suM2IhDWRxAARS3EkioUfNb$>), you will not find terms like wallet, crypto, blockchain, btc, etc. There may be millions of "registrations" in these namespaces, but the resolvers for those namespaces have not leaked into the DNS and therefore, should not be considered as "name collisions." If they start leaking into DNS now, we know that such leakage is likely "intentional" to try and game the system (which is one of the qualitative factors that should be looked at by ICANN to figure out whether there is real harm or risk). In short, name collision based on SYSTEMS misconfigured that leak traffic into the DNS root, is very different than considering the fact that there are millions of names in alternate naming systems that do not impact DNS traffic at all. So the Technical Review Team should not consider at all that there may be 1,000,000 names "registered" in an alternate space. But if the resolver system has caused leakage into DNS, then that MAY be considered (but looking at qualitative factors as to why that leakage is occurring). [cid:image003.png@01DC1287.978764F0] On 8/21/2025 10:14:47 AM, trachtenbergm@gtlaw.com<mailto:trachtenbergm@gtlaw.com> <trachtenbergm@gtlaw.com<mailto:trachtenbergm@gtlaw.com>> wrote: Jeff and Elaine, Just for clarity, operating systems and networks could constitute alternate naming spaces as they are basically infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data within such operating system or network, right? If so, then weren’t alternate name spaces taken into account for name collision purposes in the first round as that is the basis for the determination that .home and .corp (and others) presented a high risk of name collision because they are used in operating systems and networks and also had a high volume of queries at the DNS root which leaked out of the OS or network? How would it be any different if there was a high level of queries that leaked out from web3/blockchain TLDs in the DNS root? I am not taking a position on what should be considered or not at this time but just seeking clarity so that I (and others) understand and to aid in the discussion. Best regards, Marc H. Trachtenberg Shareholder Chair, Internet, Domain Name, e-Commerce and Social Media Practice Greenberg Traurig, LLP 360 North Green Street | Suite 1300 | Chicago, IL 60607 T +1 312.456.1020 M +1 773.677.3305 trac@gtlaw.com<mailto:trachtenbergm@gtlaw.com> | www.gtlaw.com<http://www.gtlaw.com/> | View GT Biography <https://www.gtlaw.com/en/professionals/t/trachtenberg-marc-h> [Greenberg Traurig Logo] [Greenberg Traurig Logo] From: Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Sent: Thursday, August 21, 2025 8:37 AM To: Pruis, Elaine <epruis@verisign.com<mailto:epruis@verisign.com>>; Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>>; subpro-irt@icann.org<mailto:subpro-irt@icann.org> Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC *EXTERNAL TO GT* For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/unique-auth...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots]<https://urldefense.com/v3/__http:/www.dnso.org/clubpublic/ga-roots/Arc00/msg...> Lets not deviate from our exiting policy. Sincerely, Jeff [cid:image003.png@01DC1287.978764F0] On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment<https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/security-and-s...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/spaces...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra<https://urldefense.com/v3/__https:/itp.cdn.icann.org/en/files/policy-development/new-gtld-progra__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarm47Q5Mng$> m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname<https://urldefense.com/v3/__http:/www.Facebook.com/first-lastname__;!!DUT_TF...>, a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarmjD4rSJ8$>. NCAP Study 1 Report<file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example<https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example<https://urldefense.com/v3/__http:/www.example__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mB...>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here<https://urldefense.com/v3/__https:/secure-web.cisco.com/1XTscfb4Zxbv5y6___al...>. 1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0<https://urldefense.com/v3/__https:/secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaXVMYDPhjbEh20lK1MD2emp1xFUbn-uo84JOXyF4PRFYu43pSiKkitABn7WX2N-DIl9P5GY2MzETTovG2-L6jPN7j6CbWSYOdr3kFpDSvxonne0ucxMO68OaCHJ6SMV5sDIk9UOoo6Og1Ktc2MzINI-cPkzFaLtx6HyduNfZsYPk5lHmX5ZrBAeCrHvejef-KkTt8g0W3sFIVzfaZPplxnKskq3M-69D837b7gi8izzsHJ6h2sH0AQtrRcfOxlA/https*3A*2F*2Fdocs.google.com*2Fdocument*2Fd*2F1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc*2Fedit*3Ftab*3Dt.0__;JSUlJSUlJSUl!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarmKm-tsS8$> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE/edit?tab=t.0<https://urldefense.com/v3/__https:/secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1Rk62WIaY4J57sV8n_X3P9GCEej6kXniLcgxUJLrV5EdkU2wXQTVFLfnU81fJwmr4ytS1fMOxA6yBvCehgssoAyLeIUdZf5xmcpu11n6vn3l0mhzUmtcNTtyBOCAf1zOe2TzBKlOwedXvClPxyv4X9eJ9cQBebVP4hsrcLN7BASoSc6Xd6-HS5Ehq3XFPGgFckVrjC_ySjc4mhOxfexkLXXfWYBYbVt328nPY1YbIAJ54iNdF4Uth_EquJlK0sQ/https*3A*2F*2Fdocs.google.com*2Fdocument*2Fd*2F1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE*2Fedit*3Ftab*3Dt.0__;JSUlJSUlJSUl!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarmx-MTqeM$> Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ 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<https://urldefense.com/v3/__https:/www.icann.org/privacy/policy__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarm2KU5KyI$>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://urldefense.com/v3/__https:/www.icann.org/privacy/tos__;!!DUT_TFPxUQ!HIpaNeP_pHwJ-mBMXZjQzL6Pcc5pyryp1G9KVXnXllPGP4MAqgm8VYwkdTlpQ-z7PaqFsmN0qeqjoarm2nn6U3M$>). 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. ________________________________ If you are not an intended recipient of confidential and privileged information in this email, please delete it, notify us immediately at postmaster@gtlaw.com<mailto:postmaster@gtlaw.com>, and do not use or disseminate the information.
Thank you Elaine for your most valuable comments. To address these concerns, we propose to amend the definition in the AGB to use the term "naming system" instead of "name space", and to clarify that the assessments are being made to mitigate the risks of name collisions between the global DNS and other naming systems. Section 6.7 would be amended as follows: "The delegation of almost any new gTLD carries some risk of Name Collision. Name Collision refers to the situation in which a resource name that is intended to be resolved in one naming system namespace is inadvertently resolved in a different naming system namespace, potentially leading to unexpected behaviour such as communication being disrupted or redirected from its intended recipient. In order to assess and mitigate the this risk for name collisions between the global DNS and other naming systems, ICANN has implemented the Name Collision Risk Management framework, following recommendations from the Name Collision Analysis Project Study Two Report, as directed by the ICANN Board on 7 September 2024." Please let us know if these amendments would address your concerns. We also plan to cover these updates in the IRT meeting on the 4th of September. Best, Fredrik
On 21 Aug 2025, at 15:37, Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> wrote:
For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round.
For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP.
Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3 <https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-e...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate.
This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD.
Here is the link to that email: DNSO Archives: [ga-roots] <http://www.dnso.org/clubpublic/ga-roots/Arc00/msg00277.html>
Lets not deviate from our exiting policy.
Sincerely,
Jeff
On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org> wrote:
Dear IRT / ICANN
In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response).
1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS.
Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.”
ICANN’s initial response in the IRT deck <https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025-...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.”
https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191
NOTE: Name Space and Name System are not the same and should not be used interchangeably:
Alternative Name Space
Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). Example: The DNS root managed by ICANN is the “main” namespace. An alternative namespace might be www.Facebook.com/first-lastname <http://www.facebook.com/first-lastname>, a twitter handle, etc Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System
Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. Example: Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. They each define their own namespace (like .bit for Namecoin, .eth for ENS). Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. Key Point: It’s about the system that manages, resolves, and governs the namespace.
From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).”
2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made.
I believe SSAC’s comment above seem to be referring to their Study 2 Report definition:
Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2
Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30:
42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca....
NCAP Study 1 Report <file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example <http://www.example/> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example <http://www.example/>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM)
3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3.
The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope.
SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems:
SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems:
Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. Operational instability for network operators and end-users. User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.”
The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected.
Elaine
From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Reply-To: Jared Erwin <jared.erwin@icann.org> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
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.
Dear IRT Members,
The deck for tomorrow’s call can be found on the meeting page here <https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...>.
The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrN... <https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaX...> The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_... <https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1R...>
Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments.
Thank you,
Jared
--
Jared Erwin
Senior Director, New gTLD Program
Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)
jared.erwin@icann.org <mailto:jared.erwin@icann.org>
_______________________________________________ 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.
Hi Fredrik, All, This does not seem to address Jeff’s point that extending NCAP out of the DNS is policy and not something that should be done merely because a comment is made on the AGB. As far as I'm aware, there is no current SSAC advice on this and the matter had not been considered or discussed by the community or the Board. Have I missed something? Cheers, CD Chris Disspain +44 7880 642456 
On 1 Sep 2025, at 09:52, Fredrik Ljunggren via SubPro-IRT <subpro-irt@icann.org> wrote:
Thank you Elaine for your most valuable comments. To address these concerns, we propose to amend the definition in the AGB to use the term "naming system" instead of "name space", and to clarify that the assessments are being made to mitigate the risks of name collisions between the global DNS and other naming systems.
Section 6.7 would be amended as follows:
"The delegation of almost any new gTLD carries some risk of Name Collision. Name Collision refers to the situation in which a resource name that is intended to be resolved in one naming system namespace is inadvertently resolved in a different naming system namespace, potentially leading to unexpected behaviour such as communication being disrupted or redirected from its intended recipient.
In order to assess and mitigate the this risk for name collisions between the global DNS and other naming systems, ICANN has implemented the Name Collision Risk Management framework, following recommendations from the Name Collision Analysis Project Study Two Report, as directed by the ICANN Board on 7 September 2024."
Please let us know if these amendments would address your concerns. We also plan to cover these updates in the IRT meeting on the 4th of September.
Best, Fredrik
On 21 Aug 2025, at 15:37, Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> wrote:
For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round.
For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP.
Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3 <https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-e...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate.
This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD.
Here is the link to that email: DNSO Archives: [ga-roots] <http://www.dnso.org/clubpublic/ga-roots/Arc00/msg00277.html>
Lets not deviate from our exiting policy.
Sincerely,
Jeff
On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org> wrote:
Dear IRT / ICANN
In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment <https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response).
1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS.
Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.”
ICANN’s initial response in the IRT deck <https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025-...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.”
https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191
NOTE: Name Space and Name System are not the same and should not be used interchangeably:
Alternative Name Space
Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). Example: The DNS root managed by ICANN is the “main” namespace. An alternative namespace might be www.Facebook.com/first-lastname <http://www.facebook.com/first-lastname>, a twitter handle, etc Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System
Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. Example: Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. They each define their own namespace (like .bit for Namecoin, .eth for ENS). Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. Key Point: It’s about the system that manages, resolves, and governs the namespace.
From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).”
2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made.
I believe SSAC’s comment above seem to be referring to their Study 2 Report definition:
Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2
Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30:
42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca....
NCAP Study 1 Report <file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example <http://www.example/> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example <http://www.example/>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM)
3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3.
The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope.
SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems:
SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems:
Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. Operational instability for network operators and end-users. User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.”
The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected.
Elaine
From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org> Reply-To: Jared Erwin <jared.erwin@icann.org> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org" <subpro-irt@icann.org> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
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.
Dear IRT Members,
The deck for tomorrow’s call can be found on the meeting page here <https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...>.
The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrN... <https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaX...> The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_... <https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1R...>
Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments.
Thank you,
Jared
--
Jared Erwin
Senior Director, New gTLD Program
Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)
jared.erwin@icann.org <mailto:jared.erwin@icann.org>
_______________________________________________ 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.
_______________________________________________ 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 Chris, the effect of this change will be to accept the SSAC’s comment and allow the name collision assessment to consider potential clashes between the DNS and other naming systems (such as blockchain-based systems), which I don’t agree with for the reasons articulated by Elaine, Jeff, and others. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 [cid:image001.png@01DC1B3A.59F53ED0] <https://comlaude.com/> Follow us on LinkedIn<https://t-uk.xink.io/Tracking/Index/pRkAAGVfAADD_RQA0> and YouTube<https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADD_RQA0> From: Chris Disspain via SubPro-IRT <subpro-irt@icann.org> Sent: 01 September 2025 10:22 To: Fredrik Ljunggren <fredrik@kirei.se> Cc: subpro-irt@icann.org Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC Hi Fredrik, All, This does not seem to address Jeff’s point that extending NCAP out of the DNS is policy and not something that should be done merely because a comment is made on the AGB. As far as I'm aware, there is no current SSAC advice on this and the matter had not been considered or discussed by the community or the Board. Have I missed something? Cheers, CD Chris Disspain +44 7880 642456 [cid:image002.jpg@01DC1B3A.59F53ED0] On 1 Sep 2025, at 09:52, Fredrik Ljunggren via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Thank you Elaine for your most valuable comments. To address these concerns, we propose to amend the definition in the AGB to use the term "naming system" instead of "name space", and to clarify that the assessments are being made to mitigate the risks of name collisions between the global DNS and other naming systems. Section 6.7 would be amended as follows: "The delegation of almost any new gTLD carries some risk of Name Collision. Name Collision refers to the situation in which a resource name that is intended to be resolved in one naming system namespace is inadvertently resolved in a different naming system namespace, potentially leading to unexpected behaviour such as communication being disrupted or redirected from its intended recipient. In order to assess and mitigate the this risk for name collisions between the global DNS and other naming systems, ICANN has implemented the Name Collision Risk Management framework, following recommendations from the Name Collision Analysis Project Study Two Report, as directed by the ICANN Board on 7 September 2024." Please let us know if these amendments would address your concerns. We also plan to cover these updates in the IRT meeting on the 4th of September. Best, Fredrik On 21 Aug 2025, at 15:37, Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3<https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-e...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots]<http://www.dnso.org/clubpublic/ga-roots/Arc00/msg00277.html> Lets not deviate from our exiting policy. Sincerely, Jeff [https://ci3.googleusercontent.com/meips/ADKq_Na0au3lFoPoPHrWAj8ua-8sA0Kn20-5...] On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment<https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025-...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname<http://www.facebook.com/first-lastname>, a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca.... NCAP Study 1 Report<file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example<http://www.example/> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example<http://www.example/>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here<https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...>. 1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0<https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaXVMYDPhjbEh20lK1MD2emp1xFUbn-uo84JOXyF4PRFYu43pSiKkitABn7WX2N-DIl9P5GY2MzETTovG2-L6jPN7j6CbWSYOdr3kFpDSvxonne0ucxMO68OaCHJ6SMV5sDIk9UOoo6Og1Ktc2MzINI-cPkzFaLtx6HyduNfZsYPk5lHmX5ZrBAeCrHvejef-KkTt8g0W3sFIVzfaZPplxnKskq3M-69D837b7gi8izzsHJ6h2sH0AQtrRcfOxlA/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc%2Fedit%3Ftab%3Dt.0> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE/edit?tab=t.0<https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1Rk62WIaY4J57sV8n_X3P9GCEej6kXniLcgxUJLrV5EdkU2wXQTVFLfnU81fJwmr4ytS1fMOxA6yBvCehgssoAyLeIUdZf5xmcpu11n6vn3l0mhzUmtcNTtyBOCAf1zOe2TzBKlOwedXvClPxyv4X9eJ9cQBebVP4hsrcLN7BASoSc6Xd6-HS5Ehq3XFPGgFckVrjC_ySjc4mhOxfexkLXXfWYBYbVt328nPY1YbIAJ54iNdF4Uth_EquJlK0sQ/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE%2Fedit%3Ftab%3Dt.0> Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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. ________________________________ 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://comlaude.com/>
I agree with Chris, too – and do not agree with the proposed change. Best Katrin DOTZON GmbH – creating identities Akazienstrasse 28 10823 Berlin Deutschland - Germany Mobile: +49 173 2019240 ohlmer@dotzon.consulting<mailto:ohlmer@dotzon.consulting> www.dotzon.consulting<http://www.dotzon.consulting/> DOTZON GmbH Registergericht: Amtsgericht Berlin-Charlottenburg, HRB 118598 Geschäftsführer: Katrin Ohlmer Sitz der Gesellschaft: Akazienstrasse 28, 10823 Berlin Von: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> Gesendet: Montag, 1. September 2025 13:24 An: Chris Disspain <chris.disspain@identity.digital>; Fredrik Ljunggren <fredrik@kirei.se> Cc: subpro-irt@icann.org Betreff: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC I agree with Chris, the effect of this change will be to accept the SSAC’s comment and allow the name collision assessment to consider potential clashes between the DNS and other naming systems (such as blockchain-based systems), which I don’t agree with for the reasons articulated by Elaine, Jeff, and others. Kind regards, Ashley Ashley Roberts Head of New TLD Consultancy Com Laude T +44 (0) 20 7421 8250 Ext 264 [cid:image001.png@01DC1B44.79C71AD0] <https://comlaude.com/> Follow us on LinkedIn<https://t-uk.xink.io/Tracking/Index/pRkAAGVfAADD_RQA0> and YouTube<https://t-uk.xink.io/Tracking/Index/bhkAAGVfAADD_RQA0> From: Chris Disspain via SubPro-IRT <subpro-irt@icann.org> Sent: 01 September 2025 10:22 To: Fredrik Ljunggren <fredrik@kirei.se> Cc: subpro-irt@icann.org Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC Hi Fredrik, All, This does not seem to address Jeff’s point that extending NCAP out of the DNS is policy and not something that should be done merely because a comment is made on the AGB. As far as I'm aware, there is no current SSAC advice on this and the matter had not been considered or discussed by the community or the Board. Have I missed something? Cheers, CD Chris Disspain +44 7880 642456 [cid:image002.jpg@01DC1B44.79C71AD0] On 1 Sep 2025, at 09:52, Fredrik Ljunggren via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Thank you Elaine for your most valuable comments. To address these concerns, we propose to amend the definition in the AGB to use the term "naming system" instead of "name space", and to clarify that the assessments are being made to mitigate the risks of name collisions between the global DNS and other naming systems. Section 6.7 would be amended as follows: "The delegation of almost any new gTLD carries some risk of Name Collision. Name Collision refers to the situation in which a resource name that is intended to be resolved in one naming system namespace is inadvertently resolved in a different naming system namespace, potentially leading to unexpected behaviour such as communication being disrupted or redirected from its intended recipient. In order to assess and mitigate the this risk for name collisions between the global DNS and other naming systems, ICANN has implemented the Name Collision Risk Management framework, following recommendations from the Name Collision Analysis Project Study Two Report, as directed by the ICANN Board on 7 September 2024." Please let us know if these amendments would address your concerns. We also plan to cover these updates in the IRT meeting on the 4th of September. Best, Fredrik On 21 Aug 2025, at 15:37, Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3<https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-e...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots]<http://www.dnso.org/clubpublic/ga-roots/Arc00/msg00277.html> Lets not deviate from our exiting policy. Sincerely, Jeff [Das Bild wurde vom Absender entfernt.] On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment<https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025-...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname<http://www.facebook.com/first-lastname>, a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/nca.... NCAP Study 1 Report<file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example<http://www.example/> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example<http://www.example/>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here<https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...>. 1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0<https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaXVMYDPhjbEh20lK1MD2emp1xFUbn-uo84JOXyF4PRFYu43pSiKkitABn7WX2N-DIl9P5GY2MzETTovG2-L6jPN7j6CbWSYOdr3kFpDSvxonne0ucxMO68OaCHJ6SMV5sDIk9UOoo6Og1Ktc2MzINI-cPkzFaLtx6HyduNfZsYPk5lHmX5ZrBAeCrHvejef-KkTt8g0W3sFIVzfaZPplxnKskq3M-69D837b7gi8izzsHJ6h2sH0AQtrRcfOxlA/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc%2Fedit%3Ftab%3Dt.0> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE/edit?tab=t.0<https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1Rk62WIaY4J57sV8n_X3P9GCEej6kXniLcgxUJLrV5EdkU2wXQTVFLfnU81fJwmr4ytS1fMOxA6yBvCehgssoAyLeIUdZf5xmcpu11n6vn3l0mhzUmtcNTtyBOCAf1zOe2TzBKlOwedXvClPxyv4X9eJ9cQBebVP4hsrcLN7BASoSc6Xd6-HS5Ehq3XFPGgFckVrjC_ySjc4mhOxfexkLXXfWYBYbVt328nPY1YbIAJ54iNdF4Uth_EquJlK0sQ/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE%2Fedit%3Ftab%3Dt.0> Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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. ________________________________ 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://comlaude.com/>
Fredrick, thank you for considering my suggestions. As others have noted, the proposed edits are the opposite of the desired outcome. We do not want to consider name collisions between name systems. That is out of scope for NCAP study 2 and the proposed name collision framework for the next round. If it were in scope, then the SSAC would not have felt compelled to submit a public comment Recommendation 3. Name collisions between naming systems is out of scope according to ICP-3. The language in the AGB needs to be refined to reflect that name collision evaluation will only occur within the ICANN name system, as clarified by Francisco on the SubPro call during the discussion. Avri, concerns that SSAC raised have been discussed multiple times over the years and every single time the community has decided that alternative name systems are out of scope. Our focus is our name system — the one interoperable global Internet managed by ICANN. We have declined to trigger a PDP or a review of ICP three even after hearing all of the concerns that are being raised again today. Why do we care so much about holding this line? Because it would allow the SSAC to submit a public comment carrying the weight of advice, but no review by the Board and only for consideration by the IRT. It will usurp the process for issuing and review of Advice and the policy development process. Using “potential user confusion” as a reason to not approve an application for a TLD, for example, .HNS because it exists in an alternative name system, as Jeff noted, opens the door for shenanigans between now and when the application goes through name collision review process. Elaine On Sep 1, 2025, at 4:30 AM, Katrin Ohlmer | DOTZON GmbH via SubPro-IRT <subpro-irt@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. I agree with Chris, too – and do not agree with the proposed change. Best Katrin DOTZON GmbH – creating identities Akazienstrasse 28 10823 Berlin Deutschland - Germany Mobile: +49 173 2019240 ohlmer@dotzon.consulting<mailto:ohlmer@dotzon.consulting> www.dotzon.consulting<http://secure-web.cisco.com/1_Uoy3TjeCP-ERXiTpKiAHe7alSrPhdXbNBGpeeZXLMgCGkV...> DOTZON GmbH Registergericht: Amtsgericht Berlin-Charlottenburg, HRB 118598 Geschäftsführer: Katrin Ohlmer Sitz der Gesellschaft: Akazienstrasse 28, 10823 Berlin Von: Ashley Roberts via SubPro-IRT <subpro-irt@icann.org> Gesendet: Montag, 1. September 2025 13:24 An: Chris Disspain <chris.disspain@identity.digital>; Fredrik Ljunggren <fredrik@kirei.se> Cc: subpro-irt@icann.org Betreff: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC I agree with Chris, the effect of this change will be to accept the SSAC’s comment and allow the name collision assessment to consider potential clashes between the DNS and other naming systems (such as blockchain-based systems), which I don’t agree with for the reasons articulated by Elaine, Jeff, and others. 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/1HoQ1xynRBf0JhJGnE7NwHM45F65-3kcUH3VyUcIEWdKoBy...> <image001.png><https://secure-web.cisco.com/1HoQ1xynRBf0JhJGnE7NwHM45F65-3kcUH3VyUcIEWdKoBy...> Follow us on LinkedIn<https://secure-web.cisco.com/1BvKsBtPMdWlqNhPaxshwpQAlQKyajsyfH0SZ948sAoK966...> and YouTube<https://secure-web.cisco.com/1RbT_6qaoUGBEt7APUkkvRXV5JNCHY23SrpB3kWKZvNbp4i...> <~WRD1902.jpg> From: Chris Disspain via SubPro-IRT <subpro-irt@icann.org> Sent: 01 September 2025 10:22 To: Fredrik Ljunggren <fredrik@kirei.se> Cc: subpro-irt@icann.org Subject: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC Hi Fredrik, All, This does not seem to address Jeff’s point that extending NCAP out of the DNS is policy and not something that should be done merely because a comment is made on the AGB. As far as I'm aware, there is no current SSAC advice on this and the matter had not been considered or discussed by the community or the Board. Have I missed something? Cheers, CD Chris Disspain +44 7880 642456 <image002.jpg> On 1 Sep 2025, at 09:52, Fredrik Ljunggren via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Thank you Elaine for your most valuable comments. To address these concerns, we propose to amend the definition in the AGB to use the term "naming system" instead of "name space", and to clarify that the assessments are being made to mitigate the risks of name collisions between the global DNS and other naming systems. Section 6.7 would be amended as follows: "The delegation of almost any new gTLD carries some risk of Name Collision. Name Collision refers to the situation in which a resource name that is intended to be resolved in one naming system namespace is inadvertently resolved in a different naming system namespace, potentially leading to unexpected behaviour such as communication being disrupted or redirected from its intended recipient. In order to assess and mitigate the this risk for name collisions between the global DNS and other naming systems, ICANN has implemented the Name Collision Risk Management framework, following recommendations from the Name Collision Analysis Project Study Two Report, as directed by the ICANN Board on 7 September 2024." Please let us know if these amendments would address your concerns. We also plan to cover these updates in the IRT meeting on the 4th of September. Best, Fredrik On 21 Aug 2025, at 15:37, Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: For the record, I am 100% supportive of Elaine's comments and believe that the to the extent that the new SSAC recommendations are viewed as inconsistent, the SSAC recommendations must be rejected. In addition, the SSAC's comments on considering alternate blockchain spaces in the analysis is a policy matter that would have to be looked at through the GNSO Policy Development process for the Subsequent Round AFTER the 2026 round. For a little more background, there was some discussion during the SubPro PDP on the topic of potential overlap between namespaces and when the NCAP Phase 1 study EXCLUDED blockchain domains from the definition of collision, the SubPro PDP considered the topic of overlap out of scope for the PDP as well. If the SSAC wants to change its view to consider blockchain, then this would have to be considered by a new PDP. Not to mention that the consideration of alternate naming space outside of DNS would seem to run counter to ICP-3<https://secure-web.cisco.com/10KghOaum5Gp6RYvvYioZMCz_EkdiaU78cXkyDUMn6gR59z...> and would present a significant deviation from the previous rounds where alternate name spaces were not only not taken into account, but which were the subject of litigation and much debate. This issue of alternate namespaces has been around for at least a quarter of a century. This makes me feel old, but here is an e-mail I sent in May 2001, regarding a claim made by Leah Gallegos of an organization called the Atlantic Root when they objected to NeuLevel's .biz TLD. Here is the link to that email: DNSO Archives: [ga-roots]<http://secure-web.cisco.com/1miY3V-vwdnLTKDE5TxHoJ1DKJqdF40RhxtMQgt0eHBNdd3W...> Lets not deviate from our exiting policy. Sincerely, Jeff <~WRD1902.jpg> On 8/20/2025 4:44:49 PM, Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT / ICANN In response to the IRT discussion on Name Collisions August 20th, I wish to reiterate the points I made on the call, and request ICANN consider these points while considering changes to the AGB in response to the SSAC Recommendations via public comment<https://secure-web.cisco.com/1c0sIZ03DdurjjHqykzPklivQLL4mu8ce0ql5fVNr_ULwhX...> (this is not SSAC Advice which would undergo a different process for intake, analysis, and response). 1. ICANN needs to update Module 6 Name Collisions to provide a clear definition of what constitutes a Name Collision (per Francisco: Collision refers to the situation in which a resource name that is intended to be resolved in one namespace is inadvertently resolved in a different name space, potentially leading to unexpected behavior such as communication being disrupted or redirected from its intended recipient) and clarify that name collision evaluations will be limited to other name spaces “leaking” into the ICANN DNS. Evaluations should not put much (if any) weight on “potential collisions with known, widely used alternative naming systems” such as blockchain, as requested in SSAC130 Recommendation 3: “The AGB should explicitly state that the TRT is allowed to include evaluating potential collisions with known, widely used alternative naming systems and other external sources, as these can create foreseeable security and stability risks for DNS users.” ICANN’s initial response in the IRT deck<https://secure-web.cisco.com/16V_PEuX64WmMCTsikWiCxJq0mwMxto-hYBlhwhg9NSV0yp...>: “On recommendation 3: The definition of a name collision (section 6.7, first paragraph) is that different name spaces are overlapping. An alternative naming system is such a different name space. It is not possible to assess the risk of name collisions without taking other name spaces into consideration, for which reason there seems to be no need to clarify on this matter further.” https://itp.cdn.icann.org/en/files/policy-development/new-gtld-progra<https://secure-web.cisco.com/1UcHDQeJmtpXMA-QhqVvsJuioOghrkUeWyeKh2Jb53R9EP6sOCZ6bredLo3MJzOOJ-vm06UqfttQ79JbVoYLTwDx0eQBkZdbYhiA6qwFXMG4oIAFTHwuahObnYOTCqLUMAd59tLAAnLJrLAOZHSVaZHqMiWxHxPOV8h0lMbaKNmU521EIXDsdupRBrYNJ1kKOoHo2equpYt_TZQ5DjbJyCKLvKoMZVOM4teX5SaRm77kF2W8S069gGIsIUkB1pc1WERq4oeaLZWr_vC1aQ4kTC1yJLajL6nIx3au0ZjLsDu8/https%3A%2F%2Fitp.cdn.icann.org%2Fen%2Ffiles%2Fpolicy-development%2Fnew-gtld-progra> m-next-round-draft-applicant-guidebook-for-public-comment-30-05- 2025-en.pdf#page=191 NOTE: Name Space and Name System are not the same and should not be used interchangeably: Alternative Name Space * Definition: A name space is the set of all possible names under a given naming scheme. An alternative name space is one that exists outside the traditional, widely used system (like the global DNS root managed by ICANN). * Example: * The DNS root managed by ICANN is the “main” namespace. * An alternative namespace might be www.Facebook.com/first-lastname<http://www.facebook.com/first-lastname>, a twitter handle, etc * Key Point: It’s about the collection of names and their structure, regardless of how they’re resolved. Alternative Name System * Definition: A name system is the actual infrastructure, protocols, and mechanisms used to resolve or map names in a namespace to their associated data (like IP addresses, certificates, or resources). * An alternative name system is a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance. * Example: * Namecoin, ENS (Ethereum Name Service), and Handshake are alternative name systems, each with their own rules and technical protocols. * They each define their own namespace (like .bit for Namecoin, .eth for ENS). * Purpose: To provide resolution services that don’t depend on the DNS, often with goals like decentralization, censorship-resistance, or blockchain integration. * Key Point: It’s about the system that manages, resolves, and governs the namespace. From the SSAC Comment: “The SSAC's goal is to ensure that a clear and transparent process exists to evaluate the technical risks of name collisions, particularly when they occur between the Domain Name System (DNS) and alternative, publicly-available naming systems (e.g., blockchain-based naming systems) as opposed to private, internal naming systems. In this comment, the SSAC provides specific recommendations to improve the AGB, focusing on the mechanisms related to the identification, evaluation, and mitigation of name collisions, primarily drawing on the Name Collision Risk Assessment Framework detailed in the Name Collision Analysis Project (NCAP) Study 2 Report (NCAP2).” 2. An edit to the AGB referencing the definition and examples of name collisions in NCAP Study 1 should be made. I believe SSAC’s comment above seem to be referring to their Study 2 Report definition: Name collisions are defined in NCAP2 as follows: Name Collision refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious. In the context of top-level domains (TLDs), the conflicting namespaces are the global Internet Domain Name System (DNS) namespace reflected in the root zone as published by the Root Zone Management Partners and any other namespace, regardless of whether that other namespace is intended for use with the DNS or any other protocol [emphasis added].2 Whereas the AGB footnote references NCAP Study 1 Report bottom of page 30: 42 For examples of name collisions, please refer to section 2.2 of the Name Collision Analysis Project (NCAP) Study report: https://icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf<https://secure-web.cisco.com/1WYb6Ec9IkcbOACRKvO8S2_ykDQgsWXAd5ekuBrezjkiUtqf-5HKW0vuP5zvzFgSxt7g1KGT6qvu1CBzdfoM9yClu2shTOdIcDr5WO99ByIRY0oWJPNCP5ADolohSHU_dBqGUBngxJwT6jYgsDWRswDL7qXlUCGyoRzwiuFxuet6GvbmTMbrwhLUO_TgkYTgtltsnGsy7e4LbLf7I0Fh6Jmq5voFUCN-D3na3uHHiI78VD7AjAUBMK_gViedYnNzl6aFdtMH3-FQrArYgQZTx5LPleohWTK_ClFi4KhNNUUk/https%3A%2F%2Ficann-community.atlassian.net%2Fwiki%2Fdownload%2Fattachments%2F99319865%2Fncap-study-1-report-19jun20-en.pdf>. NCAP Study 1 Report<file:///Users/epruis/Downloads/ncap-study-1-report-19jun20-en.pdf> first example of Name Collision: “Suppose that Alice uses .EXAMPLE internally only as her top-level domain, which works without ambiguity because .EXAMPLE is not a TLD delegated on the Internet. If Alice types www.example<http://secure-web.cisco.com/1pAWXtua4c3aaPkZP3P-60QSk__MxwxV-pBd1YU3vCNoMCFr...> in a web browser, it would take her to her own website. The next year, .EXAMPLE is delegated as a new TLD. Now when Alice tries to access www.example<http://secure-web.cisco.com/1pAWXtua4c3aaPkZP3P-60QSk__MxwxV-pBd1YU3vCNoMCFr...>, it’s no longer clear whether she is trying to access her own website or the new public domain on the Internet. The .EXAMPLE used internally by Alice and the .EXAMPLE used publicly by someone else collide. This report will refer to these as duplicate name collisions—the collision is caused by the same TLD being used in two places at the same time.” (WITHIN THE SAME NAME SYSTEM) 3. The IRT was assured by the OCTO that name collisions would be evaluated WITHIN the ICANN Domain Name System (DNS)– and referenced ICP-3 as a long-standing position to limit its activity to the ICANN DNS. A statement was made that IF the community wanted to include consideration or special treatment for existing “TLDs” in alternative name systems such as .blockchain, a policy development process would need to occur to review ICP-3. The NCAP studies were conducted under the presumption that web3 and other name systems were out of scope. SSAC’s comment on the AGB below appears to request ICANN extend the scope to include alternative name systems: SSAC: “Without explicit guidelines and proactive management, these alternative naming systems may create collisions with new gTLDs delegated through the New gTLD Program: Next Round. The SSAC believes these collisions could cause the following problems: * Security vulnerabilities stemming from misdirected traffic or unexpected system interactions. * Operational instability for network operators and end-users. * User confusion due to unpredictable resolution behavior. The SSAC submits this comment to amplify and clarify key principles from NCAP2 that address these (previously identified) risks, so that the final AGB fully reflects this guidance.” The request to consider alternative name systems and their potential for causing user confusion within the ICANN DNS as part of the Next Round AGB name collision evaluation should be rejected. Elaine From: Jared Erwin via SubPro-IRT <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Reply-To: Jared Erwin <jared.erwin@icann.org<mailto:jared.erwin@icann.org>> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt@icann.org<mailto:subpro-irt@icann.org>" <subpro-irt@icann.org<mailto:subpro-irt@icann.org>> Subject: [EXTERNAL] [SubPro-IRT] Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC 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. Dear IRT Members, The deck for tomorrow’s call can be found on the meeting page here<https://secure-web.cisco.com/1XTscfb4Zxbv5y6___alN6VCZorvKJ6jEEH3dkNb4NncbuX...>. 1. The relevant language for Name Collision can be found in the Module 6 document: https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0<https://secure-web.cisco.com/1enaeKYppeVkZojS2TyvLFltgLY1nhTzf9hwQVXMWbFqyaXVMYDPhjbEh20lK1MD2emp1xFUbn-uo84JOXyF4PRFYu43pSiKkitABn7WX2N-DIl9P5GY2MzETTovG2-L6jPN7j6CbWSYOdr3kFpDSvxonne0ucxMO68OaCHJ6SMV5sDIk9UOoo6Og1Ktc2MzINI-cPkzFaLtx6HyduNfZsYPk5lHmX5ZrBAeCrHvejef-KkTt8g0W3sFIVzfaZPplxnKskq3M-69D837b7gi8izzsHJ6h2sH0AQtrRcfOxlA/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc%2Fedit%3Ftab%3Dt.0> 2. The relevant language for CPE can be found in the Module 4 document: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE/edit?tab=t.0<https://secure-web.cisco.com/1QQniTGIPK1FGCtJxkji2dL9PQFRqTW4pNRt2x5aVLs_B1Rk62WIaY4J57sV8n_X3P9GCEej6kXniLcgxUJLrV5EdkU2wXQTVFLfnU81fJwmr4ytS1fMOxA6yBvCehgssoAyLeIUdZf5xmcpu11n6vn3l0mhzUmtcNTtyBOCAf1zOe2TzBKlOwedXvClPxyv4X9eJ9cQBebVP4hsrcLN7BASoSc6Xd6-HS5Ehq3XFPGgFckVrjC_ySjc4mhOxfexkLXXfWYBYbVt328nPY1YbIAJ54iNdF4Uth_EquJlK0sQ/https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3_DkE%2Fedit%3Ftab%3Dt.0> Regarding CPE, and based on the NCSG’s input from today, we have made several updates to the guidelines to reflect this, as I believe it aligns with the general discussion on independent research from last week. Also, as noted, I’ve added a few summary slides regarding the comments to help facilitate our conversation tomorrow. I’d like to focus more on the AGB language/changes made based on comments. Thank you, Jared -- Jared Erwin Senior Director, New gTLD Program Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) jared.erwin@icann.org<mailto:jared.erwin@icann.org> _______________________________________________ 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<https://secure-web.cisco.com/1JvNbzDmxpaRuGly1SHfWXExUQSP4INJfOWAm3Zv0RiY_NVUgOjkcm8Ke2z6C7Jv2LrdaQrEZnn7xoVjFJPUJx59FvO1b8CXbc2coP0KAXtA9jS-CV0mFG3M2KftwgXgXY4WK40TY0GW7QCGF9TzF1P1mI44zP-yjToiyF8sEXm9Tnpvhcy29MX0Uc0Y6vN-IKMizoOQTXK__ihOi77jroH4Lw1zc3DZWszznhBFpV2uYysH60VqNeV4KkSfO9eEilzt_UX03WW1YWTl0GscC4kS1yjcc1A1y61TB-AAKU0A/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://secure-web.cisco.com/1n8GbSocacMl-1UpP4X-l8ByaDJapZJiFBhaRx1yTm_WMZdZ-nZcljnXt3Q3Ju2gzJQZbORZXny80Ey0rwIubkVOu-9kJ6HowUjMTOT7y5I8Qux3xvbKw49HccJbDBmyjpDFSGbl5WDlIZYGyogEakRocADJYduvgmGdS8Ns1RXaHwCI2NzaOw0RuQXuL1epNjsNbDe1RxcdJVtesrP8CnhZU_9glAWp_p6rTpkzEzRgDkx_7GwAJeiorALy0o04JpVxe1ALtEp-ONZ67u_9pRdY0Ijvf3cWE3pPKOwbue54/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). 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. <~WRD1902.jpg> _______________________________________________ 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<https://secure-web.cisco.com/1JvNbzDmxpaRuGly1SHfWXExUQSP4INJfOWAm3Zv0RiY_NVUgOjkcm8Ke2z6C7Jv2LrdaQrEZnn7xoVjFJPUJx59FvO1b8CXbc2coP0KAXtA9jS-CV0mFG3M2KftwgXgXY4WK40TY0GW7QCGF9TzF1P1mI44zP-yjToiyF8sEXm9Tnpvhcy29MX0Uc0Y6vN-IKMizoOQTXK__ihOi77jroH4Lw1zc3DZWszznhBFpV2uYysH60VqNeV4KkSfO9eEilzt_UX03WW1YWTl0GscC4kS1yjcc1A1y61TB-AAKU0A/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://secure-web.cisco.com/1n8GbSocacMl-1UpP4X-l8ByaDJapZJiFBhaRx1yTm_WMZdZ-nZcljnXt3Q3Ju2gzJQZbORZXny80Ey0rwIubkVOu-9kJ6HowUjMTOT7y5I8Qux3xvbKw49HccJbDBmyjpDFSGbl5WDlIZYGyogEakRocADJYduvgmGdS8Ns1RXaHwCI2NzaOw0RuQXuL1epNjsNbDe1RxcdJVtesrP8CnhZU_9glAWp_p6rTpkzEzRgDkx_7GwAJeiorALy0o04JpVxe1ALtEp-ONZ67u_9pRdY0Ijvf3cWE3pPKOwbue54/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). 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<https://secure-web.cisco.com/1JvNbzDmxpaRuGly1SHfWXExUQSP4INJfOWAm3Zv0RiY_NVUgOjkcm8Ke2z6C7Jv2LrdaQrEZnn7xoVjFJPUJx59FvO1b8CXbc2coP0KAXtA9jS-CV0mFG3M2KftwgXgXY4WK40TY0GW7QCGF9TzF1P1mI44zP-yjToiyF8sEXm9Tnpvhcy29MX0Uc0Y6vN-IKMizoOQTXK__ihOi77jroH4Lw1zc3DZWszznhBFpV2uYysH60VqNeV4KkSfO9eEilzt_UX03WW1YWTl0GscC4kS1yjcc1A1y61TB-AAKU0A/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos<https://secure-web.cisco.com/1n8GbSocacMl-1UpP4X-l8ByaDJapZJiFBhaRx1yTm_WMZdZ-nZcljnXt3Q3Ju2gzJQZbORZXny80Ey0rwIubkVOu-9kJ6HowUjMTOT7y5I8Qux3xvbKw49HccJbDBmyjpDFSGbl5WDlIZYGyogEakRocADJYduvgmGdS8Ns1RXaHwCI2NzaOw0RuQXuL1epNjsNbDe1RxcdJVtesrP8CnhZU_9glAWp_p6rTpkzEzRgDkx_7GwAJeiorALy0o04JpVxe1ALtEp-ONZ67u_9pRdY0Ijvf3cWE3pPKOwbue54/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). 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. ________________________________ 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/1HoQ1xynRBf0JhJGnE7NwHM45F65-3kcUH3VyUcIEWdKoBy...> _______________________________________________ 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://secure-web.cisco.com/1JvNbzDmxpaRuGly1SHfWXExUQSP4INJfOWAm3Zv0RiY_NV...) and the website Terms of Service (https://secure-web.cisco.com/1n8GbSocacMl-1UpP4X-l8ByaDJapZJiFBhaRx1yTm_WMZd...). 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 (9)
-
Anne ICANN -
Ashley Roberts -
Chris Disspain -
Fredrik Ljunggren -
Jeffrey J. Neuman -
Karen Day -
Katrin Ohlmer | DOTZON GmbH -
Pruis, Elaine -
trachtenbergm＠gtlaw.com