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 | www.gtlaw.com
| View GT Biography
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/),
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
ShareholderChair, 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.1020M +1 773.677.3305
trac@gtlaw.com | www.gtlaw.com | View GT Biography
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 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]
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 (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/ncap-study-1-report-19jun20-en.pdf.
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/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXrNLPc/edit?tab=t.0
- 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
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)
_______________________________________________
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.
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.
