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:
-
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
|
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.
|