If no, please explain

ENS agrees that the proposed language in connection with Topic 9: Registry Voluntary Commitments / Public Interest Commitments is consistent with the SubPro recommendations. However, we would request clarifications on a few of the points addressed in this topic. First, in connection with Section 2 on Safeguard PICs, ICANN has provided a number of phrases that must be included in the Registry Agreements for certain applicants who are determined to be required to meet additional safeguards. However, ICANN should state whether these phrases must be included in the Registry Agreements exactly as written by ICANN, or if any of the Safeguard PICs may be revised or customized in any way. In the final draft AGB, we request that ICANN specify the fees, or at least the likely range of fees, associated with undergoing a Registry Commitments Evaluation (Section 3.2). Finally, in Section 5 on ICANN Compliance, ICANN should detail what penalties may be assessed upon a new gTLD registry operator if the registry operator is determined to be in non-compliance with a PIC, RVC, or Community Registration Policy.

If no, please explain

ENS agrees that the proposed language in connection with Application Questions is consistent with the SubPro recommendations. As one minor point, we would request that ICANN should state whether there are any word limits or other length limitations or guidelines for the questions requiring narrative responses, so that applicants may begin planning their application processes and project plans accordingly.

If no, please explain

ENS agrees that the proposed language in connection with Application Fees is consistent with the SubPro recommendations, and generally clear. However, in addition to the standard application fees, ICANN has listed a number of conditional evaluation categories that will or may require additional evaluation fees. All of these fees are currently listed as “TBC.” We request that ICANN specify these fees, or at least provide a likely range for them, in the draft final AGB so that applicants can begin to budget accordingly in advance of the application process. Particularly as some of these fees are likely to add substantially to the basic application fee, and as these fees, when required, will need to be paid with a short turnaround time in order for applicants to continue with their applications, an understanding of the potential additional fees is necessary to ensure that potential applicants can reserve the necessary funds.

If no, please explain

ENS agrees that the language proposed for Topic 18: Terms & Conditions is consistent with the SubPro Final Report recommendations. However, we request that ICANN further clarify the language in Paragraph 15 on limitations on discussions with other applicants. We understand this general prohibition is to avoid collusion and negotiations that may prove unfair to some applicants and to require all applicants to participate in ICANN-administered string contention, objection and auction processes as needed. However, ICANN should further detail the types of discussions that are and are not permitted, given that new gTLD applications will be published and will be a general topic of discussion in the ICANN community for at least the next several years while the application evaluations are ongoing.

If no, please explain

ENS agrees that the proposed language in connection with Financial & Operational Evaluation is consistent with the SubPro recommendations. However, we would request that ICANN provide a few minor clarifications in the final draft AGB language. First, in Section 2.2 on Financial and Operational Evaluation Criteria, ICANN has provided a requirement for applicants to have a certain amount of cash on hand. ICANN should clarify if this cash on hand requirement also applies to applicants applying under the Applicant Support Program, or if there is a proportionally reduced cash on hand requirement for ASP applicants. Next, in Section 2.3 on Clarifying Questions, we request that ICANN provide an estimated time frame during which applicants will be required to respond to CQs in order to continue with their applications. Finally, in Section 2.4 on Extended Evaluation, we request that ICANN specify if there is an additional fee required for applicants who request an Extended Evaluation due to not passing the initial Financial and Operational Evaluations.

If no, please explain

