Dear RIPE community and colleagues,

 

Thank you for the opportunity to provide feedback on the “Governance Document for the Recognition, Maintenance, and Derecognition of RIRs” (Draft of 14 April 2025). Having spoken with many members of the global Internet community, this e-mail attempts to capture the collective feedback discussed. We appreciate the considerable work that has gone into updating ICP-2 to address the full lifecycle of Regional Internet Registries (RIRs). In this email, we focus exclusively on the draft’s content – offering draft-specific feedback on clarity, requirements, and provisions – without delving into implementation details. Our comments center on whether the new requirements are clear, whether the ongoing obligations and remediation processes are sufficiently defined, and how the draft might be strengthened to ensure continuity and accountability. We also highlight certain structural concerns and suggest improvements, all in the spirit of constructively refining the document. Finally, we conclude with our general support for this important process.


TL;DR – Executive Summary & Key Take-Aways (for those with limited time)

The remainder of this e-mail addresses the specific detail recommended and should be considered in its entirety.  

 

Clarity of New Requirements and Ongoing Obligations

 

The draft commendably introduces a comprehensive set of new requirements and obligations for RIRs, moving beyond the original ICP-2’s focus on initial recognition. Principles such as Member-Controlled governance, Community-Driven policy development, Transparency, Audit, Service quality, Continuity, Anti-Capture, Ecosystem Stability, and Handoff of responsibilities are clearly enumerated in the text. These additions appropriately reflect modern expectations for good governance and accountability. We find the inclusion of these criteria to be a positive step that provides clearer definitions and more detailed guidance on RIR responsibilities than the legacy ICP-2 framework offered.

 

However, we recommend providing additional clarity or detail for certain requirements to ensure consistent understanding and application across all RIRs. For example:



 

Overall, the ongoing obligations introduced in the draft cover the right areas, but a bit more precision in language would help ensure sufficiency and consistency. Clear criteria and defined processes will reduce ambiguity when these obligations eventually need to be enforced or evaluated. We urge the authors to review each new requirement through the lens of “could different readers interpret this differently?” and, where needed, tighten the wording or add examples to prevent misinterpretation. The goal should be that RIR communities, boards, and even external observers all have a common understanding of the standards RIRs must uphold.

 

Continuity and the Need for an Emergency Back-End Registry Operator (EBERO) Model

 

We applaud the draft’s focus on continuity of services and its recognition that RIRs must plan for scenarios where another entity might need to temporarily or permanently assume their functions. In particular, Principle 20 (“Continuity”) affirms that “An RIR must maintain continuity procedures and redundancies and participate in record sharing that would enable another RIR to perform its RIR services, if necessary.” Additionally, Section 5.3(a) on the Effect of Derecognition mandates that a departing RIR “ensure the smooth transfer of its services and operations, as directed by ICANN, to a successor or interim entity.” These are crucial provisions to guarantee that the Internet Number Registry System remains stable even if an RIR faces failure or crisis.

To further strengthen this commitment, we recommend that Section 4.1(l) and Article 5 be expanded to explicitly incorporate an Emergency Back-End Registry Operator (EBERO) framework tailored for the numbering community—a Numbering-EBERO—patterned on ICANN’s proven gTLD model. The EBERO model, as deployed in the DNS space, ensures continuity by designating trusted operators to maintain registry services in the event of a registry failure. Applying this concept to the RIR system would offer a clear, operationally feasible pathway for ensuring uninterrupted allocation, registration, and RPKI publication services.

Specifically, the draft should:

These enhancements ensure routing security remains intact and eliminate the unrealistic burden that a peer RIR must instantly assume another’s full registry and RPKI operations—an expectation that is operationally intensive and introduces unnecessary fiduciary and legal risk.

While the draft implicitly allows for such fallback arrangements under its “record sharing” continuity principle, making this contingency explicit would materially increase clarity, resilience, and stakeholder confidence. A concrete addition such as: “RIRs and ICANN shall develop and maintain a Numbering-EBERO framework—modeled after ICANN’s EBERO program for gTLDs—to be activated in the event that an RIR is unable to provide services, ensuring uninterrupted operation of the Internet Number Registry System” would create strong alignment with well-understood DNS sector practices. A model the world has used for nearly 27 years. 

Such a model should include the following key elements:

This approach echoes the robust planning developed during the IANA stewardship transition and extends those best practices to the numbering system. Including these mechanisms within the formal policy framework signals that the RIR community takes continuity with the same level of rigor as the DNS community—reassuring governments, network operators, and stakeholders that the Internet’s addressing infrastructure has credible, tested fallback arrangements in place.

In summary, we strongly support the inclusion of continuity provisions and recommend explicitly incorporating a Numbering-EBERO mechanism. This would codify operational readiness, reduce ambiguity in crisis scenarios, and affirm the community’s collective commitment to uninterrupted delivery of critical Internet number services.

 

Structural Weaknesses: NRO’s Legal Status and Reliance on Reputation

 

