August 2025 - SubPro-IRT - lists.icann.org

IRT Call 15 May
by Lars Hoffmann Nov. 4, 2025

Nov. 4, 2025

Dear IRT members, For tomorrow’s call we have two topics: Fees and Terms and Conditions. Regarding fees, attached you will find the analysis that ICANN org has undertaken on the different conditional evaluations and the fees that this is resulting in. For those evaluations that are expected to be carried out by vendors, ICANN org plans to include an estimate (CPE and Name Collision High Risk String Mitigation Plan Evaluation) or a ‘will not exceed’ amount (Geographic Names Evaluation) so that applicants can prepare accordingly, but ICANN org will only charge actual costs incurred. You can also find the updated Application Fees section with new updates in the table on page 4-6. Note that other updates were reviewed by the IRT previously. The redline IRT language can be found here: https://docs.google.com/document/d/1kUixs9Ln2qnBYCPi3yCIALiI7v47fYiGaB2rvvU… On Terms and Conditions, we are still thinking through some of the feedback we received last week and so there is no updated redline for tomorrow’s call. But we will discuss the issues raised with the goal to move the conversation forward. I am also noting that next week Thursday (22 May) we will have an IRT call on the Base Registry Agreement, and, subject to tomorrow’s discussion, I anticipate we will revisit Terms and Conditions then, too. With that, I am looking forward to tomorrow’s call. Best. Lars

4 3

Fee quotation
by Marika Konings Sept. 5, 2025

Sept. 5, 2025

Dear IRT, As discussed during the IRT call earlier today, as part of an updated fee FAQ, we will make available a fee quotation (see attached) that is intended to help applicants make arrangements to ensure timely payment. The FAQ will also include a link to ICANN’s tax residency certificate and other tax related documents that may be needed by some. We hope this is helpful but if you have further suggestions that could facilitate the payment process for applicants, please let us know. Best regards, Marika

2 2

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

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

Length of the Objection Period
by Lars Hoffmann Aug. 29, 2025

Aug. 29, 2025

Dear IRT. We had a spirited discussion on the length of the community input period. Please review the recording<https://icann.zoom.us/rec/share/LIXUI8TxusG8h4uktdpcyZXoprReJWsLebFmiSHd-ch…> and chat (attached) if you could not join the call. As discussed, we would like to encourage an on-list discussion whether the 90-day objection filing period should be extended to 135 days, which will directly impact the length of the applicant journey. Please refer to the Draft AGB (p.47)<https://itp.cdn.icann.org/en/files/policy-development/new-gtld-program-next…> for the current estimate of the length of the shortest possible applicant journey from submission to delegation. We would kindly invite you to share your thoughts on list. Best. Lars

12 15

Updated CPE Language for review by 27 August
by Jared Erwin Aug. 29, 2025

Aug. 29, 2025

