1) Section 1 requires Applicants to notify ICANN “within 5 days” of an event triggering an obligation to notify ICANN.  This should be updated to specify that the Applicant must notify ICANN within 5 business days.

2) Section 3 [for Applicant Support Program]. The RySG supports the language in this section regarding the fact that approval for Applicant Support does not increase your chances in getting a string through the New gTLD Application process.

We recommend that ICANN consider adding a similar statement to the effect that an applicant that does not qualify for Applicant Support is not disadvantaged in the ultimate new gTLD application process either. 

3) Section 4. The Terms and Conditions in Section 4 state: “. . . If prior to the delegation of a new gTLD ICANN determines, in its sole discretion, that the Applicant’s financial conditions have changed and the Applicant would not have qualified for the financial support under the Applicant Support Program, then (a) at ICANN’s request the Applicant will pay ICANN the full gTLD evaluation fee promptly upon request, or (b) ICANN may reject the Application without any liability or recourse to the Applicant.”

The RySG understands and agrees with the objectives of this language, namely, to prevent any gaming in the process for applying for applicant support.  And the RySG completely agrees that if it has been determined that there was gaming or fraud, then ICANN should have (a) and (b) as remedies.

That said, we also believe that this language can be used to penalise legitimate applicants that are able to raise money for its operations and launch after being approved by ICANN for aid with the application process.  In fact, we should be encouraging these applicants to raise additional funds, not to pay ICANN back, but rather to get their “business” off the ground, hire staff, innovate, etc.  Applicant Support should never be considered a loan which must be repaid.

Example:  An Applicant applies for financial support, and they demonstrate that it did not have the resources for the $300,000 of application fees.  ICANN awards the support. Once they are approved for financial aid, it may have to go to ICANN auction during contention resolution (or even if it does not, it needs resources to launch and get started).  If an investor (or group of investors) offers to contribute $10M to the applicant to participate in an auction and/or for start-up costs, this would be considered a “change in the financial conditions.”  And, if they had had that investment initially, they would not have qualified for the Applicant Support program.  ICANN should not demand repayment (or reject the application) simply because of this change in circumstances.  We should be encouraging this type of behavior, not penalising it.

This language should be revised to state, “If prior to the delegation of a new gTLD ICANN reasonably determines, in its sole discretion, that the Applicant either (a) misrepresented its financial situation at the time it submitted its application for applicant support, (b) was dishonest, untruthful, or withheld material information in its application for Applicant Support, or, (c) if ICANN becomes aware of facts which, if had been known at the time the decision to award financial aid, would have disqualified the Applicant from receiving support under the Applicant Support Program, [delete - conditions have changed and the Applicant would not have qualified for the financial support under the Applicant Support Program - end deletion] then (a) at ICANN’s request the Applicant will pay ICANN the full gTLD evaluation fee promptly upon request, or (b) ICANN may reject the Application without any liability or recourse to the Applicant.”

This would address gaming or fraud, but not penalise an Applicant that due to its success is able to raise money.

4) We note that the Agreement does not contain a  non-assignment clause.  This would allow an Applicant that received applicant support to assign its Applicant Support to another party or to one that may not have initially qualified for that support.  It would also allow an entity that never went through evaluation to purchase the evaluated RSP prior to the application process without having gone through the background checks and other requirements of the RSP program. 

The RySG notes that clarity around whether these types of assignments are acceptable or not is needed.  OOn April 30, 2023, the ICANN Board resolved to make the rules on these types of assignments more transparent than it had been in the 2012 Applicant Guidebook.  The RySG doesn’t believe that  omitting an assignment clause from the Agreement  provides more clarity.  Ambiguity here could be an opportunity for gaming.

“Finally, there was considerable discussion within the BAMC regarding the fact that, in the next round of the New gTLD Program, ICANN org should consider whether to provide more guidance, in the Applicant Guidebook or otherwise, regarding . . . [Assignment Agreements], including whether those agreements should be disclosed and, if so, when, as well as what communications are and are not permissible leading up to an ICANN auction. The BAMC believes, and the Board agrees, that it is important for both the applicants and the application process as a whole that ICANN provide greater clarity in the next iteration of the Guidebook and auction rules regarding the transparency and notification requirements applicable throughout the various stages of the application and auction processes.” [emphasis added]