From a structural perspective, one area of concern is the reliance on the NRO (Number Resource Organization) as the coordinating body in this framework despite the NRO’s lack of distinct legal personality. By design, the NRO is an unincorporated association of the five RIRs – essentially a lightweight vehicle for collective action established by an MoU in 2003. It is not a separate legal entity empowered to enter into contracts or enforce decisions on its own. Any substantial obligation the NRO undertakes requires the explicit agreement and signatures of all five RIRs. This structure has served the community well for coordination purposes, but it does pose some weaknesses in governance enforcement which the draft document should acknowledge or seek to mitigate: 



 

In light of the above, we believe the draft should at least acknowledge these structural limitations and wherever possible, build in safeguards or alternatives. For instance, could the document provide that if the RIRs themselves are unable to reach unanimity in a serious situation, there is an option for a broader community or third-party mediation to be invoked? (We note that the ASO MoU already has an arbitration clause for certain disputes, which might cover some of these scenarios, though it’s not clear if that would apply to disagreements over this new governance document.)

 

Furthermore, the lack of a legal entity for the NRO might be revisited in the future. While it may be beyond the scope of this current policy document to change that, the community could consider whether incorporating the NRO (as a lightweight legal entity) might provide a better vehicle to hold any shared assets (like escrowed data for continuity) or to sign contracts on behalf of all RIRs. Short of that, strengthening the contractual ties between each RIR and ICANN (discussed next) can help compensate for the NRO’s limited enforcement power by introducing external accountability.

 

Toward a Direct Legal Framework with ICANN

 

To address some of the structural and enforcement concerns, we suggest the community explore establishing a direct legal framework between each RIR and ICANN, analogous to the contractual models seen in the DNS sphere (such as the Registry Agreements for gTLDs and the Registrar Accreditation Agreements). Under the current ecosystem, the RIRs’ formal relationship with ICANN is primarily governed by the ASO MoU and the IANA Numbering Services SLA. These agreements cover policy coordination and the performance of the central (IANA) functions, but they do not explicitly codify the ongoing governance obligations of RIRs themselves beyond those contexts. The new RIR Governance Document, once finalized, could be elevated from a mere policy to part of a contractual framework: for example, each RIR could sign a “Recognition Agreement” with ICANN that incorporates the commitments of the governance document, much as each gTLD registry operator signs an agreement to abide by ICANN policies and meet certain performance standards. This bilateral agreement should incorporate audit rights, breach-and-cure timelines, and continuity (EBERO + RPKI) obligations. Additionally the policy should state unambiguously that ASO, NRO, and every RIR owe accountability to the global Internet community; ICANN may act contractually only after bottom-up community approval.

 

Why would this help? Because a contract provides a direct line of accountability and enforcement. If an RIR materially breaches its obligations, ICANN would have recourse through the contract – potentially including remediation requirements, arbitration, or as a last resort termination of the agreement (which in effect corresponds to derecognition). This mirrors how ICANN is able to ensure compliance in the gTLD space: for example, ICANN’s contracts with registries and registrars include audit rights, breach notices with cure periods, and ultimately the ability to revoke the contract  if issues are not resolved. While RIRs are of course quite different from commercial registries, the principle of having a clear, enforceable two-way contract is applicable. It sets out mutual obligations: the RIR agrees to uphold the criteria and responsibilities (governance, policy processes, service levels, etc.), and ICANN agrees to continue delegating the registry function to that RIR and support it (for instance, via the IANA services and recognition in global forums). If either side fails in their duties, the contract defines what happens next.

 

Notably, the Number Community’s proposal during the IANA Stewardship Transition envisioned exactly this type of contractual assurance for the performance of the IANA numbering functions – which was achieved via the SLA between RIRs and ICANN . That SLA ensures ICANN (via PTI) performs the global allocation and registry maintenance to certain standards, with remedies if it does not. Similarly, a recognition contract would ensure each RIR performs its regional registry functions to agreed standards. It would bring much-needed clarity: today, if an RIR seriously mis-governed itself, the community’s only path is the multi-step, multi-party process in this draft. With a contract, there is an additional layer – ICANN could issue a notice of breach, the RIR would have time to cure (aligning with the draft’s rehabilitation focus), and if that failed, ICANN could invoke contractual remedies supported by the community. Crucially, this doesn’t mean giving ICANN unchecked power over RIRs; the contract terms would be community-developed and mutually agreed, and could even specify that ICANN must act only on community request (similar to how this draft requires RIR approval first). But it does create a legal obligation that can be enforced in a court or via arbitration if necessary, rather than relying purely on collegial goodwill.

 

Another benefit is removing ambiguity about obligations. A contract could spell out certain operational requirements (such as data escrow, continuity plans, and compliance reports) in more detail than a high-level policy document can. It can reference the policy (the governance document) for the broad strokes, but also include specific deliverables or metrics in appendices or via incorporated Service Level Requirements. For instance, just as ICANN’s Registry Agreements require registries to maintain emergency procedures and cooperate with EBERO providers, an RIR recognition agreement might require RIRs to maintain updated continuity plans and cooperate in any joint continuity scheme. Backing these expectations with contractual weight ensures no party can later claim the requirements were merely aspirational.

 