Dear IRT Members, As noted, in addition to the other changes we have made the past few days which were discussed on our calls on 14 August<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/328106025/2025…>, 20 August<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/399704065/2025…>, and 21 August<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/328171521/2025…>, we have made some updates based on our call yesterday. These are described below and in the language here<https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3…>. 1. Added the words “and verify” to relevant guidelines: “The panel may review AND VERIFY letters of support or opposition…” We also added a footnote to reference the support/opposition verification guidelines that live under Criterion 4. These changes have been made on all guidelines for all relevant criteria. * See first example on page 26 (+ footnote 26) but note that they appear throughout the document. 2. Added footnote 31 on page 29 regarding “double counting.” * Note that we also warn of not double counting more generally in section 4.4.6. 3. Made updates to clarify language in scoring table 4-9 on page 35. * Note that this was done solely to align with the language above the table at the start of Section 4.7.4.4. 4. Made changes to bullet “e” on page 36 to change “reputable” to “relevant” and provide additional examples of what this means in parentheses. * I note Anne’s comment below. I understood that we wanted to keep quasi-official but add official and established. Or was the IRT suggesting to remove “quasi-official”? As a reminder, this is language from the 2012 AGB and it will be the panel’s job to verify any letters of support or opposition and review whether any seem “spurious” or “unsubstantiated.” I would kindly request IRT members to review and provide their final input by Wednesday, 27 August 2025 so that we can finalize the language. Thank you, Jared From: Anne ICANN <anneicanngnso(a)gmail.com> Date: Thursday, August 21, 2025 at 17:07 To: Justine Chew <justine.chew.icann(a)gmail.com> Cc: Jared Erwin <jared.erwin(a)icann.org>, Next Round Policy Implementation via SubPro-IRT <subpro-irt(a)icann.org> Subject: [Ext] Re: [SubPro-IRT] Re: Deck Meeting #154 Thanks Justine. I hope that you and others will review the language about "quasi-official organizations" and others weighing in on the Nexus between the community and the string applied for. Folks seem concerned about community applicants doing the gaming, but the potential for gaming is higher here because the competitor who has applied for the same string and is not a community applicant need only hire a smart lawyer to form a new "quasi-official" organization to file a letter opposing the nexus and the application. There will apparently be no requirement to disclose what money and what party is actually behind such a "quasi-official" organization. This language opens the door to the worst sort of gaming (by the non-community competitor) and we need to avoid it. Wish we could all keep in mind that for legitimate objectors, we have the Community Objection. I don't think anyone on the IRT should be trying to save an Objector from having to file. It's the remedy that Sub Pro affirmed. Anne Anne Aikman-Scalese GNSO Councilor NomCom Non-Voting 2022-2026 anneicanngnso(a)gmail.com<mailto:anneicanngnso@gmail.com> On Thu, Aug 21, 2025 at 9:51 AM Justine Chew via SubPro-IRT <subpro-irt(a)icann.org<mailto:subpro-irt@icann.org>> wrote: Dear Jared, Thanks for this but I'm afraid I can't make the call later and hence request for time over the weekend to provide comments to the language changes you speak of and any further changes arising from today's call. Kind regards, Justine --------- On Fri, 22 Aug 2025, 00:01 Jared Erwin via SubPro-IRT, <subpro-irt(a)icann.org<mailto:subpro-irt@icann.org>> wrote: Dear IRT members, Also wanted to note that we have made changes to the CPE language based on our discussion yesterday. We can review those changes today. * See here: https://docs.google.com/document/d/1rH19XrXglbfYj-TyioFsj4siNECKeR5J7Gfdvk3… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1rH19XrXglbfY…> Thank you Jared From: Elisa Busetto via SubPro-IRT <subpro-irt(a)icann.org<mailto:subpro-irt@icann.org>> Reply-To: Elisa Busetto <elisa.busetto(a)icann.org<mailto:elisa.busetto@icann.org>> Date: Thursday, August 21, 2025 at 08:32 To: "subpro-irt(a)icann.org<mailto:subpro-irt@icann.org>" <subpro-irt(a)icann.org<mailto:subpro-irt@icann.org>> Subject: [SubPro-IRT] Deck Meeting #154 Hello IRT members, Just a quick note to let you know that we have published the deck for the call today: https://icann-community.atlassian.net/wiki/x/AYCPEw [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/AYC…> Best, Elisa _______________________________________________ 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.

8 27

Post call | SubPro IRT Meeting #156 | 28 August 2025
by Next Round Policy Implementation Aug. 29, 2025

Aug. 29, 2025

Dear All, The recordings for Meeting #156 of the SubPro IRT held on Thursday, 28 August 2025 are published on the meeting wiki page<https://icann-community.atlassian.net/wiki/x/UYCOEw>. 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 #156 | 28 August 2025, 18:00-20:00 UTC
by Next Round Policy Implementation Aug. 28, 2025

Aug. 28, 2025

PLEASE NOTE THE CHANGE OF TIME – THIS CALL WILL NOW BE FROM 18:00 TO 20:00 UTC DO NOT FORGET TO UPDATE YOUR CALENDAR Dear All, Meeting #156 of the SubPro IRT will be held in one hour on 28 August 2025 at 18:00-20:00 UTC [local time [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/mrexfxpw__;!!PtGJab4!5jXCFCe…>]. Planned topics: Module 6: String and Application Evaluation Procedures The final agenda can be consulted here [icann-community.atlassian.net]<https://urldefense.com/v3/__https:/icann-community.atlassian.net/wiki/x/UYC…>. 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

Deck and AGB Language for IRT Call #156 on 28 August 2025 at 18:00 UTC
by Jared Erwin Aug. 27, 2025

Aug. 27, 2025

Dear IRT Members, The deck for our 28 August 2025 call has been posted on the meeting page<https://icann-community.atlassian.net/wiki/spaces/SPIR/pages/328106065/2025…>. The relevant AGB language can be found here in Module 6<https://docs.google.com/document/d/1bNMs0Uve0CsSFjGDgbgIUs4nJj1gEjowKXWrNXr…>. As mentioned on the call today, the agenda for the call includes several topics related to Module 6: 1. Welcome and SOI Update 2. Module 6: String and Application Evaluation Procedures * Internationalized Domain Names (IDNs) * String Similarity Evaluation * Blocked/Reserved Names * Geographic Names * Brand TLD Eligibility and Code of Conduct Exemption Eligibility * PICs/RVCs 3. Upcoming IRT Meetings 4. AOB Note: The team needs a bit more time to consider the name collision feedback from last week. We plan to discuss the topic in one of our calls next week. We will confirm in the coming days. 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<mailto:jared.erwin@icann.org>

1 0