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) * We Support the draft: Updating ICP-2 into a full life-cycle governance policy is the right move and broadly welcomed. * Continuity first: Add an ICANN’s gTLD framework inspired Emergency Back-End Registry Operator (EBERO) that can run both registry and backup RPKI services; require escrow of allocation data & RPKI keys for rapid fail-over from a third-party. * Sharpen obligations: * Define “financially stable & independent” with measurable indicators. * Mandate annual financial + triennial governance audits. * Spell out rehabilitation steps and timelines. * Legal backbone: Convert the policy into bilateral Recognition Agreements (RIR ↔ ICANN) to give teeth to audits, continuity duties, and to enshrine ASO/NRO/RIR accountability to the global community. * Decision-making tweaks: * Revisit unanimity—use super-majority or preferably clear mediation path to avoid deadlock. * Lower the 25 % local-member threshold for derecognition proposals to something workable. * Provide an ICANN “failsafe” trigger for extreme cases where RIRs can’t act. * Structural gaps: Acknowledge the NRO’s non-incorporated status and antitrust optics; peer-to-peer RIR takeover is a fiduciary risk—EBERO is safer. * Keep transition promises: Ensure continuity, bottom-up authority, and transparency remain on par with 2016 IANA stewardship commitments. 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: * Financial Stability and Independence: The draft requires an RIR to be “financially stable and independent”, but it could be useful to clarify how this is measured or demonstrated. Providing guidance (even non-normative) on indicators of financial stability (such as reserve levels, diversified funding sources, or audit outcomes) would help RIR communities consistently interpret this obligation. Likewise, “independence” might be clarified to ensure it covers independence from undue single-party influence (be it government or private interests) in line with the anti-capture principle. * Regular External Audits: The draft’s Audit requirement states that RIRs “must participate in regular audits by an external and independent auditor to ensure continuing compliance with ICP-2” . This is an excellent addition for accountability. We suggest clarifying what “regular” means in practice – e.g. annual financial audits and periodic (biennial or triennial) governance compliance audits – so that each RIR conducts such reviews on a comparable schedule. Defining the expected scope of these audits (financial, procedural, policy compliance, etc.) would also bolster clarity. This will ensure the ongoing obligation is uniformly understood and that any RIR’s community can readily verify that audits are being conducted as intended. * Continuity Procedures: The requirement for continuity (discussed more fully below) is described in fairly broad terms. While it appropriately avoids prescribing detailed implementation, a bit more specificity could improve clarity. For instance, it could explicitly mention maintaining up-to-date data escrow or backup of registry records and agreements with other RIRs or preferably a trusted neutral 3rd party for emergency operations, since these are concrete steps that enable another entity to take over services if necessary. This would align the obligation with best practices for continuity planning. * Remediation Process Clarity: The draft establishes a much-needed remediation process (Rehabilitation) whereby aiding a non-compliant RIR is the preferred first response, with derecognition as a last resort  . We fully support this approach. To enhance clarity, the document could outline the steps of remediation in a bit more detail – for example: after an issue is identified, a formal notice to the RIR in question, a timeline for the RIR to formulate a remediation plan, periodic progress check-ins, and how/when the assisting parties (other RIRs/ICANN) will determine if the issue has been resolved or further action is needed. Including such procedural outlines (even if high-level) would make the obligations and expectations during Rehabilitation more explicit. It would also assure stakeholders that there is a predictable path from identifying a problem to either its resolution or, if absolutely needed, derecognition. 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: * Require escrow of all essential data and cryptographic material needed to restart services, including delegated RPKI keys, ROAs, and manifest/CRL data. * Mandate that the EBERO be capable of operating allocation, registration, and RPKI publication during a prolonged outage or systemic failure affecting an RIR. * Clarify that EBERO activation is community-triggered and time-bound, returning control to the original RIR once it is rehabilitated or formally replaced by a successor organization. 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: * Systematic escrow of registry and routing data in neutral repositories accessible to ICANN or authorized continuity operators. * Identification and designation of standby operator(s) (other RIRs or trusted third parties) with the technical and legal capacity to operate an IP address registry on short notice. * Clearly defined triggers and handover processes to ensure openness, transparency, accountability, and restoration of original authority when feasible. 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: * Enforcement of Obligations: The new governance document, once adopted, will effectively function like an agreement between ICANN and the RIRs (since it must be mutually approved by both). However, because the NRO is not a party with independent authority, enforcing the obligations in the document will ultimately rely on the RIRs holding each other accountable through peer pressure and mutual agreement, or on ICANN’s oversight where applicable. If an RIR were to willfully breach a requirement and refuse to remedy it, the only recourse in the draft is the derecognition process, which – as we discuss below – requires unanimous support of the other RIRs and ICANN’s approval to carry out. This high threshold might delay or even preclude necessary action. In a scenario where an RIR is non-compliant but at least one of its peers is hesitant to set a precedent by derecognizing (perhaps due to fears of instability or political considerations), the NRO framework offers no middle-ground enforcement tool. The document builds in a strong bias toward remediation (rightly so), but if remediation fails and consensus to act cannot be reached, the system could be stuck. This is a structural risk: important decisions can be vetoed by a single RIR, which could potentially enable an uncooperative RIR to persist in a state of non-compliance longer than the community or global interest would prefer. * Risk of Inter-RIR Conflict or Deadlock: The unanimity model, while ensuring that no RIR is overruled lightly, might also exacerbate conflicts if they do arise. Imagine a situation where one RIR’s interests or philosophies differ significantly from the others – that RIR might block changes or actions that the rest see as necessary (or conversely, the others might isolate one RIR). With the NRO’s current setup, there is no independent arbiter to break a stalemate; everything depends on voluntary consensus or, failing that, extreme measures. This could strain the trust and reputation-based fabric that holds the RIR system together. In the AFRINIC crisis that partly prompted this revision, we saw how disputes can escalate to court cases and community unrest. In the absence of a stronger legal framework, similar future conflicts could likewise end up in protracted litigation or simply paralysis, which benefits no one. * Antitrust and Competition Concerns: The draft’s procedures effectively have the incumbent RIRs collectively deciding on the market entry or exit of RIRs (i.e., recognition of new ones or derecognition of existing ones). While this makes sense from a coordination standpoint – since the RIRs must work together – it is not hard to imagine an external observer raising antitrust or competition questions about this arrangement. Five entities agreeing to bar a new competitor, or to carve up service regions with a strict rule of one-per-region, could be perceived as a cartel-like activity, even if done with good intentions for stability. Indeed, the requirement that all (other) RIRs unanimously concur before an RIR can be derecognized or a new one recognized means any incumbent has an effective veto over what could be seen as a competitive move. The RIRs have historically justified the single-RIR-per-region model on efficiency and stewardship grounds (to avoid fragmentation of the registry system), and that reasoning still holds. But in today’s environment, being explicit about why the governance structure is not anti-competitive might be necessary to preempt misunderstandings. One way to address this is by ensuring the governance document and related agreements articulate that these decisions are made in the global public interest of Internet number stability, not for the economic gain of the RIR organizations themselves (which are non-profit and community-driven by charter). In an effort to be pristine on these issues the draft may wish to remain silent or remove any requirements for geographic limitations on RIRs and to remove any legal entity requirements such as being a non-profit. 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: * Continuity of Operations: As discussed, one of the fundamental principles of the transition was that the global registry functions must not be disrupted. The draft’s continuity and handoff provisions are very much in the spirit of that principle. We encourage the drafters to ensure that these provisions are as strong as or stronger than the continuity mechanisms that were expected of ICANN/PTI. For example, if the IANA operator is required to have disaster recovery sites and failover plans, the RIRs should as well – and the governance document could explicitly reference that expectation. It would demonstrate that we hold ourselves to the same standard we demanded of the IANA operator when stewardship was transitioned. * Community Empowerment and Accountability: The transition was predicated on the idea that the communities (numbers, names, protocols) could self-govern responsibly in absence of government oversight, using transparent processes and accountability measures. The draft does a good job of embedding community oversight (e.g., members electing RIR leadership, bottom-up policy making, published records). One suggestion: incorporate by reference the fact that each RIR has its own accountability mechanisms (like member meetings, the ability to recall board members or equivalent, dispute resolution processes, etc.), and that these play a role in addressing issues before they escalate to the inter-RIR level. By acknowledging the RIRs’ internal accountability, the document aligns with the transition ethos that solutions should start from the ground up. It also reassures that if an RIR is failing, its own community will likely be the first to signal and attempt to correct course – with the global mechanisms kicking in if those local attempts fail. A final thought on this topic while the draft aligns with ICP-2’s cooperative ethos, expecting one RIR to absorb another’s obligations and liabilities is a poor fiduciary practice. Boards have duties to their own members and cannot assume external risk overnight. By making EBERO the primary continuity path and peer take-over strictly a last-resort, the document shields all parties from unintended financial or legal exposure while still guaranteeing uninterrupted service. * Fail-safe for Unresponsive RIRs: Under the transition, we contemplated scenarios such as an RIR that is unresponsive or unable to function, and made commitments (albeit somewhat implicit) that the remaining system would adapt to ensure continuity. For instance, the NRO stated that formal relationships were put in place to ensure responsibilities are clear and can be carried out post-transition. To fully honor that, the governance document should leave no doubt that if an RIR becomes unresponsive, the community (via the other RIRs and ICANN) can and will take action to safeguard the number registry system. The current draft’s Section 2.4 (ICANN Review) allows other RIRs to trigger an audit of a suspect RIR, which is a good tool. We might strengthen that by allowing ICANN or the community to initiate such a review in extraordinary cases even if one or two other RIRs hesitate – perhaps by requiring a majority of RIRs rather than unanimity to request an audit, or by empowering the ASO AC to flag issues to ICANN. Ensuring there is no procedural dead-end when an RIR is truly unresponsive is key to alignment with our promises of resilience. * Preservation of Bottom-Up Authority: Finally, the post-transition world is one where the communities are in charge. This document should be explicit that recognizing or derecognizing an RIR is a community-driven decision. In fact, it is – Section 2.3 requires RIR (and in derecognition cases, RIR’s own members) approval before ICANN’s Board can act. We support this approach as it respects the bottom-up, multi-stakeholder model. Our earlier suggestion of contracts with ICANN is not meant to contradict this; rather, any such contracts would be anchored in the community’s decisions. We recommend maybe adding a line in the preamble or an early section to affirm that “the authority for recognition or derecognition of an RIR originates from the global Internet Number Community, with ICANN’s role being to confirm and implement the community’s decisions”. This framing sends a clear message that we are remaining true to the principles of the IANA transition – namely, no top-down imposition, but rather community-driven governance supported by ICANN. 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: * Unanimity Requirements for RIR Decisions (Section 2.3): The draft requires unanimous agreement of all other RIRs to recognize a new RIR or to derecognize an existing one . This could inhibit timely action – e.g., a single RIR could block the derecognition of a failing peer, or potentially block a worthy new RIR from being recognized due to unrelated disagreements. We suggest revisiting whether absolute unanimity is necessary in all cases. Perhaps a supermajority (e.g., 4 out of 5) could be sufficient for certain decisions, or at least there should be a mechanism to escalate if unanimity cannot be reached despite clear evidence of a serious problem. At minimum, require the dissenting RIR to document its reasons publicly  (the draft does have each RIR publish its decision rationale), and allow further community input or mediation in response. This would add transparency and pressure to resolve any stalemate. * ICANN’s Lack of Independent Initiation Power: As written, ICANN “shall have no power to Recognize or Derecognize an RIR” absent an approved proposal from the RIRs , and ICANN “may not initiate” a recognition/derecognition proposal. We understand the intent is to prevent unilateral ICANN action, preserving community control. However, this blanket prohibition could be problematic if all RIRs are paralyzed or if an issue arises that the RIRs (for political or practical reasons) fail to address. Consider a situation where an RIR’s dysfunction is harming the global system, yet the other RIRs can’t agree on action – ICANN’s hands would be tied even if the wider community (network operators, governments, etc.) were clamoring for intervention. We recommend introducing a narrow exception or process for ICANN initiation in extraordinary circumstances: for example, ICANN could initiate a proposal only upon petition by some significant threshold of the affected RIR’s own community or other stakeholders. Another approach is allowing ICANN to call for a public consultation or review team (outside of the RIRs) to examine the situation if the RIRs cannot or will not act. This would ensure there’s a path forward in truly urgent situations, while still respecting that any final decision would go through the community-driven steps. In short, a failsafe trigger for ICANN might be prudent, given that ultimate authority still rests with the Board to sign off on a change in RIR status. * Threshold for Community Derecognition Proposal: The draft enables “not less than 25% of the Members” of an RIR to propose that RIR’s derecognition. We agree that the regional community should have this power – it’s an important accountability mechanism. The 25% threshold, however, is fairly high and might be difficult to achieve in practice (consider that some RIRs have thousands of members; 25% could be many hundreds). If an RIR is truly in crisis, rallying a quarter of the entire membership to formally sign onto a proposal could be burdensome, yet a smaller (but still substantial) portion might clearly support the move. We suggest re-evaluating this threshold. Perhaps something like 10% of members and at least 3 of the 5 RIRs concurring could be an alternative trigger formula that balances regional and global input. This would lower the bar for raising an issue to the formal level, without making it too easy to frivolously launch a derecognition procedure. If 25% is retained, it might help to justify why that number is appropriate (e.g., it signifies a significant minority and prevents factious misuse). * Clarify “Reasonable Support” in Rehabilitation (Section 5.2): We strongly endorse the language in Section 5.2 that other RIRs and ICANN will provide “all reasonable support” to help a non-compliant RIR come back into compliance . To avoid any ambiguity, it could be helpful to add examples of what “reasonable support” entails – for instance, does it include seconding staff or technical expertise, providing financial loans or guarantees, temporarily sharing infrastructure, etc.? Of course, the exact support will depend on the situation, but setting expectations that the community will mobilize assistance (and perhaps referencing the types of support seen in past incidents like the AFRINIC situation, where other RIRs offered help) would be useful. Additionally, the document could specify that the affected RIR must cooperate with such support in good faith. (It’s implied, but stating it ensures the failing RIR can’t simultaneously refuse help and avoid derecognition indefinitely.) * External Factors and Force Majeure: The community feedback prior to drafting raised the question of RIRs operating under external constraints – for example, sanctions, government interference, or even war, which might temporarily cause an RIR to violate some criteria (e.g., inability to provide services fully in parts of its region). The governance document should include a grace or exception clause for such situations. We propose adding something like: “If an RIR’s non-compliance is due primarily to factors beyond its control (such as legal prohibitions or extreme events in its service region), this shall be taken into account in remediation timelines and decisions.” In other words, don’t treat an RIR as neglectful when it is prevented from acting by external forces. The focus in those cases should be on how the global community can temporarily assist or route around the obstacle (for instance, could another RIR handle requests from a sanctioned country on an interim basis?). Incorporating this consideration will prevent inadvertent penalization of an RIR for circumstances like sanctions that are outside its power to change. It also signals to governments that the RIR system is not blind to real-world events – we have a means to maintain registry functions for everyone even under adverse conditions. * Terminology Consistency: A minor editorial note – ensure all key terms (Recognition, Derecognition, RIR, Member, etc.) are used consistently with their definitions in Article 1. For example, the draft uses “Member” to mean participants in an RIR’s governance (not necessarily limited to fee-paying members in all RIRs, since some communities allow broader participation). This should match each RIR’s reality. If there’s any discrepancy (like some RIRs define membership differently), perhaps adjust the definition or add a footnote. Also, clarify if “Members” in the 25% rule means 25% of all entities eligible to vote in that RIR’s elections – this likely is the intent, and it should be unambiguous. * Official Language (Section 2.7): The draft declares English as the official language of the Internet Numbers Registry System. While this is practical for global coordination, it did raise some community questions. We suggest maintaining this for the authoritative text, but also committing to translations of the document in all RIR regions’ major languages for informational purposes. This will improve inclusivity. We recall concerns that public feedback was limited by language barriers; providing official translations of the governance document (even if English remains controlling) might encourage broader input and understanding in the future. * Reference to IANA and ASO Roles: It might help to explicitly reference how global policies (via the ASO AC) and the IANA numbering services tie into this governance document. For instance, a statement that “Nothing in this document alters the Global Policy Development Process as defined in the ASO MoU, and RIRs must continue to adhere to global policies (which is indeed one of the criteria carried over).” Also, perhaps clarify that ICANN’s role in recognition is executed via its Board with advice from the ASO AC as needed. These linkages are mostly understood by insiders, but making them explicit will paint a complete picture of the governance landscape for newcomers reading this document. 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.