If no, please explain

ENS agrees that the language in draft Module 1: The Applicant Journey is consistent with Board-approved recommendations, and that the concepts in this module are consistent across the AGB. However, we would request one content refinement for the final AGB. Specifically, Rights Protection Mechanisms (RPMs) are addressed only very briefly in the AGB, in section 1.2.17 (Dispute Resolution Procedures After Delegation), in which the PICDRP, RRDRP, and TM-PDDRP are mentioned, with a link (to a resource outside the AGB) provided for other RPMs. As we believe the AGB should be a comprehensive resource for those interested in learning more about the new gTLD program, we suggest including an Appendix in the final AGB that describes the RPMs (particularly including the Trademark Clearinghouse and Uniform Rapid Suspension System, as well as those listed above) in greater detail. As 14 years will have passed since the 2012 new gTLD application round, there will likely be many newcomers to the ICANN community for the planned 2026 round. These newcomers will include not only prospective applicants, but also intellectual property rightsholders who are seeking to understand how the expansion of the DNS may impact them and who need to plan for budgets and other strategic considerations in light of these changes. Including the RPM information in an appendix would ensure that this information is easily accessible to all members of the community.

If no, please explain

ENS agrees that the language in draft Module 2: Application Submission is consistent with Board-approved recommendations, and that the concepts in this module are consistent across the AGB. However, we do have some concerns regarding one aspect of the application submission process, the Prioritization Draw. Specifically, we would request clarification on why ICANN has chosen to require purchase of tickets for the Prioritization Draw in person, particularly when the Draw itself will only be held virtually. This would seem to be a cumbersome and potentially cost-prohibitive step for some applicants, particularly those applying under the Applicant Support Program or applicants from underrepresented regions. If ICANN is not able to reconsider requiring purchase of tickets in person, at a minimum, we would request that details of the Draw be announced far more than 30 days in advance (the current timeline stated in the AGB), including the physical location for purchase of the tickets and the cost of each ticket, so that applicants can plan accordingly. Otherwise, ICANN would seem to be prioritizing processing of applications for applicants who have substantial financial resources and who can travel easily on short notice, an approach that seems counter to ICANN’s goal of increasing the global reach of the new gTLD program, and diversity of its applicants, in the 2026 round.

If no, please explain

ENS agrees that the language in draft Module 3: Community Input, Objections, and Appeals is consistent with Board-approved recommendations, and that the concepts in this module are consistent across the AGB. However, while the procedures detailed in this module are clear, we remain concerned that ICANN has not yet published even rough estimates of ranges for the expected fees in connection with the objection processes. As of this comment period (July 2025), many organizations, whether or not they are planning to apply for their own new gTLDs, are in the process of completing their budgets for 2026. Due to the complete lack of information regarding objection fees, organizations that have concerns that their rights may be infringed by new gTLD applications cannot yet budget accordingly. In a similar vein, all new gTLD applicants may need to be prepared to receive objections to their applications. For new gTLD applicants, being able to budget for objection fees is particularly critical because if they receive objections, they will need to pay the objection fees within a very short window in order to be able to continue with their applications. Accordingly, we urge ICANN (and its selected dispute resolution providers) to publish at least anticipated ranges of objection fees as soon as possible, and certainly well before the final AGB is published in December 2025, so that all organizations with an interest in the new gTLD program are able to plan accordingly.

If no, please explain

