Suggested Clarification(s)

It would be helpful for Section 1 of the RSP Handbook to state explicitly that a Registry Operator can serve as its own RSP, as well as a statement that the Registry Operator does not have to be an RSP to apply for a new gTLD. ICANN refers to the allocation of a TLD as a “critical Internet technology”. We recommend the use of the word “essential” as a replacement for “critical”, or any word except “critical” that may be more acceptable.

Suggested Clarification(s)

The section of the draft RSP Handbook on Eligibility would benefit from the following clarifications: - What constitutes a “breach” in this context and what entity determines a breach has occurred; - Whether “shareholders” refers to internal shareholders, external shareholders, or both, especially as this pertains to publicly traded companies; - How a “major shareholder” is defined. Additionally, where the draft Handbook says, “ICANN org may take into account information received from any source if it is relevant to the criteria in this section,” we believe that ICANN should not accept anonymously submitted material in order to ensure that the RSP evaluation process is transparent. We also believe ICANN org MUST (not “may”) contact an applicant if questions arise based on the information received during the background screening process. ICANN should publish the list of eligible panellists (third-party evaluators) and what makes them eligible to serve. Finally, in regards to potential conflicts of interest for evaluators, RSP applicants should be informed about who the evaluators are in order to raise concerns about potential conflicts.

Suggested Clarification(s)

Additional clarity about whether and how the RSP evaluation process impacts the new gTLD application fee would be useful. If an applicant uses an RSP that has already passed technical evaluation, it stands to reason that the cost of processing that application would be less than the cost to process an application where the RSP has not previously been evaluated. Similarly, clarity regarding the fee structure for RSP pre-evaluation when an RSP opts to be pre-evaluated for multiple types of registry services (Main RSP, DNS RPS, DNSSEC RSP, etc.) would be useful. It would also be useful to understand how the amount of the fee for each type of application maps to the costs associated with evaluating each type of application. The proposed structure should accommodate RSPs that may mix-and-match different registry services for different new gTLD applicants. In addition to the impact of the pre-evaluation fee on the application process, ICANN should state explicitly the impact of the results of the RSP evaluation process on the application process. For example, if a point-based system is used in the application process, what points are possible from the RSP evaluation process. The sentence "Each SLT is expressed as a range of calendar days, excluding ICANN office closures" appears to be ambiguous. Does ICANN consider itself closed on weekends and holidays? If holidays are excluded, which holidays? It would be helpful to define more precisely what is meant by "ICANN office closures". The draft document acknowledges that no challenge or appeal mechanism has been defined at this time. We look forward to the opportunity to review the proposal before it is finalized. Finally, it would be helpful to have clarity on exactly what will or won’t be published. Although some technical questions indicate they will not have their responses published, Applicants should have the ability to mark elements of the application confidential and expect that request to be honored. If there are limitations to what can be declared confidential this should be stated clearly. This is especially important with regard to responses to the technical questions as this may expose proprietary or security related elements of an RSP operation.

Other Topics or Areas of Knowledge

Editorial comment: Question MAIN.1.15 refers to MANRS as an Internet Society initiative. While it originated there it is currently a joint partnership between the Internet Society and the Global Cyber Alliance. This is a common sub-question and thus this comment applies in all such sections (and is not repeated in this public comment). Section Main.5. does not include RFC5732, a standard component of EPP.

Other Topics or Areas of Knowledge

Question DNS1.6 asks if the RSP does or will routinely renew all cryptographic material. However, in the context of DNSSEC, some operators do not routinely renew DNS key signing keys, but the Zone signing keys are routinely rolled over. This question should be rephrased to account for these practices. A common sub-question appears at DNSSEC.1.6. Question DNS1.13 about DDOS solutions is incredibly broad. We suggest making this question more specific in order to obtain more useful and relevant responses from RSPs. As a more general comment, many of these technical questions raise concerns about sharing sensitive information and details about proprietary technologies and systems. Especially insofar as RSP responses will be made public, ICANN should consider revising certain questions where an applicant may be exposed to security risks by sharing their architectures and practices.

Other Topics or Areas of Knowledge

Question DNSSEC.1.6 asks if the RSP does or will routinely renew all cryptographic material. However, in the context of DNSSEC, some operators do not routinely renew DNS key signing keys, but the Zone signing keys are routinely rolled over. This question should be rephrased to account for these practices. A common sub-question appears at DNS.1.6. Question DNSSEC.3.9 asks if the RSP does or will use HSMs certified to at least FIPS 140-3. FIPS does not rank requirements in the way the question implies, and in fact, FIPS 140-3 replaced 140-2 and made it obsolete. This question should be refined and made more specific.

Other Topics or Areas of Knowledge

We have some questions about how Proxy RSPs are defined in the draft Handbook. In section 1.3, the draft Handbook states that “Some ROs may perform registration validation to comply with applicable local law in a given jurisdiction, which is an optional Registry Service required to be approved by ICANN.” However, the questions in the Proxy RSP section repeat the same questions as the Main RSP section. Can ICANN please clarify how registration validation would or would not factor into the evaluation of Proxy RSPs and what implications that may have for existing Registry Operators who work with proxy providers?

Other Topics or Areas of Knowledge

Question IDN.3.4 refers to Implementation Guidance 26.6 in the Final Report of the Subsequent Procedures Policy Development Process. However, that guidance is regarding root zone operators' ability to maintain a larger root zone, which does not seem applicable to this question at all. Even if we assume that the reference should have been 25.6 (Topic 25 is about IDNs) the question is still confusing because that recommendation refers to enforcing the "same entity principle" at the second level. Please clarify the reference that is intended to enhance understanding the question. Setting aside the reference, Section 4.1.2 refers to the use of a "pre-approved catalog" of script/language pairs. The document seems to suggest that only ICANN approved script/language pairs will be included in the catalog. Please clarify two things. First, will a registry operator using an approved script/language table (according to IDN Services) for an existing TLD be eligible to be evaluated with their existing table when applying for a Variant TLD? Second, will an RSP that is supporting the use of an approved script/language table (according to IDN Services) be eligible to be evaluated under this program with their existing table? Please provide additional clarity about which tables are eligible to be used, and the impact on eligibility for this program as appropriate.

Clarifications

The statement in item 4.1.12, “IDNs offered at the second level will not have variant management” should be clarified. Does this mean that variants of second-level strings recorded in the zone will not be available for registration, i.e., they must continue to be blocked as they are now?