We understand that introducing new formal agreements is a significant step, and some in the community may worry about increased ICANN authority. However, we believe it can be done in a balanced way that retains community primacy. The contract model can explicitly preserve the bottom-up nature (for example, it can state that ICANN will not exercise any termination or replacement of an RIR without evidence of community approval per the governance document’s process). Its main function is to add a safety net: if, say, an RIR’s leadership became so dysfunctional that it ignored both its community and its peers, the existence of a contract would give the wider community (through ICANN) a firmer lever to protect the public interest. It turns what might be a reputational standoff into a situation with legal recourse.

 

In summary, we recommend considering a hybrid governance model where this updated ICP-2 document is not only a policy but also forms the basis of bilateral RIR-ICANN agreements. This approach draws on successful elements of the DNS regime’s contracts to resolve ambiguity and enforce mutual obligations. It would complement the excellent work done in the draft by providing an enforcement mechanism that is currently missing due to NRO’s non-corporate nature. We believe this would ultimately strengthen the resiliency of the RIR system, as all parties (RIRs, ICANN, and the community) would have clearer expectations and remedies if things go wrong.

 

Alignment with IANA Stewardship Transition Commitments

 

It is important that the final governance framework for RIRs remains consistent with the commitments made during the 2014–2016 IANA Stewardship Transition, particularly regarding accountability and continuity. During that transition, the Number Resource Community emphasized maintaining the stability, security, and resiliency of Internet number administration throughout and beyond the end of the NTIA’s oversight. The proposals developed (notably the CRISP proposal for numbers) assured the global community that the decentralised RIR system would continue to be reliable and that robust agreements and oversight mechanisms would replace the historical U.S. government contract. Indeed, the community put in place the SLA with ICANN and established the IANA Numbering Services Review Committee to monitor ICANN’s performance – measures which have worked well.

 

Now, in this RIR governance document, we have the opportunity to reinforce and extend those transition commitments to the RIRs’ own operations. Several points of alignment should be checked: 



 

In essence, our feedback here is to double-check that everything we assured stakeholders in 2016 is carried forward: continuity of services, robust oversight mechanisms, community empowerment, and clarity in responsibilities. If any gaps are identified when holding the draft against those commitments, those gaps should be filled before finalizing the document. This will not only make the RIR governance stronger but also uphold the credibility we earned during the transition process by delivering on our word.

 

Specific Provisions Needing Improvement or Clarification

 

Below we list several specific provisions or aspects of the draft that have been identified (by ourselves and others in prior feedback rounds) as problematic or in need of refinement. We recommend the drafting team address these in the next version: 



 

The above list covers the key issues previously noted by various community members and observers, as well as some new suggestions based on our analysis. Addressing these will, in our view, significantly improve the next draft. We recognize that some items (like altering unanimity or introducing ICANN failsafes) may be contentious – but it’s important to discuss them openly now, to ensure the final policy is as robust and broadly acceptable as possible.

 

Conclusion

 

In conclusion, we reiterate our strong support for the process and the overall direction of this governance document. The challenges faced in recent years (e.g., AFRINIC’s crisis) underscored the need for a modernized framework – one that ensures continuity, accountability, and stability in the Internet Numbers Registry System across all regions. This draft is a major step toward that goal, transforming ICP-2 from a simple set of start-up criteria into a full lifecycle governance policy. We commend the NRO NC and all contributors for tackling this complex task.

 

Our feedback aims to be constructive and aligned with the multi-stakeholder, bottom-up ethos of our community. We believe that by clarifying the requirements, shoring up the continuity provisions (with explicit EBERO-style backups), addressing structural enforcement gaps, and drawing on best practices from the DNS sector, we can make the RIR system even more resilient. The DNS community’s experience has shown that having well-defined contracts and contingency mechanisms greatly contributes to stability and confidence – the numbering community should strive for the same level of rigor and preparedness. Ultimately, both names and numbers are critical pillars of the Internet’s infrastructure, and our stakeholders deserve assurance that both are in good hands with strong safeguards.

 

Please view our suggestions in that light: not as criticisms of the draft, but as refinements to ensure nothing is overlooked that could one day threaten continuity or trust. We appreciate the careful balance the draft strikes in preserving the RIRs’ autonomy and the community’s authority. Our recommendations seek to preserve that balance while adding clarity and legal robustness where needed.

 

We are encouraged by the collaborative approach so far – including regional consultations and the ICANN public comment process – and we remain optimistic that the final document will reflect the community’s collective wisdom. Thank you for considering our input. We look forward to continued dialogue and are confident that, working together, we will finalize an RIR Governance Document that upholds the stability, continuity, and responsible governance of Internet number resources for decades to come, much as similar measures in the DNS world have done for domain names for the past 27 years.

 

Sincerely,

 

William Sylvester

William has been a member of the global Internet community for nearly 30 years.  He has actively contributed to RIR policy development, chaired working groups, support committees, and served as Chair of the RIPE Community Accountability Task Force after the IANA Stewardship Transition.  William began his career at the InterNIC, helped launch ARIN in 1997, assisted in establishing the DNS Registry System in 1998, and was a member of the Whitehouse sponsored President’s Committee on Internet and Security in the early 2000s.