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:29 Apr 2022
Original Public Comment: Root Zone Update Process Study
Other Comments

The Registries Stakeholder Group (RySG) thanks JAS and IANA for the comprehensive study of the Root Zone Update Process and well-considered report. The analysis and report are further assurance that ICANN understands the critical importance of a stable, secure IANA root zone management operation to the stable, secure operation of the global DNS. As a customer of IANA, the RySG understands and appreciates the day-to-day challenge that the IANA organization faces to maintain 100% integrity and security of root zone updates.

Overall, we find general agreement with the set of recommendations. While we don’t disagree with the recommendations we do want to note that not all of them may be necessary and some could have some unintended consequences. In the remainder of this note, we outline those additional points for consideration and suggestions related to Recommendation II optionality and the possible unintended consequences of implementing certain recommendations.

Recommendation II Optionality

We would like to note that while we generally agree with Recommendation II (“do not recommend implementation of a traditional multifactor authentication for the RZM currently”), we would rather have seen this recommendation encourage IANA to develop technology to allow its users to opt-in to multifactor authentication as a “may offer the option for” rather than “not recommend implementation” (of multifactor authentication).

While multiple registry operators provided feedback to JAS in support of multifactor authentication, we found the report’s rationale that the RZM not require multifactor authentication to be compelling, especially the elements related to “trust reboot” and infrequent interaction. While not entirely the same situation as that faced by IANA, several RySG members face similar issues as Back End Registry Operators, in both gTLD and ccTLD contexts, and are familiar with the challenges of operating multifactor authentication in this context.  

We note that there could be room in the interpretation of the II.a text to allow for optionality. That is, if the term “traditional multifactor authentication” is taken to mean “requires multifactor authentication”; while a “non-traditional multifactor authentication” could be interpreted as being “optional”. We understand that this could mean that certain IANA customers could be using multifactor authentication while others are not. But this also would allow IANA’s customers to comply with their own security standards, which may require the use of multifactor authentication.


Possible Unintended Consequences

We remain supportive of the recommendations and while the report includes the benefits related to the various Recommendations, we would like to highlight some other factors for consideration when IANA is determining which Recommendations to implement and how. Specifically, the possible implementation path for Recommendations I.a, V, and VII.a could have the following unintended consequences:

I.a indicates that IANA should “consider rotating SOC2 auditors”. From experience, registry operators know that changing auditors can be a disruptive and time-consuming process with limited benefit. We did not find documented support for the stated rationale (p. 30) that it is “good practice” which centers on a “fresh set of eyes”. While we support the current public RFP process for the SOC2 auditor contract, we would be hesitant to penalize the current vendor in a forthcoming RFP process.

V indicates that IANA should “increase the geographic diversity of its staff to other regions of the United States.” While we understand the stated rationale for geographic diversity (risks related to infrastructure interruptions), we note that the report fails to fully account for both the costs and benefits of geographical diversity. For example, a distributed staff will require funding for periodic travel for team meetings. Further, during the peak of the COVID-19 pandemic when air travel was extremely difficult, certain DNSSEC key ceremonies were largely possible due to the geographic proximity of IANA staff. This was not included in the report.

Vii.a indicates that ICANN should “offer translated documents that describe IANA policies and services”. While we support accessibility, we note that a legal translation of a policy document is a challenging process and note that to avoid any confusion there should be one version that “controls”. Therefore, if IANA chooses to implement this recommendation we suggest clarity around the controlling version. 



Overall, we welcome the report and appreciate its thoroughness and care. The IANA stewardship transition of 2016 has been successful in significant part because commitments to close oversight, attention to customer needs, and continual improvement are being kept. The RySG appreciates this opportunity to offer its support and review of the report and looks forward to continued collaboration on these issues. 

Summary of Submission

The RySG welcomes the report and appreciates its thoroughness and care. We find general agreement with the set of recommendations. While we don’t disagree with the recommendations we do want to note that not all of them may be necessary and some could have some unintended consequences.