- SubPro-IRT - lists.icann.org

Re: Updated CPE Language for review by EOD Today August 29
by Jared Erwin Sept. 3, 2025

Sept. 3, 2025

Dear IRT members, I appreciate the input and conversation on this. I would kindly request that any further feedback on this language below be provided by EOD today (23:59 UTC). ICANN will circulate an updated/final draft by EOD Tuesday with any redlines based on this exchange incorporated. After that time, I would like to consider the CPE section complete/closed for further editing. FWIW, and as stated in my prior email, I believe that this version of the scoring table both simplifies the language and preserves the guideline re: outside support/opposition, which, to reiterate, was a concept that has already been in the language since January and continues to be in the language now. Thank you, Jared 4 - Applicant has majority support and does not have relevant opposition 3 - Applicant has majority support and has relevant minority opposition 2 - Applicant has majority support but also has relevant significant opposition 0 - Applicant does not have majority support The applicant has demonstrated support with clear rationale from a majority of the identified community. The applicant does not have any relevant (footnote) opposition. Note: Where the applied-for string carries broader meanings or implications beyond the identified community, the panel may also consider whether there is support, or the absence of opposition, from relevant organizations outside of the identified community (footnote). The applicant has demonstrated majority support with clear rationale from the identified community. However, the applicant has relevant minority opposition with clear rationale. The applicant has demonstrated majority support with clear rationale from the identified community. However, the applicant also has relevant significant opposition with clear rationale. The applicant has not demonstrated majority support with clear rationale from the identified community. Thank you Jared From: Anne ICANN <anneicanngnso(a)gmail.com> Date: Friday, August 29, 2025 at 06:30 To: Juan Manuel Rojas <jumaropi(a)yahoo.com> Cc: Justine Chew <justine.chew.icann(a)gmail.com>, Jared Erwin <jared.erwin(a)icann.org>, "subpro-irt(a)icann.org" <subpro-irt(a)icann.org> Subject: Re: [SubPro-IRT] Re: [Ext] Re: Re: Updated CPE Language for review by 27 August Thank you Juan and all, I believe that Jared's last draft of the chart as sent to the list is accurate. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso(a)gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Aug 28, 2025 at 4:06 PM Juan Manuel Rojas via SubPro-IRT <subpro-irt(a)icann.org<mailto:subpro-irt@icann.org>> wrote: Dear all, Just to clarify my position: I intended, and thought I had written, that I support Anne’s comments regarding the need for opposition to come from relevant organizations, but I do not share Justine’s broader objection to including any reference to external support or opposition. I also understood Jared’s note to be reflecting this same distinction, essentially aligning with Anne’s approach rather than removing these references entirely Best Juan On Thu, Aug 28, 2025 at 15:37, Justine Chew via SubPro-IRT <subpro-irt(a)icann.org<mailto:subpro-irt@icann.org>> wrote: _______________________________________________ SubPro-IRT mailing list -- subpro-irt(a)icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave(a)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(a)icann.org<mailto:subpro-irt@icann.org> To unsubscribe send an email to subpro-irt-leave(a)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.

4 16

REMINDER | SubPro IRT Meeting #158 | 4 September 2025, 12:00-14:00 UTC
by Next Round Policy Implementation Sept. 3, 2025

Sept. 3, 2025

