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.
Detail obligations:
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).
Decision-making Fixes:
Structural gaps:
Honor the spirit and keep IANA transition promises:
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).
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/emergency-back-end-registry-operator
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-icann-seeks-back-up-registry-operators--emergency-back-end-registry-operators-or-eberos-14-9-2011-en
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-nro/
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-supporting-organization-mou-november-2019/
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-of-understanding/
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-ncc-and-state-of-the-netherlands/
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-of-the-right-to-registration-of-ipv4-addresses-for-the-recovery-of-money/
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/seizing-ip-addresses-in-the-netherlands
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/emergency-back-end-registry-operator/gtld-registry-continuity
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-the-emergency-back-end-registry-operator-program-12-07-2024-en
21. Fact
Sheet: The IANA Stewardship Transition Explained, https://www.ntia.gov/other-publication/fact-sheet-iana-stewardship-transition-explained
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.pdf