Comment

1.

While introducing the functions of an RSP, one can find very short explanations of these roles in Section 1.3. Although one can expect that an RSP applicant may know in detail what these concepts are, it is nonetheless very useful to provide links to ICANN-related materials about certain keywords and concepts to help readers understand better what is being described (such as, for example, DNSSEC). While we know that this readability may not apply to every document produced within ICANN, handbooks should take special care with readability.  As we and others discussed in our comments to the ASP Handbook, we all are working hard to attract a much wider group to the New gTLD Program and, thus, need to reach out a little more to help them.  We recommend Wikipedia as a good practice standard for writing a text in a reader-friendly format.

2.

In accordance with the statement in section 2.1 that says, 

"RSPs that have not sought evaluation during the pre-evaluation period must be evaluated during the gTLD application period. The evaluation criteria and testing will be the same as that which occurs during the RSP pre-evaluation period." 

The term "pre-evaluation" may introduce ambiguity, as it suggests a phase preceding the actual evaluation, while in this context, it is meant to denote an earlier evaluation. The NCSG recommends substituting this term with "early evaluation" or other suitable alternatives to enhance clarity and remove potential misunderstanding regarding this process. 

3.

In Chapter 3.1 - Eligibility, the NCSG has identified significant concerns warranting clarification. 

Our first pivotal question pertains to whether this section describes eligibility solely for applying or for being ultimately chosen as an RSP. If the intention is to specify eligibility for application submission, which seems to be the case when looking at the rest of the draft, it is nonetheless valuable to articulate this explicitly to prevent any confusion. 

Conversely, if the criteria are intended to determine eligibility for selection as an RSP, they may not be sufficiently comprehensive. Notably, there is an absence of stipulated requirements regarding technical knowledge or experience as eligibility criteria within this section, despite other segments of the application underscoring the necessity for comprehensive technical expertise in managing a successful RSP entity. Emphasizing this aspect within the eligibility section of this document is crucial to ensure transparency and alignment with the overall application requirements. 

A second important question is about the background screening. We fully comprehend that it is important to keep the concept here open-ended to encompass as many situations as possible in which an entity might not be suitable to do business with ICANN, especially in a process whose focus is precisely accreditation. However, in the way it is written and considering the reference to the 2012 Applicant Guidebook, there is a lot of space for significant discretion. 

Will ICANN take into account sanctions that are clearly a political reprisal, as we see happening with technology companies in countries with an authoritarian bias (one should note that these punishments are not rarely encompassed by two of the concepts of the 2012 Guidebook)? 

What types of "deceptive business practices" will be considered to exclude an entity (antitrust violations are included, for example)? 

In any case, we await ICANN's new consultation when these criteria are defined, since they are still pending in the draft document and this is something crucial to scrutinize.

In chapters 3.2 (Required Documents), clarification about the English translations would be welcome. In some countries, largely due to market reserve practices, it is a common request (not only in public but also in private processes) to require translations to be sworn/certified, which are substantially more expensive. Pointing out that this is not the case for the RSP application may prevent a few applicants  a much larger expense as they hire non-certified translators or do the translations through the entity’s employees, if they have the expertise for it.

4.

One should note that the flowchart at the beginning of Chapter 4.1 may lead to some confusion since the “Payment -> Background Screening” part is presented in a way that seems it be an alternative for the applications of the different services. If this was intentional, some clarification on this point would be fruitful. In a side (and minor) remark, there are also some typos when spelling “application” that should be corrected.

As outlined in Chapter 4.1.5, 

“Organizations are not required to have an operational RSP at this stage of the evaluation. It will be necessary, however, for an organization to demonstrate a clear understanding of the key technical and operational aspects of an RSP and that it has accomplished some of the groundwork involved”. 

This raises the pertinent question regarding the specific stage at which concrete evidence of a fully established RSP will be necessitated. Clarity on this matter is essential, particularly concerning the timing for achieving a functional setup, which ideally should be before commencing the Registry System Testing phase. Defining this timeline will provide applicants with a clear roadmap and ensure the timely development and readiness of their RSP infrastructure.

Further, according to 4.1.5, 

“RSP Applicants are required to pay all requested fees within 45 calendar days after they receive payment instructions from ICANN org. RSP Applicants will be notified upon receipt of payment by ICANN org”. 

Acknowledging potential challenges associated with payment processing, particularly in regions where delays are commonplace, we advocate for the inclusion of a provision to accommodate applicants encountering such circumstances. This proposed compromise entails permitting applicants facing potential delays in fee transfer to provide compelling evidence of payment initiation from their financial institution, thereby ensuring equitable treatment and mitigating any adverse impact stemming from unforeseen payment processing delays.

5.

Although this is a secondary remark, mainly for aesthetical reasons, we suggest not repeating the phrase “This fee will be payable to ICANN only via bank wire transfer” in Chapter 5.1, since the general rule about it is already established in Chapter 5.3

6.

NCSG would recommend stronger wording in Chapter 6.4 when mentioning that contacting “ICANN staff members, Board members, or individuals engaged by ICANN” “in order to lobby for a particular outcome” is “not appropriate”. This is an understatement, considering that contacting these players for this specific purpose is at least illegitimate behavior, and should be addressed as such.

Conclusion

In conclusion, the NCSG expresses its sincere gratitude for the chance to provide feedback and guidance on important ICANN policy matters as such. Our comments are mainly aimed at making the text easier to understand and addressing potential ambiguities that may confuse readers, especially those who are not used to ICANN's procedures and this particular technical language.

We therefore extend our thanks to the team who drafted this very well-written Handbook and to ICANN Staff for their diligent consideration of our remarks and look forward to our concerns being addressed.