Dear All, Meeting #158 of the SubPro IRT will be held on 4 September 2025 at 12:00-14:00 UTC [local time<https://tinyurl.com/yhx33rrc>]. Planned topics: New gTLDProgram: Next Round Privacy Policy; The Applicant Journey; Contention Set Resolution; Name Collision The final agenda can be consulted here<https://icann-community.atlassian.net/wiki/x/AQCREw>. Before the meeting, please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> and the ICANN Community Anti-Harassment Policy<https://www.icann.org/en/governance/documents/icann-community-anti-harassme…>. We would like to remind participants that to ensure transparency of participation in ICANN's multistakeholder model, we ask that you sign in to Zoom sessions using your full name. For example, First Name and Last Name or Surname. You may be removed from the session if you do not sign in using your full name. Zoom information: Join the Zoom Webinar directly (recommended): https://icann.zoom.us/j/97063459905?pwd=VUVsd0J0RnNtRXkyNXJFZW9vdTEzZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/97063459905?pwd=VUVsd0J0…> Meeting ID: 970 6345 9905 Passcode: DQ#0L.9x5e Zoom Audio only: One tap mobile +13462487799,,97063459905#,,,,*5806401747# US (Houston) +16699006833,,97063459905#,,,,*5806401747# US (San Jose) Meeting ID: 970 6345 9905 Passcode: 5806401747 Should you be unable to attend the meeting, please let us know in advance. A recording will be made available. Please do not hesitate to contact us should you have any questions. Best regards, Renate

1 0

Post call | SubPro IRT Meeting #157 | 2 September 2025
by Next Round Policy Implementation Sept. 3, 2025

Sept. 3, 2025

Dear All, The recordings for Meeting #157 of the SubPro IRT held on Tuesday, 2 September 2025 are published on the meeting wiki page<https://tinyurl.com/nhj9ya9t>. These include: * Audio recording * Zoom recording (including audio, visual, rough transcript, chat) * Attendance * Deck For additional information, you may consult the mailing list archives<https://mm.icann.org/pipermail/subpro-irt/> and the main wiki page<https://community.icann.org/x/pQM5Dg>. Best regards, Renate

1 0

REMINDER | SubPro IRT Meeting #157 | 2 September 2025, 18:00-20:00 UTC
by Next Round Policy Implementation Sept. 2, 2025

Sept. 2, 2025

Dear All, Meeting #157 of the SubPro IRT will be held in one hour on 2 September 2025 at 18:00-20:00 UTC [local time<https://tinyurl.com/nhj9ya9t>]. Planned topics: Registry Voluntary Commitments/Public Interest Commitments; Terms & Conditions; Conflict of Interest; Code of Conduct & Conflict of Interest Guidelines for Service Providers; General Information The final agenda can be consulted here<https://icann-community.atlassian.net/wiki/x/eYCOEw>. Before the meeting, please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> and the ICANN Community Anti-Harassment Policy<https://www.icann.org/en/governance/documents/icann-community-anti-harassme…>. We would like to remind participants that to ensure transparency of participation in ICANN's multistakeholder model, we ask that you sign in to Zoom sessions using your full name. For example, First Name and Last Name or Surname. You may be removed from the session if you do not sign in using your full name. Zoom information: Join the Zoom Webinar directly (recommended): https://icann.zoom.us/j/97063459905?pwd=VUVsd0J0RnNtRXkyNXJFZW9vdTEzZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/97063459905?pwd=VUVsd0J0…> Meeting ID: 970 6345 9905 Passcode: DQ#0L.9x5e Zoom Audio only: One tap mobile +13462487799,,97063459905#,,,,*5806401747# US (Houston) +16699006833,,97063459905#,,,,*5806401747# US (San Jose) Meeting ID: 970 6345 9905 Passcode: 5806401747 Should you be unable to attend the meeting, please let us know in advance. A recording will be made available. Please do not hesitate to contact us should you have any questions. Best regards, Renate

4 5

Independent Objectors and Brand String Change Requests
by Elisa Busetto Sept. 2, 2025

Sept. 2, 2025

Dear all, In meeting #155<https://icann-community.atlassian.net/wiki/x/KQCOEw>, we discussed whether we should retain Independent Objectors (IOs) in case of an objection period following a Brand String Change Request. As mentioned in the meeting, we believe that IOs should only be filing objections during the objection window opening on String Confirmation Day. Having a panel of IOs on retainer for an undefined period of time just to look at individual applications for what we believe will be very few cases (if any at all) seems to be excessively costly, also given the very restrictive conditions around Brand String Change Requests. We also note that there does not seem to be any specific requirements in this sense in the policy, and that comments and objections can still be submitted during this time. Thank you very much, Elisa