ENS agrees that the language in draft Module 6: String and Application Evaluation Procedures is consistent with Board-approved recommendations, and that the concepts in this module are consistent across the AGB. However, ENS requests that ICANN consider refinements in three areas of this module: Geographic Names (Section 6.5); Name Collision (Section 6.7); and String Similarity Evaluation (Section 6.10). Regarding geographic names, we appreciate the clarity ICANN provides regarding the non-availability of country and territory names in the upcoming new gTLD round, as well as the documentation required in connection with capital city names. However, more clarity is needed regarding the consideration of strings for certain other types of geographic names, particularly, applications for city names that are not intended to be used in as a reference to the actual city. We are concerned, in particular, that private applicants may be able to obtain new gTLDs for major city names (that are not capital cities), creating confusion in the DNS by operating those new gTLDs for purposes unrelated to the geographic location (i.e., as brand names). In addition, ICANN states, in Section 6.5.2, that “Strings that include but do not exactly match a Geographic Name as defined in this section will not be considered Geographic Names.” Accordingly, it appears that strings that are very close variants of geographic names will not be subject to additional scrutiny, even if the existence of such gTLDs may cause confusion in connection with geographic locations. We understand that there are literally millions of geographic and place names globally, and that ICANN cannot, of course, exclude all of them from being eligible as new gTLD strings; however, we request that the string evaluation consider whether applications for strings for well-known geographic names (that do not strictly fall under the criteria listed in this section), as well as close variants of geographic names, may cause confusion in the DNS. Regarding name collision, we urge ICANN to require applicants for strings that are assessed to be high-risk to submit their High-Risk String Mitigation Plans before, not after, contention sets are resolved. We maintain that applicants should not be able to prevail against other applicants for the same strings without presenting such plans, as a great disservice may be done to the competing applicants if such High-Risk String Mitigation Plans are not successfully evaluated. While we appreciate that changing the order of this process will result in additional time and expense for all such applicants, this is the only consistent way to ensure that all applicants for high-risk strings have an opportunity for a fair evaluation. Applicants who pass their High-Risk String Mitigation Evaluations could then all proceed to the auction phase of contention set resolution. An even greater concern, however, in the name collision area is the existence and use of what are likely to be highly sought after strings in alternative name spaces outside of ICANN governance, which have been operating for some time unconstrained by – and without regard for – ICANN policies and contractual obligations. Current operators of such strings are very likely to apply for identical new gTLDs in the upcoming round. This is a growing concern within the ICANN community, particularly in the technical constituencies such as the SSAC, which has formed a RIDE Working Party to study such issues, as discussed extensively during ICANN83 in Prague. ICANN should consider that a new gTLD, for which an identical string already exists in an alternative name space, should be considered a compromised asset, and that delegating such gTLDs may subject ICANN, and applicants, to substantial liability. In addition to the technical issues posed by name collision, such delegations could also result in consumer confusion, difficulties with resolving queries (particularly as access to alternative names is increasingly integrated into mainstream web browsers), security risks, and broken authentication systems. We urge ICANN to ensure that operators of strings in alternative names spaces are not given preferential treatment in the upcoming new gTLD application round, either deliberately or inadvertently. Such operators should not be rewarded for choosing to operate outside of ICANN governance and policies, particularly when the results of such preferential treatment could be so devastating for the stability of the DNS, as well as consumer trust in the new gTLD program and the DNS itself. ICANN’s policies against such preferential treatment date back to ICP-2, issued in July 2001, and ICANN should not, in any way, reverse these policies now. While there is not a simple solution to the complex issue of likely name collisions at the intersection of alternative name spaces and the new gTLD program, we suggest that the GNSO study this issue in detail, integrating the advice and concerns of the SSAC RIDE Working Party, before ICANN proceeds to allow delegation of strings that already exist in alternative name spaces. In particular, the Intellectual Property Constituency (IPC) should also have an opportunity to assess how to mitigate the substantial risk to brand owners that may result from delegation of such strings, particularly as such strings currently exist in spaces that are not subject to ICANN’s Rights Protection Mechanisms. We believe such an effort is important in the context of these specialized strings is justified because there is no simple way to prevent collisions while simultaneously (a) respecting existing rights of name holders in alt DNS spaces, (b) migrating names from alt DNS to ICANN-authorized DNS spaces, and (c) respecting the carefully structured manner by which ICANN has prescribed the launch of any new gTLD to respect the rights of trademark holders (i.e., requiring sunrise / landrush periods for registration, etc.). In short, migrating names from the zone file of an existing alt DNS TLD to a new gTLD is not simple and requires further serious consideration. Regarding the string similarity evaluation, we agree that ICANN does clearly delineate the types of strings that will be compared against each applicant string. However, we note that the string similarity evaluation does not appear to account for strings that may exist in alternative name spaces that are not under ICANN governance. Given the proliferation of such strings and alternative name spaces in recent years, ICANN should not ignore their existence by considering string similarity within only the ICANN-governed DNS, particularly due to the technical issues outlined above in connection with name collision.

If no, please explain

ENS agrees that the language in draft Module 7: General Information is consistent with Board-approved recommendations, and that the concepts in this module are consistent across the AGB. However, we do have concerns regarding the AGB information on Security and Stability (Section 7.5). This section only addresses one aspect of security and stability, the rate of delegation of new gTLDs. While we agree that this is one important element of maintaining the security and stability of the Internet – ensuring the root zone is not flooded with an inordinate number of new gTLDs at one time – it is not the only aspect of security and stability that ICANN should consider. Specifically, we request that ICANN expand this section to address name collision issues, or at least cross-reference the name collision section of the AGB as detailed in Module 6, as name collisions could destabilize the DNS and result in consumer confusion and loss of trust.

If no, please explain

ENS agrees that the language in draft Appendix 7: Conflict of Interest Process for Service Providers is consistent with Board-approved recommendations, and that the concepts in this module are consistent across the AGB. However, we request that ICANN further clarify the conflict check process for the technical experts who will be conducting the High-Risk String Mitigation evaluations in connection with name collision. In particular, it is essential that such evaluators do not have a financial interest in strings associated with alternative name systems that may result in name collisions, especially as the conflict clearance process appears to be primarily based on self-disclosure rather than extensive third-party background investigation.