On 1 Sep 2025, at 21:17, Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> wrote:
First of all at this point in time, if you look at the data tool we were given, No blockchain top-level names have leaked into the DNS in any real fashion. That should be telling in and of itself. If it starts happening after today, that is likely gaming by someone._______________________________________________This is another reason why the SSAC comments must not be taken into consideration and if provided as advice must be rejected.On 9/1/2025 3:31:02 PM, Anne ICANN <anneicanngnso@gmail.com> wrote:
Hi all - for some reason, I thought we were all talking about names that leak into the DNS? (not just names that exist in alternate naming systems?) What is actually meant by "leaking into the DNS?"AnneOn Mon, Sep 1, 2025 at 9:22 AM Jeffrey J. Neuman via SubPro-IRT <subpro-irt@icann.org> wrote:_______________________________________________Actually, using your analogy and comparing it to the actual situation, it would be that you are on one highway, the truck is on another highway, and you are trying to protect yourself in the situation that that truck will come on to your highway and crash into you....and your solution would be akin to the police stating that you may not drive on your highway because of something that may or may not ever happen.On 9/1/2025 10:55:50 AM, Avri Doria <doriavr@gmail.com> wrote:
Hi,I find the way the terms are being used to be obfuscatings and therefore was trying to point to what actually happen on the network.I also take issue with your statement about scope. While I agree that it is not in scope for ICANN to do anything about those other names that look a lot like ICANN names, it is in scope for ICANN to make sure it is protected from them.
When driving down the road, it is not in scope for me to determine the standards of the truck barrelling towards me, but it is in scope for me to make sure I evade it safely. If I see it and maintain that I am in my lane, so it is their problem, I might be accused of foolishness and perhaps even malfeasance.avriOn Mon, Sep 1, 2025 at 10:45 AM Jeff Neuman <jeff@jjnsolutions.com> wrote:Avri,
You just added a new term “in the network itself” to the discussion creating even more confusion between “naming systems” and “name spaces.” Lets remember the critical fact, Blockchain names (and notice how I am not using the word “domain”) do not use the DNS and therefore by definition cannot be “domain names”. Blockchain names are not in the same name space or the same naming system nor are they “in network”.
Blockchain names are no different than any other name space like your X (formerly twitter) handle, your Instagram handle, tik tok username, or any other user ID. Nor is it different than Linked In” or your Facebook Link, which yes appear as URLs, but where the DNS is not used after resolving the second level domain. None of them rely on DNS and therefore are all outside the scope of ICANN. Just as ICANN is not allowed to consider content issues which are outside its scope, to consider other name spaces that do not use the DNS too would be outside ICANN’s scope and a violation of its mission.
Will there be requests for reconsideration….yes, you cannot stop that. Can ICANN quickly dispose of those, yes. Could there be lawsuits? Yes you cannot stop that.
But I GUARANTEE, as a lawyer, that if the SSAC comment is adopted, that will be far worse when the lawsuits come. Why? Because:
(a) ICANN would no longer be able to make the argument that the consideration of issues cause by name spaces outside the DNS is outside of their mission;
(B) the SSAC position opens the door to the consideration of “users perceptions” which introduces judgment calls. This will not stop the lawsuits, but will only prolong them. The determination of “users perceptions” will be an issue of fact (as opposed to an issue of law). As such, it would make those lawsuits next to impossible to dispense with them early on a motion to dismiss,
(C) It would open us ICANN to even more IRPs, this time by any Applicant who is potentially found to be in collision with a blockchain name space that disagrees with the fact that users would perceive the collision; and
(D) would encourage gaming and the creation of alternate name spaces in the future to attempt to prevent ICANN from ever delegating certain strings (which rewards those playing outside the rules).
In short, if I were ICANN’s legal counsel on this (which I am of course not), I would strongly advise the ICANN Board to reject the SSAC’s position even if it were to become advice. But in any case, it is NOT appropriate for the IRT to consider.
From: Avri Doria <doriavr@gmail.com>
Sent: Monday, September 1, 2025 9:55 AM
To: Pruis, Elaine <epruis@verisign.com>
Cc: trachtenbergm@gtlaw.com <trachtenbergm@gtlaw.com>; jeff@jjnsolutions.com <jeff@jjnsolutions.com>; jared.erwin@icann.org <jared.erwin@icann.org>; subpro-irt@icann.org <subpro-irt@icann.org>
Subject: Re: [SubPro-IRT] Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTCHi,
I have a slightly different outlook on it. I think that the new and additional problem happens when different name systems use the same name space producing possible collisions whether in the network itself or even just in the users' perceptions.
I think that the SSAC recommendations need to be taken seriously for this upcoming round, and that it needs to be dealt with before we plunge into a round that can cause long lasting issues; such as requests for reconsideration, IRP,s and worse. It is unthinkable to me that we would decide this before understanding, weighing, and dealing with the risk. I often think that SSAC is overly cautious, but not in this case.
I am not certain it requires a PDP. The job of the Board to weigh the recommendations of the GNSO Council against the advice it gets. It can certainly initiate a PDP if that is what it determines is best. Additionally any of the ACs or the GNSO itself can request a PDP. I do not, however, think that determination rests with the IRT. We have the problem of trying to understand how the policies determined by the GNSO Council and approved by the Board can be implemented, given what has become the case on the Internet. I do not see that as having been resolved.
avri
On Thu, Aug 21, 2025 at 11:14 AM Pruis, Elaine via SubPro-IRT <subpro-irt@icann.org> wrote:HI Marc
I’m making the distinction using “name spaces” vs. “name systems”.
Name Spaces (as you’ve described below and how the NCAP Study 1 considered them) “where .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” (INTERNAL) “network.” >>Home and Corp were not alternative name systems that had their own governance, root files and resolution servers.
How I would describe a web3 “TLD” is alternative name system -- a complete naming system that operates outside the traditional DNS, often with its own resolution methods, trust models, and governance.” 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).( A leak of an alternative name system (.eth mistakenly showing up for a ICANN DNS user) would only occur if the resolvers or browsers supported re-direction to the other Name System, like sending queries for .eth to the ICANN DNS instead of internally resolving the query on their own resolvers, or the resolvers or browsers making the distinction between Name Systems). In general naming systems and resolvers are hierarchical and browsers use an order of operation to determine which “root” to query, the don’t randomly guess at which Naming System the user intends. This is why when you query something like wallet.eth on a chrome browser today, you don’t land in the .eth name system.
SSAC’s recommendations seem to be asking ICANN to expand the Name Collision Framework to consider collisions not just INSIDE ICANN’s “single global authoritative root zone” but to also factor in potential user confusion with OTHER Naming Systems, leaky or not.
Hope that helps!
Elaine
From: "trachtenbergm@gtlaw.com" <trachtenbergm@gtlaw.com>
Date: Thursday, August 21, 2025 at 7:14 AM
To: "jeff@jjnsolutions.com" <jeff@jjnsolutions.com>, Elaine Pruis <epruis@verisign.com>, "jared.erwin@icann.org" <jared.erwin@icann.org>, "subpro-irt@icann.org" <subpro-irt@icann.org>
Subject: [EXTERNAL] RE: [SubPro-IRT] Re: 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.
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<image001.png><image002.png>
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
<image003.png>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.
_______________________________________________
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.