2 2

Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
by Phil Buckingham Sept. 2, 2025

Sept. 2, 2025

2 1

Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
by Pruis, Elaine Sept. 1, 2025

Sept. 1, 2025

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(a)gtlaw.com" <trachtenbergm(a)gtlaw.com> Date: Thursday, August 21, 2025 at 7:14 AM To: "jeff(a)jjnsolutions.com" <jeff(a)jjnsolutions.com>, Elaine Pruis <epruis(a)verisign.com>, "jared.erwin(a)icann.org" <jared.erwin(a)icann.org>, "subpro-irt(a)icann.org" <subpro-irt(a)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 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(a)gtlaw.com | www.gtlaw.com | View GT Biography From: Jeffrey J. Neuman via SubPro-IRT <subpro-irt(a)icann.org> Sent: Thursday, August 21, 2025 8:37 AM To: Pruis, Elaine <epruis(a)verisign.com>; Jared Erwin <jared.erwin(a)icann.org>; subpro-irt(a)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(a)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/nc…. 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(a)icann.org> Reply-To: Jared Erwin <jared.erwin(a)icann.org> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt(a)icann.org" <subpro-irt(a)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/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXr… 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(a)icann.org _______________________________________________ SubPro-IRT mailing list -- subpro-irt(a)icann.org To unsubscribe send an email to subpro-irt-leave(a)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(a)gtlaw.com, and do not use or disseminate the information.

8 11

Re: Deck for IRT Call #153a on 20 August 2025 at 18:30 UTC
by Pruis, Elaine Sept. 1, 2025

Sept. 1, 2025

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/nc…. 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(a)icann.org> Reply-To: Jared Erwin <jared.erwin(a)icann.org> Date: Tuesday, August 19, 2025 at 3:19 PM To: "subpro-irt(a)icann.org" <subpro-irt(a)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/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXr… 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(a)icann.org

9 13

Deck meeting #157
by Elisa Busetto Sept. 1, 2025

Sept. 1, 2025

Dear all, The deck for meeting #157 was posted to the wiki: https://icann-community.atlassian.net/wiki/x/eYCOEw Best regards, Elisa

1 1

NEW MEETING | SubPro IRT Meeting #158a | 11 September 2025, 18:00-20:00 UTC
by Next Round Policy Implementation Sept. 1, 2025

Sept. 1, 2025

Dear All, Meeting #158a of the SubPro IRT will be held on 11 September 2025 at 18:00-20:00 UTC [local time<https://tinyurl.com/2sc9f5mm>]. Planned topics: TBA The final agenda can be consulted here<https://icann-community.atlassian.net/wiki/x/AQB3Gw>. Before the meeting, please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> and the ICANN Community Anti-Harassment Policy<https://www.icann.org/en/governance/documents/icann-community-anti-harassme…>. We would like to remind participants that to ensure transparency of participation in ICANN's multistakeholder model, we ask that you sign in to Zoom sessions using your full name. For example, First Name and Last Name or Surname. You may be removed from the session if you do not sign in using your full name. Zoom information: Join the Zoom Webinar directly (recommended): https://icann.zoom.us/j/97063459905?pwd=VUVsd0J0RnNtRXkyNXJFZW9vdTEzZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/97063459905?pwd=VUVsd0J0…> Meeting ID: 970 6345 9905 Passcode: DQ#0L.9x5e Zoom Audio only: One tap mobile +13462487799,,97063459905#,,,,*5806401747# US (Houston) +16699006833,,97063459905#,,,,*5806401747# US (San Jose) Meeting ID: 970 6345 9905 Passcode: 5806401747 Should you be unable to attend the meeting, please let us know in advance. A recording will be made available. Please do not hesitate to contact us should you have any questions. Best regards, Renate

1 0