Feedback on the Version 2 (DRAFT) RIR Governance Document
Dear RIPE Colleagues, We appreciate the opportunity to provide feedback on the “Governance Document for the Recognition, Maintenance, and Derecognition of RIRs” (Version 2 (DRAFT)). After speaking with many members of the global Internet community, this e-mail captures the collective feedback discussed. We sincerely appreciate the NRO Number Council (NRO NC) and all community members who have dedicated significant time and effort to producing this second draft of the RIR Governance Document. This is a critical and complex undertaking, and we value the progress made. We share the goals articulated in the draft's preamble: to "Ensure Accountability," "Support System Stability and Continuity," and "Preserve the Bottom-Up, Multistakeholder Model". We offer our feedback in a constructive spirit to ensure this draft achieves those goals in a legally sound and operationally robust manner. The community has a critical need to address these issues in an open and transparent means for the betterment of the Internet. TL;DR – Executive Summary & Key Takeaways (for those with limited time) We support evolving ICP-2 into a binding governance framework. This timely and necessary evolution requires the NRO NC to provide the foundation for essential conversations between all RIRs and ICANN—the only entities that can resolve issues of enforceability, transparency, and operational robustness within this draft framework. Immediate transparency is required. Each RIR and ICANN must publicly identify any objections to this framework or obstacles to adoption. This must be done promptly, with feedback shared openly and transparently with the entire Internet community, including all stakeholders. Governance and Global Policy must remain separate. Existing avenues serve each; discussions must focus on their respective domains without co-mingling. We must immediately establish and transparently communicate clear next steps and timelines. The community deserves meaningful inclusion. Beyond representation through the NRO NC or RIR representatives, the community deserves access to open and transparent meetings, including working sessions where any community member can attend and witness proceedings. Critical issues require immediate attention. Next steps must address continuity, data security, and rapidly finalize NRO NC efforts to ensure the security and stability of the Internet. We have an obligation to protect the RIRs, and the community must be included in this process. Continuity first: Adopt a domain-style Emergency Back-End Registry Operator (EBERO) model with clearly defined, proactive continuity triggers. * Include escrow of registry and operational data. * Define approved operators under contract with ICANN and/or RIRs. * Avoid peer-triggered failover; replace with technical + legal thresholds for real-time action. Detail obligations: * Define “financially stable and independent” using public, measurable criteria. * Require annual financial audits and triennial governance audits. * Establish formal rehabilitation pathways for non-compliant RIRs, with deadlines and enforcement. Legal backbone: Convert this draft into bilateral, binding Recognition Agreements between each RIR and a Trusted Neutral 3rd Party (currently ICANN via PTI post IANA Transition). * This gives legal force to global obligations (audits, compliance, continuity, and recognition/derecognition). * Supersede the ineffective Section 4.1(i) “local law” carve-out—no global policy can be optional. * Mandate structural alignment (e.g. bylaws, MoUs) with this governance framework. * This framework can support the current legal relationship with ICANN. Decision-making Fixes: * Replace unanimity with super-majority or arbitration to prevent stalemates. * Lower derecognition thresholds the current numbers are an incumbent shield. Understand that 5% is too low and opens risk for organizational capture. * Give ICANN an emergency escalation trigger when RIRs cannot act with clearly articulated rules for usage. * Empower an independent Ombudsman. Structural gaps: * Acknowledge and resolve the NRO’s non-legal status and its dual role as ASO. * Mandate a transparent public charter defining ASO/NRO/RIR relationships, funding, and obligations. * Avoid “peer-led takeovers”—fiduciary risk is too high. Legal continuity must rely on contractual mechanisms, not political votes. Honor the spirit and keep IANA transition promises: * Preserve bottom-up multistakeholder authority. * Require open, transparent processes for all implementation procedures. * Ensure community-driven oversight, not just RIR/ICANN negotiations behind closed doors. * Provide achievable continuity of services for all RIRs. This e-mail formally analyzes the draft. We find that while it introduces necessary concepts, it contains fundamental structural and legal ambiguities that threaten an effective governance framework. We will identify these ambiguities, explain their legal and operational consequences, and propose specific, actionable next steps to resolve them. This feedback focuses on building upon the draft’s revision – offering draft-specific feedback on clarity, requirements, and provisions – while attempting to determine future plans for implementation details. Our comments center on whether the new draft addresses identified issues, whether the ongoing obligations and remediation processes are sufficiently defined, and the community's next steps to ensure continuity and accountability. We also highlight certain structural concerns and suggest improvements, all in the spirit of constructively refining the draft. Finally, we conclude with our general support for this important process. The remainder of this e-mail addresses detailed structural, legal, and governance recommendations and should be reviewed in full. Key Structural Deficiencies and a Proposed Path Forward This draft represents an attempt by the numbering community to self-regulate. However, it fails to resolve the central legal conflict of the RIR system: the supremacy of RIRs' local legal incorporation over the "global policy" and community consensus this draft purports to enforce. Summary of Core Deficiencies 1. The "Local Law" Supremacy Clause (Sec. 4.1(i)): The draft grants RIRs an explicit "carve-out" to ignore any global policy or draft provision if it conflicts with "any applicable law" [Sec 4.1(i)]. This single clause invalidates the entire framework, rendering it advisory rather than binding, and explicitly permits the very capture and fragmentation it was meant to prevent. 2. The "Implementation Procedures" Black Box (Sec. 1.3): The draft defers critical, substantive details of governance, compliance, and continuity to "Implementation Procedures". These procedures are to be developed later, solely by "the RIRs and ICANN", with no explicit guarantee of the "open, transparent, bottom-up" community process mandated for other policies [Sec 4.1(h)]. This is an unacceptable risk, creating a vector for capture and dilution of intent for this draft. 3. Ineffective Accountability Triggers (Sec. 2.4, 4.2): The member-initiated triggers for audits and derecognition—set at "25% of the RIR's total Members or 2,000 Members, whichever is lesser" [Sec 2.3(b)(i)(B), Sec 2.4(b)]—are prohibitively high. They are a defense for incumbents, not a tool for the stated goal of "member-driven oversight". Equally 5% or 100 members is too low and opens the door for organizational capture. 4. A Weak and Reactive Continuity Model (Art. 5): The "Emergency Continuity" plan is dangerously underdeveloped. It is reactive, requiring unanimous agreement from all other RIRs and ICANN after a failure has already occurred [Sec 5.1(a)], rather than a proactive, funded, and tested system. This lags significantly behind the contractual, secure models used in the domain name community. We already have clear examples where ICANN failed to act in response to the AFRINIC crisis. Continuity is paramount and all industry participants must have a clear understanding of their role in continuity. Proposed Path Forward The NRO NC, having now received substantive community feedback, has completed its analysis. The next essential step is to move from drafting to adjudication. We formally request the NRO NC to conclude their drafting and engage the leadership of ICANN and each of the five RIR Executive Boards, asking them to clearly and publicly articulate to the community any objections they may have to this draft as written. This will bring any private objections (e.g., to removing the "local law" carve-out) into the open and create a transparent, documented basis for resolving these final, critical issues. Foundational Legal Basis and Structural Flaws: A Legal Analysis This section serves as our legal brief on the draft standing and core flaws. The Draft’s Legal Standing: A Multilateral Agreement, Not an enforceable "Law" The draft’s preamble, which states it is an "initiative led by the NRO Number Council (NRO NC), also serving as the ASO Address Council (ASO AC)" highlights a foundational legal ambiguity. The Number Resource Organization (NRO) is an unincorporated "coordinating body for the five RIRs". It is, in effect, a trade association. It has no independent legal personality or authority to create binding "policy” or “laws" for its members (the RIRs) or for ICANN. It has no accountability to any community as it cannot enter into any legal contracts. Any substantial obligation the NRO undertakes requires the explicit agreement and signatures of all five RIRs. This structure still has substantial anti-trust and competition concerns. The Address Supporting Organization (ASO) is an official Supporting Organization within the ICANN structure. Its role and relationship with ICANN are defined by the ASO Memorandum of Understanding (MoU). The relationship between these bodies is the source of profound conflicts of interest and transparency failures. The RIRs created the NRO, which then, via the 2004 (and 2019) ASO MoU, fulfills the role of the ASO. This "dual-hatting" means the RIRs' coordination body is also the body meant to provide independent policy advice to ICANN specifically about numbering and RIR governance–This is a textbook unmitigated conflict of interest. Therefore, this draft cannot be a "law." Its only path to legal force is, as defined in its own Article 7.1, "the unanimous agreement of ICANN and the RIRs". This draft must be treated as a proposed binding, multilateral agreement—a contract—between ICANN and the five RIR legal entities. This framing is essential for understanding why the loopholes and carve-outs it contains are so dangerous. It is not a policy; it is the charter for the system's operation. Currently, ICANN is a vendor to the RIRs via a contract the RIRs have with PTI which is part of ICANN. As we would consider trusted neutral 3rd parties to support audits, continuity, and recognition we might envision an expansion of this relationship to provide the many services such as the emergency backup or even a party to manage RIR recognition and conduct de-recognition processes if ever needed. This all must be contractual to be enforceable. The Fatal Flaw: Section 4.1(i) and the "Local Law" Carve-Out The core of the community's concern is correctly identified as Section 4.1(i). The clause states an RIR must comply with policies "so long as those Number Resource Policies do not obligate the RIR to violate any applicable law" [Sec 4.1(i)]. This subordinates the entire global framework to the local judiciary of any RIR's headquarters. This concern is often raised regarding RIPE NCC, which is incorporated as a membership association under Dutch law. The concern that RIPE NCC's structure prevents accountability is correct in principle, the problem is the RIPE NCC's obligation to comply with Dutch law over global policy. Research confirms that RIPE NCC, as a Dutch association, is subject to Dutch court orders and has been compelled by them in the past. Under Section 4.1(i) as written, a single Dutch court order could force RIPE NCC to violate a global policy, and this draft would explicitly permit it. This nullifies the concept of "global" policy and accountability, creating five different legal regimes (USA, Netherlands, Mauritius, Brazil, Australia) instead of one. Recommendation: This carve-out must be removed. The draft’s "Rectification" clause (Sec. 7.2) must be inverted. It should not be a "grace period" for RIRs to comply; it must be a mandatory "cure period" during which an RIR must effect any structural or legal changes necessary (e.g., changes to its articles of association or corporate form) to achieve compliance with the global draft. This is the only way to establish the supremacy of the global multistakeholder consensus over local legal structures. Note the domain name industry has already accomplished this with their structure with ICANN. The RIRs need for autonomy has opened the existing structure to anti-trust, jurisdictional, competitive, capture, and other vulnerabilities. Separation of Governance and Policy A foundational principle of good governance is the separation of the rules of the system (governance) from the outputs of the system (policy). This draft fails to maintain that separation. This draft is a governance document. It establishes the entities, their obligations, and the accountability mechanisms. "Global Policies" are policy outputs related to number resources, developed via the Policy Development Process (PDP) [Sec 1.1, Sec 4.1(h)]. By including the Section 4.1(i) "carve-out" for policies, the draft co-mingles these two distinct layers. It allows a local legal challenge to a policy to invalidate the governance commitment. Recommendation: This draft must be finalized as the Master Governance Agreement for the RIR System. Its sole purpose should be to define the rules, recognition, and accountability of the RIRs themselves. It should simply state that RIRs must comply with Global Policies developed through the ICANN/ASO process with no legal carve-outs. This separates the charter of the system from the policies that run on it. Analysis of Community Protections: Accountability, Transparency, and Continuity Proposals for robust anti-capture, continuity, and transparency measures were not meaningfully integrated into this draft. Accountability and Anti-Capture (Failure) The triggers for an ad-hoc audit (Sec. 2.4) or a derecognition proposal (Sec. 2.3) based on member action are "at least 25% of the RIR's total Members or 2,000 Members, whichever is lesser" [Sec 2.3(b)(i)(B), Sec 2.4(b)]. These thresholds are not an accountability tool; they are an impenetrable shield for RIR management and boards. The language supporting an ICANN triggered audit lacks clear direction and undermines ICANNs ability to trigger an audit requiring RIR approvals. There should be pre-determined rules that are open an transparent to direct the audit triggers. 1. RIPE NCC has approximately 20,000 members. 25% would be 5,000. The trigger is therefore 2,000 members. 2. ARIN has approximately 7,000 voting members. 25% is 1,750. 3. Organizing 2,000 (or 1,750) distinct corporate entities to sign a formal petition is a massive, expensive, and politically fraught undertaking. 4. Equally 5% or 100 members is far too low and opens organizational capture. This threshold makes the draft’s stated goal of "member-driven oversight" a fiction. Recommendation: These triggers are a clear sign of incumbent capture. They must be dramatically lowered to a realistic level and supplemented by an independent, system-wide Ombudsman with the power to initiate an audit. Transparency (Failure) Greater transparency into the relationship between the NRO, the ICANN ASO, and the RIRs is a core community demand. There must be clear and delineated lines of responsibility for each entity without overlap. This draft worsens this problem by accepting the conflated "NRO NC, also serving as the ASO AC" without question or definition. The ASO MoU is the only thing giving the NRO this power, yet this draft fails to clarify the lines of authority, funding, and legal liability between the RIRs (who fund everything), the NRO (their unincorporated agent), and the ASO (their ICANN mask). Furthermore, the community requires that "any meetings should be open," especially "working sessions." • Problem: Section 1.3 states the RIRs and ICANN will jointly develop the "Implementation Procedures". It does not state this development is subject to the "open, transparent, bottom-up" PDP mandated in Section 4.1(h). Or that this will include any community involvement, oversight, or participation. • Risk: This allows the RIRs and ICANN to create the real rules of the system in closed-door negotiations, bypassing the community. This is a primary vector for capture, manipulations, and deception. Recommendation: 1. This draft must mandate a formal, public charter clarifying the NRO-ASO relationship, its funding by the RIRs, and its legal status. 2. Section 1.3 must be amended to state explicitly that all "Implementation Procedures" are subject to a full community consultation and consensus process before they can be adopted by the RIRs and ICANN. 3. The ASO, NRO, RIRs, etc must be separate entities each conducting their specific purpose. Only through this separation can we remove conflicts and anti-competitive issues. Continuity and Data Security (Failure) The community requires confirmation of "Continuity, database security and protection against capture while protecting against monopoly." Article 5 ("Emergency Continuity") and Section 4.1(m) (Continuity) are the draft’s response, and they are wholly inadequate. • Section 4.1(m) requires RIRs to "share such records, data... with an Emergency Operator" [Sec 4.1(m)]. This is a vague promise, not a secure, audited, and tested data escrow program. Properly funded, regularly submitted escrow property, and on-going tests to verify data integrity and ability to recover from this escrow data. • Article 5 requires a unanimous vote of all other RIRs and ICANN to initiate an emergency continuity event [Sec 5.1(a)]. This is slow, political, and unworkable in a real crisis (e.g., a board capture, catastrophic financial failure, or government seizure). This is not a continuity plan; it is a political "last resort" trigger. It provides no real-time security for the registry database, which is a critical global resource. As drafted this does not maintain the security and stability of the Internet. The "Hasty" IANA Transition and the Domain Community Standard The numbering community's governance model, as reflected in this draft, is demonstrably weaker, less secure, and provides fewer protections against capture and failure than the domain community's model. This reflects a "hasty" approach during the IANA transition that prioritized RIR autonomy over global community accountability. The Domain Community Model (ICANN Contractual Compliance) • Accountability: gTLD registries and registrars operate under direct, legally-binding contracts (the Registry Agreement and Registrar Accreditation Agreement) with ICANN. ICANN has a dedicated Contractual Compliance department to enforce these terms. • Continuity (EBERO): The domain community has the Emergency Back-End Registry Operator (EBERO) program. This is a proactive, funded, and testedsystem. ICANN has contracts with third-party operators to take over "Critical Functions" (DNS resolution, Shared Registration System, Registration Data Directory Services, Data Escrow) in the event of a registry failure. This system has been activated to protect registrants. The Numbering Community Model (This Draft) • Accountability: A "collegial" model based on "good faith" 1 and unanimous consent of peers (the other RIRs) to initiate an audit or derecognition [Sec 2.3(b)(v), Sec 2.4(a)]. This is peer protection, not public accountability. • Continuity: A reactive model (Article 5) that requires a unanimous political vote during an emergency. Conclusion & Recommendation: The numbering community's governance must be brought up to the standard set by the domain community. We recommend that Article 5 and Section 4.1(m) be removed and replaced with a mandate for the RIRs and ICANN to jointly develop and fund a formal, EBERO-equivalent program for the Internet Numbers Registry System. This program must ensure proactive, secure data escrow, defined technical triggers for activation (not requiring RIR peer-unanimity), and a funded, contracted, independent operator ready to ensure service continuity.This can be under the legal framework that exists with ICANN, PTI, and the RIRs today. But should be re-evaluated in the future to evolve this to the benefit of number resource registrants. Conclusion and Formal Next Steps We thank the NRO NC for its work in stewarding this draft. The community has now provided exhaustive feedback identifying critical, structural flaws. Further drafting by the same group will not solve these high-level political and legal impasses. The time for community drafting is over; the time for leadership commitment has begun. We formally request that the NRO NC, as the convenor of this process, now execute the following transparent, "top-down" finalization process: 1. Engage Leadership: Formally transmit this draft (and a summary of community objections) to the ICANN Board and the Executive Boards of all five RIRs. 2. Request Public Comment: Request that each of these six bodies provide a formal, public, on-the-record response to the community, articulating: o Their official position on the draft. o Any specific objections they have to the draft as written, especially regarding: • The removal of the "local law" carve-out (Sec. 4.1(i)). • The mandate for community oversight of "Implementation Procedures" (Sec. 1.3). • The strengthening of accountability triggers (Sec. 2.4, 4.2). • The mandate to create a formal EBERO-equivalent continuity program (Art. 5). 1. Document and Resolve: Publicly document all objections and establish a final, open, and transparent process (with open working sessions, as requested by the community) to adjudicate and resolve these specific, documented objections. This is the only path to a final, binding document that the community can trust. We must not defer these fundamental conflicts to "Implementation Procedures" to be solved in secret, at a later date. The risk of capture is too high, and the security and stability of the Internet Numbers Registry System is too important. We look forward to participating in this next, critical phase of the process. 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. Recommended Further Reading and Supporting Documents 1. The current v2 DRAFT RIR-Governance-Document-v2-FINAL.pdf, https://www.nro.net/wp-content/uploads/RIR-Governance-Document-v2-FINAL.pdf 2. Emergency Back-end Registry Operator - icann, accessed November 6, 2025, https://www.icann.org/en/contracted-parties/registry-operators/resources/eme... 3. Safe and Secure New gTLDs: ICANN Seeks Back-up Registry Operators | (Emergency Back-End Registry Operators or "EBEROs"), accessed November 6, 2025, https://www.icann.org/en/announcements/details/safe-and-secure-new-gtlds-ica... 4. Registry Transition Processes - icann, accessed November 6, 2025, https://www.icann.org/registry-transition-processes-en 5. What is the relationship between the ASO and the NRO | The Address Supporting ... - icann, accessed November 6, 2025, https://aso.icann.org/faq/what-is-the-relationship-between-the-aso-and-the-n... 6. ASO & NRO | The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/about/aso-and-nro/ 7. The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/about/aso-icann/ 8. ICANN ASO MoU 2019 | The Number Resource Organization, accessed November 6, 2025, https://www.nro.net/icann-aso-mou-2019/ 9. ICANN – ASO MoU (2019) | The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/documents/memorandums-of-understanding/icann-address-s... 10. ASO Memorandum of Understanding | The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/documents/memorandums-of-understanding/aso-memorandum-... 11. NRO Number Council - American Registry for Internet Numbers - ARIN, accessed November 6, 2025, https://www.arin.net/about/welcome/nronc/ 12. RIPE NCC Website and Publicly Available RIPE NCC Services Terms of Service, accessed November 6, 2025, https://www.ripe.net/about-us/legal/terms-of-service/ 13. RIPE NCC Standard Service Agreement, accessed November 6, 2025, https://www.ripe.net/publications/docs/ripe-812/ 14. RIPE NCC Conflict Arbitration Procedure — RIPE Network ..., accessed November 6, 2025, https://www.ripe.net/publications/docs/ripe-844/ 15. Update on Court Proceedings Between RIPE NCC and State of the Netherlands, accessed November 6, 2025, https://www.ripe.net/about-us/news/update-on-court-proceedings-between-ripe-... 16. A First for the RIPE NCC: Seizure of the “Right to Registration of IPv4 Addresses” for the Recovery of Money, accessed November 6, 2025, https://labs.ripe.net/author/ciaran_byrne/a-first-for-the-ripe-ncc-seizure-o... 17. Seizing IP addresses in the Netherlands as a security for your damages claims in international litigation - Taylor Wessing, accessed November 6, 2025, https://www.taylorwessing.com/en/insights-and-events/insights/2023/07/seizin... 18. About Registrars - ICANN, accessed November 6, 2025, https://www.icann.org/resources/pages/what-2013-05-03-en 19. gTLD Registry Continuity - icann, accessed November 6, 2025, https://www.icann.org/en/contracted-parties/registry-operators/resources/eme... 20. ICANN to Move Four gTLDs Into the Emergency Back-End Registry Operator Program, accessed November 6, 2025, https://www.icann.org/en/announcements/details/icann-to-move-four-gtlds-into... 21. Fact Sheet: The IANA Stewardship Transition Explained, https://www.ntia.gov/other-publication/fact-sheet-iana-stewardship-transitio... 22. Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions, https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd...
On 7 Nov 2025, at 16:35, William Sylvester via ripe-list <ripe-list@ripe.net> wrote:
We appreciate the opportunity to provide feedback
Who is "we" here? Your very detailed response isn't clear on that point.
Jim, thanks for your note. I bring these comments forward as myself, but with extensive discussions from many individuals in the global Internet community, attendees at RIR meetings, conferences, and events with others who offered their opinions on these matters which were consolidated as this feedback. On 11/7/25, 2:31 PM, "Jim Reid" <jim@rfc1035.com <mailto:jim@rfc1035.com>> wrote:
On 7 Nov 2025, at 16:35, William Sylvester via ripe-list <ripe-list@ripe.net <mailto:ripe-list@ripe.net>> wrote:
We appreciate the opportunity to provide feedback
Who is "we" here? Your very detailed response isn't clear on that point.
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 9:14 PM, William Sylvester via ripe-list <ripe-list@ripe.net> wrote: Jim, thanks for your note. I bring these comments forward as myself, but with extensive discussions from many individuals in the global Internet community, attendees at RIR meetings, conferences, and events with others who offered their opinions on these matters which were consolidated as this feedback. On 11/7/25, 2:31 PM, "Jim Reid" <jim@rfc1035.com <mailto:jim@rfc1035.com>> wrote: On 7 Nov 2025, at 16:35, William Sylvester via ripe-list <ripe-list@ripe.net <mailto:ripe-list@ripe.net>> wrote: We appreciate the opportunity to provide feedback Who is "we" here? Your very detailed response isn't clear on that point. ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://urldefense.com/v3/__https://mailman.ripe.net/mailman3/lists/ripe-lis... [mailman[.]ripe[.]net] As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://urldefense.com/v3/__https://www.ripe.net/membership/mail/mailman-3-m... [ripe[.]net]
Hi, On 7 Nov 2025, at 16:35, William Sylvester via ripe-list <ripe-list@ripe.net> wrote: […]
Summary of Core Deficiencies 1. The "Local Law" Supremacy Clause (Sec. 4.1(i)): The draft grants RIRs an explicit "carve-out" to ignore any global policy or draft provision if it conflicts with "any applicable law" [Sec 4.1(i)]. This single clause invalidates the entire framework, rendering it advisory rather than binding, and explicitly permits the very capture and fragmentation it was meant to prevent.
Can you please expand on this as I don’t understand your concern as it relates to Global Policies. The 2019 ASO MoU defines Global Policy as “number resource policies that have the agreement of all RIRs according to their policy development processes and ICANN, and require specific actions or outcomes on the part of IANA or any other external ICANN-related body in order to be implemented.” (my emphasis) So far, we only have global policies that require IANA action. They empower the RIRs to get resources from IANA. https://www.nro.net/icann-aso-mou-2019/ https://www.nro.net/policy/global/ Can you explain the kind of law and the kind of policy you have in mind? Thanks, Leo
Hi Leo, Thank you for the reply, this is one of the structural vulnerabilities in the draft framework. You're absolutely right that current Global Policies are narrowly scoped to IANA functions and resource empowerment. My concern isn't with how Global Policies work today, but rather with how Section 4.1(i) could undermine the ICP-2 evolution framework itself – particularly if we ever need Global Policies that impose obligations on RIRs rather than just IANA. Section 4.1(i) creates an explicit escape hatch: any RIR can disregard any provision of the ICP-2 evolution framework (including governance obligations, accountability measures, or operational requirements) by invoking "applicable law." This transforms what should be binding commitments into optional guidelines. Consider these hypothetical but plausible examples: 1. Data Localization/Sovereignty Laws Harming Continuity: An RIR might invoke data residency requirements to justify refusing cross-regional coordination or registry data sharing that the framework requires for stability and interoperability or denying data escrows to enable continuity. 2. Competition/Antitrust or other Legal Compliance: An RIR might claim that coordinating with other RIRs (as the framework requires) violates local competition law, using 4.1(i) to fragment unified operations. A court could order that the property of the RIR (including all the IP registrations) could go to the Government or a Plantiff in a lawsuit. 3. National Security Carve-outs: Increasingly, governments claim authority over "critical infrastructure" including internet resources. An RIR could invoke such laws to override governance provisions requiring transparency, due process, or multi-stakeholder participation. Many of the links I provided speak to some real-world examples where some of these examples have already happened. Why This Matters for ICP-2 RIR Governance Draft The 2019 ASO MoU definition you cited is correct but incomplete for this context. While today's Global Policies focus on IANA empowerment, the ICP-2 evolution framework must establish governance obligations that bind RIRs themselves – not just IANA. Section 4.1(i) preemptively exempts RIRs from these obligations whenever convenient. The draft attempts to create enforceable accountability but simultaneously provides an unlimited waiver. Any provision requiring RIRs to maintain registry accuracy, ensure equitable access, provide due process, coordinate operations, or maintain transparency can be ignored by invoking "applicable law." Proposed Solution Rather than a blanket supremacy clause, the framework should: * Acknowledge that RIRs operate under various jurisdictions * Require transparent disclosure when legal conflicts arise * Establish a structured process for addressing genuine legal conflicts * Distinguish between mandatory compliance with actual legal requirements versus voluntary invocation of legal ambiguity as policy cover * Empower revocation of an RIR if these diverge in a way that an RIR can no longer comply with the Global Policy and protect the number registrations as a result for end-users. The current language in 4.1(i) does none of this – it simply grants unilateral authority to disregard any inconvenient obligation. I'm happy to discuss this in detail with you if that would be helpful. Thanks, William From: Leo Vegoda <leo@vegoda.org> Date: Saturday, November 8, 2025 at 6:08 AM To: bills <william.sylvester@addrex.net> Cc: "ripe-list@ripe.net" <ripe-list@ripe.net> Subject: Re: [ripe-list] Feedback on the Version 2 (DRAFT) RIR Governance Document Hi, On 7 Nov 2025, at 16:35, William Sylvester via ripe-list <ripe-list@ripe.net> wrote: […] Summary of Core Deficiencies 1. The "Local Law" Supremacy Clause (Sec. 4.1(i)): The draft grants RIRs an explicit "carve-out" to ignore any global policy or draft provision if it conflicts with "any applicable law" [Sec 4.1(i)]. This single clause invalidates the entire framework, rendering it advisory rather than binding, and explicitly permits the very capture and fragmentation it was meant to prevent. Can you please expand on this as I don’t understand your concern as it relates to Global Policies. The 2019 ASO MoU defines Global Policy as “number resource policies that have the agreement of all RIRs according to their policy development processes and ICANN, and require specific actions or outcomes on the part of IANA or any other external ICANN-related body in order to be implemented.” (my emphasis) So far, we only have global policies that require IANA action. They empower the RIRs to get resources from IANA. ICANN ASO MoU 2019 | The Number Resource Organization<https://www.nro.net/icann-aso-mou-2019/> nro.net<https://www.nro.net/icann-aso-mou-2019/> [cid:image001.png@01DC5236.79F42FB0]<https://www.nro.net/icann-aso-mou-2019/> Global Policy | The Number Resource Organization<https://www.nro.net/policy/global/> nro.net<https://www.nro.net/policy/global/> [cid:image001.png@01DC5236.79F42FB0]<https://www.nro.net/policy/global/> Can you explain the kind of law and the kind of policy you have in mind? Thanks, Leo
I am not checking my emails until Nov 14th, 2025. Thanks, Samaneh On Nov 7, 2025, at 5:35 PM, William Sylvester via ripe-list <ripe-list@ripe.net> wrote: Dear RIPE Colleagues, We appreciate the opportunity to provide feedback on the “Governance Document for the Recognition, Maintenance, and Derecognition of RIRs” (Version 2 (DRAFT)). After speaking with many members of the global Internet community, this e-mail captures the collective feedback discussed. We sincerely appreciate the NRO Number Council (NRO NC) and all community members who have dedicated significant time and effort to producing this second draft of the RIR Governance Document. This is a critical and complex undertaking, and we value the progress made. We share the goals articulated in the draft's preamble: to "Ensure Accountability," "Support System Stability and Continuity," and "Preserve the Bottom-Up, Multistakeholder Model". We offer our feedback in a constructive spirit to ensure this draft achieves those goals in a legally sound and operationally robust manner. The community has a critical need to address these issues in an open and transparent means for the betterment of the Internet. TL;DR – Executive Summary & Key Takeaways (for those with limited time) We support evolving ICP-2 into a binding governance framework. This timely and necessary evolution requires the NRO NC to provide the foundation for essential conversations between all RIRs and ICANN—the only entities that can resolve issues of enforceability, transparency, and operational robustness within this draft framework. Immediate transparency is required. Each RIR and ICANN must publicly identify any objections to this framework or obstacles to adoption. This must be done promptly, with feedback shared openly and transparently with the entire Internet community, including all stakeholders. Governance and Global Policy must remain separate. Existing avenues serve each; discussions must focus on their respective domains without co-mingling. We must immediately establish and transparently communicate clear next steps and timelines. The community deserves meaningful inclusion. Beyond representation through the NRO NC or RIR representatives, the community deserves access to open and transparent meetings, including working sessions where any community member can attend and witness proceedings. Critical issues require immediate attention. Next steps must address continuity, data security, and rapidly finalize NRO NC efforts to ensure the security and stability of the Internet. We have an obligation to protect the RIRs, and the community must be included in this process. Continuity first: Adopt a domain-style Emergency Back-End Registry Operator (EBERO) model with clearly defined, proactive continuity triggers. • Include escrow of registry and operational data. • Define approved operators under contract with ICANN and/or RIRs. • Avoid peer-triggered failover; replace with technical + legal thresholds for real-time action. Detail obligations: • Define “financially stable and independent” using public, measurable criteria. • Require annual financial audits and triennial governance audits. • Establish formal rehabilitation pathways for non-compliant RIRs, with deadlines and enforcement. Legal backbone: Convert this draft into bilateral, binding Recognition Agreements between each RIR and a Trusted Neutral 3rd Party (currently ICANN via PTI post IANA Transition). • This gives legal force to global obligations (audits, compliance, continuity, and recognition/derecognition). • Supersede the ineffective Section 4.1(i) “local law” carve-out—no global policy can be optional. • Mandate structural alignment (e.g. bylaws, MoUs) with this governance framework. • This framework can support the current legal relationship with ICANN. Decision-making Fixes: • Replace unanimity with super-majority or arbitration to prevent stalemates. • Lower derecognition thresholds the current numbers are an incumbent shield. Understand that 5% is too low and opens risk for organizational capture. • Give ICANN an emergency escalation trigger when RIRs cannot act with clearly articulated rules for usage. • Empower an independent Ombudsman. Structural gaps: • Acknowledge and resolve the NRO’s non-legal status and its dual role as ASO. • Mandate a transparent public charter defining ASO/NRO/RIR relationships, funding, and obligations. • Avoid “peer-led takeovers”—fiduciary risk is too high. Legal continuity must rely on contractual mechanisms, not political votes. Honor the spirit and keep IANA transition promises: • Preserve bottom-up multistakeholder authority. • Require open, transparent processes for all implementation procedures. • Ensure community-driven oversight, not just RIR/ICANN negotiations behind closed doors. • Provide achievable continuity of services for all RIRs. This e-mail formally analyzes the draft. We find that while it introduces necessary concepts, it contains fundamental structural and legal ambiguities that threaten an effective governance framework. We will identify these ambiguities, explain their legal and operational consequences, and propose specific, actionable next steps to resolve them. This feedback focuses on building upon the draft’s revision – offering draft-specific feedback on clarity, requirements, and provisions – while attempting to determine future plans for implementation details. Our comments center on whether the new draft addresses identified issues, whether the ongoing obligations and remediation processes are sufficiently defined, and the community's next steps to ensure continuity and accountability. We also highlight certain structural concerns and suggest improvements, all in the spirit of constructively refining the draft. Finally, we conclude with our general support for this important process. The remainder of this e-mail addresses detailed structural, legal, and governance recommendations and should be reviewed in full. Key Structural Deficiencies and a Proposed Path Forward This draft represents an attempt by the numbering community to self-regulate. However, it fails to resolve the central legal conflict of the RIR system: the supremacy of RIRs' local legal incorporation over the "global policy" and community consensus this draft purports to enforce. Summary of Core Deficiencies 1. The "Local Law" Supremacy Clause (Sec. 4.1(i)): The draft grants RIRs an explicit "carve-out" to ignore any global policy or draft provision if it conflicts with "any applicable law" [Sec 4.1(i)]. This single clause invalidates the entire framework, rendering it advisory rather than binding, and explicitly permits the very capture and fragmentation it was meant to prevent. 2. The "Implementation Procedures" Black Box (Sec. 1.3): The draft defers critical, substantive details of governance, compliance, and continuity to "Implementation Procedures". These procedures are to be developed later, solely by "the RIRs and ICANN", with no explicit guarantee of the "open, transparent, bottom-up" community process mandated for other policies [Sec 4.1(h)]. This is an unacceptable risk, creating a vector for capture and dilution of intent for this draft. 3. Ineffective Accountability Triggers (Sec. 2.4, 4.2): The member-initiated triggers for audits and derecognition—set at "25% of the RIR's total Members or 2,000 Members, whichever is lesser" [Sec 2.3(b)(i)(B), Sec 2.4(b)]—are prohibitively high. They are a defense for incumbents, not a tool for the stated goal of "member-driven oversight". Equally 5% or 100 members is too low and opens the door for organizational capture. 4. A Weak and Reactive Continuity Model (Art. 5): The "Emergency Continuity" plan is dangerously underdeveloped. It is reactive, requiring unanimous agreement from all other RIRs and ICANN after a failure has already occurred [Sec 5.1(a)], rather than a proactive, funded, and tested system. This lags significantly behind the contractual, secure models used in the domain name community. We already have clear examples where ICANN failed to act in response to the AFRINIC crisis. Continuity is paramount and all industry participants must have a clear understanding of their role in continuity. Proposed Path Forward The NRO NC, having now received substantive community feedback, has completed its analysis. The next essential step is to move from drafting to adjudication. We formally request the NRO NC to conclude their drafting and engage the leadership of ICANN and each of the five RIR Executive Boards, asking them to clearly and publicly articulate to the community any objections they may have to this draft as written. This will bring any private objections (e.g., to removing the "local law" carve-out) into the open and create a transparent, documented basis for resolving these final, critical issues. Foundational Legal Basis and Structural Flaws: A Legal Analysis This section serves as our legal brief on the draft standing and core flaws. The Draft’s Legal Standing: A Multilateral Agreement, Not an enforceable "Law" The draft’s preamble, which states it is an "initiative led by the NRO Number Council (NRO NC), also serving as the ASO Address Council (ASO AC)" highlights a foundational legal ambiguity. The Number Resource Organization (NRO) is an unincorporated "coordinating body for the five RIRs". It is, in effect, a trade association. It has no independent legal personality or authority to create binding "policy” or “laws" for its members (the RIRs) or for ICANN. It has no accountability to any community as it cannot enter into any legal contracts. Any substantial obligation the NRO undertakes requires the explicit agreement and signatures of all five RIRs. This structure still has substantial anti-trust and competition concerns. The Address Supporting Organization (ASO) is an official Supporting Organization within the ICANN structure. Its role and relationship with ICANN are defined by the ASO Memorandum of Understanding (MoU). The relationship between these bodies is the source of profound conflicts of interest and transparency failures. The RIRs created the NRO, which then, via the 2004 (and 2019) ASO MoU, fulfills the role of the ASO. This "dual-hatting" means the RIRs' coordination body is also the body meant to provide independent policy advice to ICANN specifically about numbering and RIR governance–This is a textbook unmitigated conflict of interest. Therefore, this draft cannot be a "law." Its only path to legal force is, as defined in its own Article 7.1, "the unanimous agreement of ICANN and the RIRs". This draft must be treated as a proposed binding, multilateral agreement—a contract—between ICANN and the five RIR legal entities. This framing is essential for understanding why the loopholes and carve-outs it contains are so dangerous. It is not a policy; it is the charter for the system's operation. Currently, ICANN is a vendor to the RIRs via a contract the RIRs have with PTI which is part of ICANN. As we would consider trusted neutral 3rd parties to support audits, continuity, and recognition we might envision an expansion of this relationship to provide the many services such as the emergency backup or even a party to manage RIR recognition and conduct de-recognition processes if ever needed. This all must be contractual to be enforceable. The Fatal Flaw: Section 4.1(i) and the "Local Law" Carve-Out The core of the community's concern is correctly identified as Section 4.1(i). The clause states an RIR must comply with policies "so long as those Number Resource Policies do not obligate the RIR to violate any applicable law" [Sec 4.1(i)]. This subordinates the entire global framework to the local judiciary of any RIR's headquarters. This concern is often raised regarding RIPE NCC, which is incorporated as a membership association under Dutch law. The concern that RIPE NCC's structure prevents accountability is correct in principle, the problem is the RIPE NCC's obligation to comply with Dutch law over global policy. Research confirms that RIPE NCC, as a Dutch association, is subject to Dutch court orders and has been compelled by them in the past. Under Section 4.1(i) as written, a single Dutch court order could force RIPE NCC to violate a global policy, and this draft would explicitly permit it. This nullifies the concept of "global" policy and accountability, creating five different legal regimes (USA, Netherlands, Mauritius, Brazil, Australia) instead of one. Recommendation: This carve-out must be removed. The draft’s "Rectification" clause (Sec. 7.2) must be inverted. It should not be a "grace period" for RIRs to comply; it must be a mandatory "cure period" during which an RIR must effect any structural or legal changes necessary (e.g., changes to its articles of association or corporate form) to achieve compliance with the global draft. This is the only way to establish the supremacy of the global multistakeholder consensus over local legal structures. Note the domain name industry has already accomplished this with their structure with ICANN. The RIRs need for autonomy has opened the existing structure to anti-trust, jurisdictional, competitive, capture, and other vulnerabilities. Separation of Governance and Policy A foundational principle of good governance is the separation of the rules of the system (governance) from the outputs of the system (policy). This draft fails to maintain that separation. This draft is a governance document. It establishes the entities, their obligations, and the accountability mechanisms. "Global Policies" are policy outputs related to number resources, developed via the Policy Development Process (PDP) [Sec 1.1, Sec 4.1(h)]. By including the Section 4.1(i) "carve-out" for policies, the draft co-mingles these two distinct layers. It allows a local legal challenge to a policy to invalidate the governance commitment. Recommendation: This draft must be finalized as the Master Governance Agreement for the RIR System. Its sole purpose should be to define the rules, recognition, and accountability of the RIRs themselves. It should simply state that RIRs must comply with Global Policies developed through the ICANN/ASO process with no legal carve-outs. This separates the charter of the system from the policies that run on it. Analysis of Community Protections: Accountability, Transparency, and Continuity Proposals for robust anti-capture, continuity, and transparency measures were not meaningfully integrated into this draft. Accountability and Anti-Capture (Failure) The triggers for an ad-hoc audit (Sec. 2.4) or a derecognition proposal (Sec. 2.3) based on member action are "at least 25% of the RIR's total Members or 2,000 Members, whichever is lesser" [Sec 2.3(b)(i)(B), Sec 2.4(b)]. These thresholds are not an accountability tool; they are an impenetrable shield for RIR management and boards. The language supporting an ICANN triggered audit lacks clear direction and undermines ICANNs ability to trigger an audit requiring RIR approvals. There should be pre-determined rules that are open an transparent to direct the audit triggers. 1. RIPE NCC has approximately 20,000 members. 25% would be 5,000. The trigger is therefore 2,000 members. 2. ARIN has approximately 7,000 voting members. 25% is 1,750. 3. Organizing 2,000 (or 1,750) distinct corporate entities to sign a formal petition is a massive, expensive, and politically fraught undertaking. 4. Equally 5% or 100 members is far too low and opens organizational capture. This threshold makes the draft’s stated goal of "member-driven oversight" a fiction. Recommendation: These triggers are a clear sign of incumbent capture. They must be dramatically lowered to a realistic level and supplemented by an independent, system-wide Ombudsman with the power to initiate an audit. Transparency (Failure) Greater transparency into the relationship between the NRO, the ICANN ASO, and the RIRs is a core community demand. There must be clear and delineated lines of responsibility for each entity without overlap. This draft worsens this problem by accepting the conflated "NRO NC, also serving as the ASO AC" without question or definition. The ASO MoU is the only thing giving the NRO this power, yet this draft fails to clarify the lines of authority, funding, and legal liability between the RIRs (who fund everything), the NRO (their unincorporated agent), and the ASO (their ICANN mask). Furthermore, the community requires that "any meetings should be open," especially "working sessions." • Problem: Section 1.3 states the RIRs and ICANN will jointly develop the "Implementation Procedures". It does not state this development is subject to the "open, transparent, bottom-up" PDP mandated in Section 4.1(h). Or that this will include any community involvement, oversight, or participation. • Risk: This allows the RIRs and ICANN to create the real rules of the system in closed-door negotiations, bypassing the community. This is a primary vector for capture, manipulations, and deception. Recommendation: 1. This draft must mandate a formal, public charter clarifying the NRO-ASO relationship, its funding by the RIRs, and its legal status. 2. Section 1.3 must be amended to state explicitly that all "Implementation Procedures" are subject to a full community consultation and consensus process before they can be adopted by the RIRs and ICANN. 3. The ASO, NRO, RIRs, etc must be separate entities each conducting their specific purpose. Only through this separation can we remove conflicts and anti-competitive issues. Continuity and Data Security (Failure) The community requires confirmation of "Continuity, database security and protection against capture while protecting against monopoly." Article 5 ("Emergency Continuity") and Section 4.1(m) (Continuity) are the draft’s response, and they are wholly inadequate. • Section 4.1(m) requires RIRs to "share such records, data... with an Emergency Operator" [Sec 4.1(m)]. This is a vague promise, not a secure, audited, and tested data escrow program. Properly funded, regularly submitted escrow property, and on-going tests to verify data integrity and ability to recover from this escrow data. • Article 5 requires a unanimous vote of all other RIRs and ICANN to initiate an emergency continuity event [Sec 5.1(a)]. This is slow, political, and unworkable in a real crisis (e.g., a board capture, catastrophic financial failure, or government seizure). This is not a continuity plan; it is a political "last resort" trigger. It provides no real-time security for the registry database, which is a critical global resource. As drafted this does not maintain the security and stability of the Internet. The "Hasty" IANA Transition and the Domain Community Standard The numbering community's governance model, as reflected in this draft, is demonstrably weaker, less secure, and provides fewer protections against capture and failure than the domain community's model. This reflects a "hasty" approach during the IANA transition that prioritized RIR autonomy over global community accountability. The Domain Community Model (ICANN Contractual Compliance) • Accountability: gTLD registries and registrars operate under direct, legally-binding contracts (the Registry Agreement and Registrar Accreditation Agreement) with ICANN. ICANN has a dedicated Contractual Compliance department to enforce these terms. • Continuity (EBERO): The domain community has the Emergency Back-End Registry Operator (EBERO) program. This is a proactive, funded, and testedsystem. ICANN has contracts with third-party operators to take over "Critical Functions" (DNS resolution, Shared Registration System, Registration Data Directory Services, Data Escrow) in the event of a registry failure. This system has been activated to protect registrants. The Numbering Community Model (This Draft) • Accountability: A "collegial" model based on "good faith" 1 and unanimous consent of peers (the other RIRs) to initiate an audit or derecognition [Sec 2.3(b)(v), Sec 2.4(a)]. This is peer protection, not public accountability. • Continuity: A reactive model (Article 5) that requires a unanimous political vote during an emergency. Conclusion & Recommendation: The numbering community's governance must be brought up to the standard set by the domain community. We recommend that Article 5 and Section 4.1(m) be removed and replaced with a mandate for the RIRs and ICANN to jointly develop and fund a formal, EBERO-equivalent program for the Internet Numbers Registry System. This program must ensure proactive, secure data escrow, defined technical triggers for activation (not requiring RIR peer-unanimity), and a funded, contracted, independent operator ready to ensure service continuity.This can be under the legal framework that exists with ICANN, PTI, and the RIRs today. But should be re-evaluated in the future to evolve this to the benefit of number resource registrants. Conclusion and Formal Next Steps We thank the NRO NC for its work in stewarding this draft. The community has now provided exhaustive feedback identifying critical, structural flaws. Further drafting by the same group will not solve these high-level political and legal impasses. The time for community drafting is over; the time for leadership commitment has begun. We formally request that the NRO NC, as the convenor of this process, now execute the following transparent, "top-down" finalization process: 1. Engage Leadership: Formally transmit this draft (and a summary of community objections) to the ICANN Board and the Executive Boards of all five RIRs. 2. Request Public Comment: Request that each of these six bodies provide a formal, public, on-the-record response to the community, articulating: o Their official position on the draft. o Any specific objections they have to the draft as written, especially regarding: • The removal of the "local law" carve-out (Sec. 4.1(i)). • The mandate for community oversight of "Implementation Procedures" (Sec. 1.3). • The strengthening of accountability triggers (Sec. 2.4, 4.2). • The mandate to create a formal EBERO-equivalent continuity program (Art. 5). 3. Document and Resolve: Publicly document all objections and establish a final, open, and transparent process (with open working sessions, as requested by the community) to adjudicate and resolve these specific, documented objections. This is the only path to a final, binding document that the community can trust. We must not defer these fundamental conflicts to "Implementation Procedures" to be solved in secret, at a later date. The risk of capture is too high, and the security and stability of the Internet Numbers Registry System is too important. We look forward to participating in this next, critical phase of the process. 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. Recommended Further Reading and Supporting Documents 1. The current v2 DRAFT RIR-Governance-Document-v2-FINAL.pdf, https://www.nro.net/wp-content/uploads/RIR-Governance-Document-v2-FINAL.pdf [nro.net] 2. Emergency Back-end Registry Operator - icann, accessed November 6, 2025, https://www.icann.org/en/contracted-parties/registry-operators/resources/eme... 3. Safe and Secure New gTLDs: ICANN Seeks Back-up Registry Operators | (Emergency Back-End Registry Operators or "EBEROs"), accessed November 6, 2025, https://www.icann.org/en/announcements/details/safe-and-secure-new-gtlds-ica... 4. Registry Transition Processes - icann, accessed November 6, 2025, https://www.icann.org/registry-transition-processes-en 5. What is the relationship between the ASO and the NRO | The Address Supporting ... - icann, accessed November 6, 2025, https://aso.icann.org/faq/what-is-the-relationship-between-the-aso-and-the-n... [aso.icann.org] 6. ASO & NRO | The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/about/aso-and-nro/ [aso.icann.org] 7. The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/about/aso-icann/ [aso.icann.org] 8. ICANN ASO MoU 2019 | The Number Resource Organization, accessed November 6, 2025, https://www.nro.net/icann-aso-mou-2019/ [nro.net] 9. ICANN – ASO MoU (2019) | The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/documents/memorandums-of-understanding/icann-address-s... [aso.icann.org] 10. ASO Memorandum of Understanding | The Address Supporting Organization (ASO ICANN), accessed November 6, 2025, https://aso.icann.org/documents/memorandums-of-understanding/aso-memorandum-... [aso.icann.org] 11. NRO Number Council - American Registry for Internet Numbers - ARIN, accessed November 6, 2025, https://www.arin.net/about/welcome/nronc/ [arin.net] 12. RIPE NCC Website and Publicly Available RIPE NCC Services Terms of Service, accessed November 6, 2025, https://www.ripe.net/about-us/legal/terms-of-service/ [ripe.net] 13. RIPE NCC Standard Service Agreement, accessed November 6, 2025, https://www.ripe.net/publications/docs/ripe-812/ [ripe.net] 14. RIPE NCC Conflict Arbitration Procedure — RIPE Network ..., accessed November 6, 2025, https://www.ripe.net/publications/docs/ripe-844/ [ripe.net] 15. Update on Court Proceedings Between RIPE NCC and State of the Netherlands, accessed November 6, 2025, https://www.ripe.net/about-us/news/update-on-court-proceedings-between-ripe-... [ripe.net] 16. A First for the RIPE NCC: Seizure of the “Right to Registration of IPv4 Addresses” for the Recovery of Money, accessed November 6, 2025, https://labs.ripe.net/author/ciaran_byrne/a-first-for-the-ripe-ncc-seizure-o... [labs.ripe.net] 17. Seizing IP addresses in the Netherlands as a security for your damages claims in international litigation - Taylor Wessing, accessed November 6, 2025, https://www.taylorwessing.com/en/insights-and-events/insights/2023/07/seizin... [taylorwessing.com] 18. About Registrars - ICANN, accessed November 6, 2025, https://www.icann.org/resources/pages/what-2013-05-03-en 19. gTLD Registry Continuity - icann, accessed November 6, 2025, https://www.icann.org/en/contracted-parties/registry-operators/resources/eme... 20. ICANN to Move Four gTLDs Into the Emergency Back-End Registry Operator Program, accessed November 6, 2025, https://www.icann.org/en/announcements/details/icann-to-move-four-gtlds-into... 21. Fact Sheet: The IANA Stewardship Transition Explained, https://www.ntia.gov/other-publication/fact-sheet-iana-stewardship-transitio... [ntia.gov] 22. Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions, https://www.ianacg.org/icg-files/documents/IANA-transition-proposal-final.pd... [ianacg.org] ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://urldefense.com/v3/__https://mailman.ripe.net/mailman3/lists/ripe-lis... [mailman[.]ripe[.]net] As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://urldefense.com/v3/__https://www.ripe.net/membership/mail/mailman-3-m... [ripe[.]net]
participants (4)
-
Jim Reid -
Leo Vegoda -
Samaneh Tajalizadehkhoob -
William Sylvester