Public Comment

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.

Contenido disponible solo en los siguientes idiomas

  • English

Name: Registries Stakeholder Group (RySG)
Date:21 Apr 2024
1. Does the RSP Evaluation Program, as described in the draft RSP Handbook, meet the intent of the policy recommendations of Topic 6: Registry Service Provider Pre-Evaluation of the SubPro PDP Final Report
Yes, but with the following suggested clarification(s)

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.

2. Does the draft RSP Handbook describe the requirements and expectations placed upon an RSP applicant such that an RSP applicant can reasonably determine its ability to successfully pass RSP evaluation? If not, please specify the additional information an RSP applicant would need to reasonably determine their ability to pass RSP evaluation
Yes, but with the following suggested clarification(s)

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.

3. Does the RSP Evaluation Program, as described in the draft RSP Handbook, contain processes and procedures that will allow RSP applicants to successfully apply and pass evaluation in a timeframe compatible with the needs of RSP applicants and their potential gTLD clients. If not, please specify what modifications to the RSP evaluation process would be needed to better accommodate these timeframes.
Yes, but with the following suggested clarification(s)

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.

4. Do the technical questions regarding the application for a Main RSP in Appendix A of the draft RSP Handbook cover all areas of knowledge necessary for ICANN org and its third-party evaluators to assess the applicant’s ability to operate a Main RSP in a manner sufficient to insure the security and stability of the DNS? If not, please specify which topics or areas of knowledge should be added.

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.

5. Do the technical questions regarding the application for a DNS RSP in Appendix A of the draft RSP Handbook cover all areas of knowledge necessary for ICANN org and its third-party evaluators to assess the applicant’s ability to operate a DNS RSP in a manner sufficient to insure the security and stability of the DNS? If not, please specify which topics or areas of knowledge should be added.
No; there are other topics or areas of knowledge that ICANN org should assess

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.

6. Do the technical questions regarding the application for a DNSSEC RSP in Appendix A of the draft RSP Handbook cover all areas of knowledge necessary for ICANN org and its third-party evaluators to assess the applicant’s ability to operate a DNSSEC RSP in a manner sufficient to insure the security and stability of the DNS? If not, please specify which topics or areas of knowledge that should be added.
No; there are other topics or areas of knowledge that ICANN org should assess

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.

7. Do the technical questions regarding the application for a Proxy RSP in Appendix A of the draft RSP Handbook cover all areas of knowledge necessary for ICANN org and its third-party evaluators to assess the applicant’s ability to operate a Proxy RSP in a manner sufficient to insure the security and stability of the DNS? If not, please specify which topics or areas of knowledge that should be added.
No; there are other topics or areas of knowledge that ICANN org should assess

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?

8. Do the technical questions regarding the application for an IDN service in Appendix B of the draft RSP Handbook cover all areas of knowledge necessary for ICANN org to assess the applicant’s ability to operate a Main RSP with an IDN service in a manner sufficient to insure the security and stability of the DNS? If not, please specify which topics or areas of knowledge should be added.
No; there are other topics or areas of knowledge that ICANN org should assess

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.

14. Are the technical questions regarding the application for an IDN Service in Appendix B of the draft RSP Handbook clear and understandable? If not, please specify the questions that need more clarity and how they could be made more understandable.
No; some clarifications are needed

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?