ENS agrees that the proposed language in connection with Name Collision is consistent with the SubPro recommendations. However, we would request clarification on several points in the draft final AGB. First, in Section 4 on Temporary Delegation and Final Assessment, ICANN indicates that the DNS root zone may not grow by more than 5% per month. We hope that ICANN can expand this language to specify how strings will be queued for temporary delegation, and in addition, if ICANN could provide an estimate of potential wait times in the temporary delegation queue so that applicants may plan accordingly. Next, in Section 5.1 on the High-Risk String Mitigation Plan, we request that ICANN clarify if there is any additional cost to applicants who must submit a Mitigation Plan to proceed with their applications. Regarding Challenges to the Mitigation Plan Evaluation (Section 6), we request that ICANN specify whether, if a challenge to a Mitigation Plan evaluation is successful, the application will be terminated or if the applicant will have any opportunities to make additional revisions to the plan, and if so, how that process would evolve. Finally, regarding Section 7 that relates to Interaction with Variants, we request that ICANN specify how much time applicants will have to amend their applications to remove a variant label, upon receiving the assessment that a particular label is high risk. More broadly, in addition to the clarifications above, we request that ICANN consider reviewing several ancillary but critical matters relating to Name Collision before finalizing AGB language. One such issue is that we note that, if applications are in a contention set, ICANN does not require that applicants submit a High-Risk String Mitigation Plan until after the contention set is resolved. While we understand that ICANN may wish to avoid requiring applicants in contention sets that have not been resolved to invest the time and additional fees required to submit a Mitigation Plan, ultimately, we are concerned that not requiring and reviewing the Mitigation Plan until later may do applicants a disservice. Specifically, if an auction is ultimately required to resolve a contention set, applicants may make very substantial additional investments only to learn that a Mitigation Plan is required, which may or may not be accepted to allow the application to proceed to delegation. Accordingly, we suggest that ICANN consider identifying high-risk strings, and requiring Mitigation Plans as needed, much earlier in the application process. On another note, we understand that, to date, Name Collision issues have only arisen very rarely in the DNS. However, with specific regard to high-risk strings, we would like to flag that, due to the proliferation of alternative name spaces in recent years that are not under ICANN governance and which have not respected ICANN policies, there is a much higher potential for Name Collision issues in the forthcoming new gTLD round, particularly without additional procedural changes and safeguards in place. This is precisely because many operators of such alternative name spaces are likely to apply for identical new gTLDs in the coming round and – depending on whether such applicants successfully or unsuccessfully become TLD operators for those strings that are already extant and in use – delegation of those strings could potentially result in a myriad of problems, including (i) Name Collisions, (ii) consumer confusion, (iii) resolution conflicts arising from queries to alternative roots, (iv) security risks from unintended DNS consequences, and (v) potentially even broken authentication systems should consistent TLD resolution be impacted – all of which affects the integrity of the DNS as a source of truth and Internet users’ trust in the DNS. At a minimum, we would request that current operators of alternative roots not be given any priority or preferential treatment if they apply for identical new gTLDs in the upcoming round. Such a policy would track with ICANN’s ICP-3 (July 2001), which prohibits such preferential treatment. (See ICP-3: A Unique, Authoritative Root for the DNS, at Section 4, Outside the Process, available at https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-en) (“Some of these [alternative name space] operators and their supporters assert that their very presence in the marketplace gives them preferential right to TLDs to be authorized in the future by ICANN . . . under the philosophy that if they get there first with something that looks like a TLD and invite many registrants to participate, then ICANN will be required by their very presence and force of numbers to recognize in perpetuity these pseudo TLDs, inhibiting new TLDs with the same top-level name from being launched through the community's processes.”) However, because the above negative consequences on the DNS can significantly erode public trust in the Internet and ICANN processes, we would urge ICANN to carefully study the issue of potential name collision impact arising specifically from co-existing identical TLDs and alternative roots from both a technical and policy perspective. With the issue of DNS stability on the table, studying this issue through a Policy Development Process Working Group before allowing such new gTLD applications to proceed through the evaluation and delegation process would be consistent with ICANN’s fundamental mandate. The results of such a PDP would inform whether and how such new gTLD applications might be able to proceed without impacting DNS stability by, e.g., implementing certain collision mitigation safeguards that security researchers and the public have had ample opportunity to review, prioritizing specific roots for DNS resolution, or such a PDP may conclude that delegation at this time for certain high-risk strings should be delayed.

If no, please explain

ENS agrees that the proposed language in connection with the Community Priority Evaluation is consistent with the SubPro recommendations. However, we would suggest a few minor revisions to be included in the draft final AGB. First, in Section 1.3 on Conditional Fees, we request that ICANN provide a general range of what additional fees may be required so that organizations considering submitting a Community application, which may ultimately require a Community Priority Evaluation, can begin budgeting for this possibility, particularly as we understand that these fees may be substantial. Next, in Section 1.4.1 on Clarifying Questions, we request that ICANN specify the time frame, or likely time frame, that CPE applicants will have to respond to any Clarifying Questions issued. Finally, we submit that requiring a score of 12/15 (80%) on the Community Priority Evaluation may be a particularly high bar that is difficult for many legitimate Community applicants to meet and would suggest an alternative of requiring a score of 10/15 instead, with the caveat that successful CPE applicants may not score a zero in any of the four categories. During prior ICANN meeting sessions discussing Community applications for the upcoming new gTLD round, ICANN staff had stated that an assessment of the 2012 application round indicated that criteria were too stringent at that time, resulting in missed opportunities for potential Community applicants. As ICANN has clearly invested significantly in developing procedures for Community applications, it would be unfortunate if there is a similar result to the 2012 round in which very few applicants could take advantage of Community Priority.

If no, please explain

ENS agrees that the proposed language for Contention Set Resolution is consistent with the SubPro recommendations. However, in Sections 2.1 and 2.2, we request that ICANN amend the language to specify that the prohibition on communications among applicants is limited to the contention set resolution period. Due to general participation in the ICANN ecosystem, prospective applicants may wish to communicate regarding aspects of their prospective applications before contention sets are published and may wish to share information on their applications and business strategies once contention sets have been resolved. While these details are implied, we request that ICANN state this more explicitly, particularly as violations may have very severe consequences, including being permanently barred from participation in the new gTLD program. In addition, in Section 3.1.1 on Replacement Strings, we request that ICANN specify that each application may only designate a single Replacement String, aside from any variants. In addition, regarding Section 4.3 on the ICANN New gTLD Auction, we request that ICANN clarify how auction proceeds will be used to benefit the ICANN community, as this is not discussed in the section and may be a consideration for whether applicants in contention sets wish to proceed to participation in auctions.

If no, please explain

ENS agrees that the proposed language for Brand Eligibility Evaluation (Section 13) is consistent with the SubPro recommendation. As one minor point, in Section 1.3.1 on Required Documentation, the requirements state that the applicant seeking Brand eligibility must provide a “trademark registration.” However, we request that ICANN specify if this must be a current national trademark registration (or what types of registrations are eligible), and if the applicant must provide a copy of the certificate of registration, as well as whether there were any circumstances under which common law rights to a mark would suffice. In addition, we request that ICANN state whether applicants must keep the trademark registration in good standing (i.e., complete any applicable renewals or other required filings) during the new gTLD and Brand Eligibility evaluation processes.