Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.
If no, please explain
Implementation Guidance 9.6 recommends that a panel of experts in regulated industries determine whether applied-for strings should be subject to the Safeguards described in Section 2 of Topic 9 of the AGB. As written, the AGB gives ICANN org the power to determine whether a given string falls into one of the categories warranting additional safeguards. Further, the rationale for 9.6 is to promote predictability for applicants. We would suggest bolstering the language in 2.1 to describe the questions applicants will need to answer. As an added point, the RySG believes that the text of the PICs, especially Safeguard PICs, should be considered a starting point for applicants to draft contractual terms. Applicants should have the ability to refine the text of the PICs to fit their specific needs and circumstances.
If no, please explain
In Question 59, there are two references to a person exerting “Significant Influence”, but no definition as to what that means? As this is referenced as a defined term, can you please provide that definition. Question 105 refers to the ASP handbook which we believe is a typo.
If no, please explain
Implementation Guidance 18.5 states that applicants who apply for a new gTLD that is later not approved because of a high risk of name collision should be granted a full refund, but this refund is not contemplated in this document. This comment concerns Topic 15.3 Application Fee Refunds. The SubPro Final Report emphasizes the importance of a predictable, fair and transparent refund process to ensure applicants are not exposed to unnecessary financial risk. Of course, this also needs to be balanced against limiting any potential attempts to game the process. As a result of the prohibition on private resolution, ICANN’s Auction of Last Resort will now be the only mechanism to settle contention sets and will generate revenue for ICANN. This future source of resources makes the equitability of the application fee refund schedule even more vital. So, while the draft Guidebook language may reflect the original recommendation, the prohibition on private resolution has changed the overall landscape and process for applicants and therefore justifies review and revision. The RySG proposes the following additions to the current proposed schedule of refunds to ensure a predictable process: (1) Applicants that decide to withdraw their applications after string confirmation day should be entitled to a larger refund percentage. In the last round, Applicants were offered a refund of 80% if they withdrew at this point, and the RySG believes that it would be appropriate to do the same in this round. Although admittedly not many applicants in the last round withdrew at this point, that may have been due to the fact that private resolution of contention sets allowed flexibility to form partnerships, joint ventures, or other collaborative arrangements to settle contention sets. However, by prohibiting private resolution, we believe there may be more applicants that will opt to withdraw shortly after String Confirmation Day. (2) GAC Early Warnings: In line with the 2012 Round of gTLD application fee refunds, applications that are withdrawn pursuant to a GAC Early Warning and within 21 days of such an Early Warning should receive a refund of 65%. Such withdrawals currently fall under the second refund tranche, i.e., 35%, the RySG firmly believes that GAC Early Warnings for specific strings can potentially introduce uncertainty for an applicant as they may have significant implications for the operation of the prospective TLD. As a result, this should be an exceptional situation that warrants this higher refund percentage. (3) Community Priority Evaluations: Similar to point 1 above, non-community based applications that are withdrawn pursuant to another application for the same string that prevails under a Community Priority Evaluation should also be eligible to receive a refund of 65% (i.e., eligible for the refund percentage for the current first refund window). Considering the advantages of a community application, and the inability to know if your application will be in a community contention set, even at the time of String Confirmation, losing applicants in a Community Priority Evaluation should be eligible for the 65% refund. (4) Applicant Support Program Applicants: ASP Applicants that withdraw their application at any stage of the application process should receive a full refund of the portion of the applicable application fee that they paid. Currently, the Applicant Support Program estimates a fee waiver of 75-85% of the application fees. As a result, certain ASP candidates that withdraw during the third refund schedule (20% refund) may still end up forfeiting a certain amount of their application fees. ASP candidates should receive a full refund of the application fee that they contribute regardless of when they may withdraw their application.
If no, please explain
Paragraph 1: The term “material” should be clearly defined in this section. Paragraph 3: The RySG notes that the sentence “Applicant acknowledges and agrees that ICANN has the right to determine not to proceed with any and all applications for new gTLDs, including this Application, and that there is no assurance that any additional gTLDs will be created” could be misconstrued as giving ICANN the power to cancel the New gTLD Program in its entirety, which would constitute overriding a Consensus Policy. We recommend clarifying this text to ensure it is consistent with ICANN’s Bylaws. Paragraph 9: Assignment Provisions: On April 30, 2023, the ICANN Board resolved to “provide greater clarity to applicants regarding the transparency and notification requirements throughout the application and auction process” with respect to agreements entered into pre-delegation to assign (or transfer change of control) immediately post delegation. The current Terms and Conditions does not provide that additional clarity. in fact, by removing the words in Topic 18, Section 9, “applicant’s rights or obligations in connection with the application” from Module 6, Section 10 of the 2012 Applicant Guidebook, ICANN seems to be implying that changes of control are allowed without ICANN consent during the application phase creating much more uncertainty in what is and what is not allowed. Change of Control does not require, and is not the same thing as, an assignment of the application - yet both may result in the ability to mask the underlying applicant during the application process thereby allowing that applicant to avoid being evaluated by ICANN and the community. The RySG recommends, in line with the ICANN Board resolution, that more clarity be added as to what is what is not allowed. Examples include: (1) Can an applicant assign the rights of its application, but not the actual application itself, to a third party? If this is allowed, then (a) would that require ICANN consent; and (b) would that trigger the required Applicant Change process? (2) Can an applicant agree with a third party to a future assignment of the Registry Agreement in exchange for funding in an Auction of Last Resort? If this is allowed, the RySG notes that the third party will have effectively avoided much of the application process, including, Objections, public comment, Government Early Warnings, GAC Consensus Advice, etc. Paragraph 13: The text regarding ICANN’s ability to amend the AGB should reference the SPIRT process. Similarly, the reference to advice received by ICANN from ICANN Advisory Committees should be limited to advice that is received and adopted by the ICANN Board. Paragraph 15: This paragraph needs to be updated with citations to the relevant sections of the AGB.
If no, please explain
There seems to be an error in the questions included in this section relating to DNS Abuse. The questions provided require documentation of government support, which does not align with the text of Q5.2-1 in the Application Questions document.
If no, please explain
There appears to be an inconsistency between this draft section of the AGB and the information ICANN has published regarding the Registry Service Provider Evaluation Program (see: https://newgtldprogram.icann.org/en/application-rounds/round2/rsp). The latter indicates that Registry Service Providers will only be evaluated during two periods: from 19 November 2024 to 20 May 2025 (Pre-Evaluation Period) and during the application submission window. ICANN says explicitly, “ICANN org plans to close the submission period when the Next Round gTLD application submission period closes.” This statement does not seem to align with the draft section of the AGB, which states that applicants may specify their RSP(s) after submitting their applications. The RySG is concerned about this discrepancy and the impact its restriction may have on competition. We believe applicants should have the ability to designate an RSP following application, i.e., during the evaluation process, even if doing so would require opting for Extended Evaluation and/or incurring higher evaluation costs, and requests that ICANN resolve this apparent inconsistency.
If no, please explain
It is not clear from the proposed text whether the reports described in each of the final paragraphs of Section 3 and 4 under this Topic are the same report. We recommend ICANN staff refine the language to add this clarity, by naming the actual report(s). Additionally, it is not clear from Section 3 under this Topic who will perform the Initial Assessment. Related to this point, it is unclear what will be done with the feedback from the described Public Comment Period. We recommend ICANN staff update this Section to provide additional clarity. The role of the panel of technical experts in evaluating the High Risk Mitigation Plan is not clear from the text of Section 5 under this Topic. As written, it seems that the panel provides advice to ICANN org, but that the final decision on the approval of the Mitigation Plan is made by ICANN staff. If this is the case, we recommend ICANN provide more guidance on the weight given to the opinion of the panel and under what circumstances ICANN may go against the recommendation of the panel. Furthermore, the origin, composition, and operation of the Evaluation Challenge Service Provider, mentioned in Section 6 under this topic, are unclear in this context. We recommend ICANN staff update this section to provide additional clarity, either with expository text or a reference to another section of the Next Round Applicant Guidebook. Also, we note that in some portions of Section 6, the Evaluation Challenge Service Provider seems to be referred to as the Evaluation Service Provider. Finally, Applicants need clarity on what ICANN considers “personal data” under Section 5.1 of this document, such that the information will not be disclosed to the applicant. The ability of an applicant to propose an adequate Mitigation Plan requires access to full name collision data. The community should have an opportunity to weigh in on ICANN’s determination of what it considers “personal data” not subject to disclosure under this Section. Furthermore, the RySG recommends that ICANN consider the development of appropriate data processing agreements to allow ICANN to disclose the personal data to applicants so they can prepare an adequate Mitigate Plan.
If no, please explain
The last sentence of Section 1.2 under this Topic should also reference all comments received during the applicant comment period. The CPE panel should consider both comments in support and comments in opposition to the application, submitted during the application comment period. Similarly, the CPE panel should observe the Objections process to ensure that formal Objections submitted on an application also factor into the evaluation. In Section 1.4, the final version of the AGB would benefit from defining what constitutes “Limited Research.” Regarding section 1.4.1, we believe that a new set of panelists should be required, not merely suggested, to review Evaluation Challenges. Section 1.6.1.1.B.b - Engagement: The definition for Active and Consistent should include evidence of active and consistent engagement. Currently, this section only identifies the types of activities that can be considered as engagement. Applicants must provide evidence of REGULAR interactions with the community, and ACTIVE engagement, not just merely being a passive member. In fact, scoring elements that rely on binary criteria seem ill-suited to the task of evaluating how communities truly function. We would suggest adjusting the overall scoring system to allow for additional nuance - this could mean increasing the number of total available points and commensurately increasing the threshold by which an applicant would be evaluated successfully. Finally, we believe that the text in Section 1.5 about the CPE process being designed to weed out both false positives and false negatives should be elevated to the very beginning of the AGB section on Community Applications and CPE.
If no, please explain
The lack of diagrams in Section 1.2.2. regarding indirect contention made review very difficult. The RySG recommends that all diagrams and other images throughout the AGB be included in the final comment proceeding. The AGB should be clear when the prohibition on communications between applicants begins; it is currently not clear. The RySG wishes to express strong concerns related to the prohibition on applicants making public statements “that provide direct or indirect information related to their application(s) or application strategies for strings that are in contention.” A number of future applicants have already publicly disclosed strings they intend to apply for when the application window opens, similarly, we are concerned that this could prevent applicants from discussing information related to their fundraising, since this could indicate possible auction strategies. Furthermore, the Guidebook does not provide a time restriction on this prohibition – will future applicants who have already announced their intended strings be found to be in violation of the AGB if those strings end up in contention? Finally, we would like to express our concerns that the rule prohibiting communications between applicants may be used to unfairly cast doubt on the conduct of an innocent applicant. For example, once an allegation that a prohibited communication occurred, it may be very difficult to prove that such a communication did not occur and such an investigation could use significant resources of both the applicants and ICANN.