- ripe-list - mailman.ripe.net

RIPE92 Call for Presentations now open!
by Massimiliano Stucchi 18 Dec '25

18 Dec '25

Dear colleagues, The RIPE Programme Committee (PC) is now seeking content proposals for plenary presentations, lighting talks, tutorials and BoFs at RIPE 92. This meeting will take place in Edinburgh, UK, from 18th to 22nd May 2026. RIPE92 will be a hybrid meeting, so both in-person and remote presentations are encouraged and will be accepted. The deadline to submit a presentation proposal is 9th of March 2026. Proposals submitted after this date will only be considered if there are still time slots available. You can read more about the CfP and submit your proposal at: https://pretalx.ripe.net/ripe-92/cfp More about the RIPE92 Meeting: https://ripe92.ripe.net/ Kind regards, Max Stucchi (On Behalf of the RIPE Programme Committee) -- Massimiliano Stucchi MS16801-RIPE https://stucchi.ch

1 0

The RIPE Chair Team Reports - December 2025
by Mirjam Kuehne 18 Dec '25

18 Dec '25

Dear colleagues, In this last report for 2025, we talk about some follow-ups from RIPE 91 and look forward to RIPE 92. You can also find updates on a number of RIPE documents and other community programmes and initiatives: https://labs.ripe.net/author/mirjam_kuhne/the-ripe-chair-team-reports-decem… Season's Greeting, Mirjam Kühne and Anna Wilson RIPE Chair Team

1 0

Anyone know Thomas Robinson?
by Johan Helsingius 15 Dec '25

15 Dec '25

https://britpanorama.co.uk/editors-picks/russias-hidden-leverage-over-europ…

7 9

New Draft RIPE Programme Committee Charter for your Review
by Mirjam Kuehne 15 Dec '25

15 Dec '25

Dear colleagues, We made some small changes to the RIPE Programme Committee Charter (currently ripe-829): In section 3. Composition and Roles, we added the option to have a representative from the regional community in Central Asia (CAPIF) on the RIPE PC (similar to the representatives from MENOG and SEE). At the same time, we added "RIPE" in front of WG Chairs and we added links to CAPIF, SEE and MENOG (all in section3). You can find the new draft version here: https://www.ripe.net/publications/docs/ripe-documents/other-documents/draft… Please let me know, if you have any comments or questions. The deadline for comments is 19 January 2026. Kind regards, Mirjam Kühne RIPE NCC

1 0

Request for Participation in International Survey on Network Engineering Workforce Development
by MAEMURA Akinori 05 Dec '25

05 Dec '25

Dear RIPE colleagues, # Forwarding this survey to relevant colleagues or organizations in your country is very welcome and greatly appreciated. I hope this message finds you well. The Japan Network Information Center (JPNIC) and the Ministry of Internal Affairs and Communications (MIC) of Japan are conducting a joint research initiative on the development and retention of network engineering talent. As part of this effort, we are gathering insights from global stakeholders. [Reference] Launch of a Research Study on Securing and Developing Network Engineering Talent, and Request for Cooperation https://www.nic.ad.jp/en/topics/2025/20251205-01.html Japan faces several challenges including regional disparities, shortages of skilled personnel among smaller operators, and gaps in structured training and career development pathways. To inform effective policy development, we seek to learn from your country’s experiences, practices, and ideas. We would be sincerely grateful if you could participate in our international survey on the current status, challenges, and policy approaches related to network engineer development. We plan to share preliminary findings at future forums, and your input will play a meaningful role in shaping this work. The survey can be accessed at the following link: https://www.surveymonkey.com/r/japan-hrd2025 ・Estimated time required: 10-15 minutes ・Survey deadline: December 18 ・Responses will be kept confidential, anonymized during analysis, and used solely for research purposes. ・Any personal information (if provided) will be used only for follow-up communication related to this study. Your expertise and perspectives would be extremely valuable to us. If appropriate, please feel free to forward this invitation to others who may offer relevant insights. Should you have any questions, please do not hesitate to contact us. Thank you very much for your time and cooperation. Best regards, MAEMURA Akinori maem(a)nic.ad.jp Japan Network Information Center (JPNIC) -- MAEMURA Akinori / 前村昌紀 maem(a)nic.ad.jp JPNIC - Japan Network Information Center

1 0

ten years
by Randy Bush 02 Dec '25

02 Dec '25

rob has been gone for ten years. does not seem that long. sigh. randy

2 2

anycast community
by Randy Bush 27 Nov '25

27 Nov '25

i thought i remembered discussion of a community tag for anycast prefixes. anyone have specific reference? randy

12 20

BGP Lab Testing and Peering Guidance – AS205941
by Lungu Stefan-Gabriel 27 Nov '25

27 Nov '25

Hello RIPE community, My name is Stefan Lungu, I am 14 years old. I currently hold ASN AS205941 and have experience with BGP basics using BIRD (bird2). I am planning to test BGP scenarios similar to provider setups, including prefix filtering, and peering policies. I apologize if this kind of message is not appropriate for this mailing list. I am just looking for opportunities to learn more. I would greatly appreciate any guidance or feedback on best practices for safely experimenting with BGP using a public ASN in a controlled lab environment. For further details or private discussions, please feel free to contact me at hi (at) lungustefan (dot) com so as not to disturb the whole mailing list. Thank you for your time. Best regards, Lungu Ștefan-Gabriel.

1 0

RIPE 91 Community Plenary Minutes
by Mirjam Kuehne 27 Nov '25

27 Nov '25

Dear colleagues, The draft minutes of the RIPE 91 Community Plenary are online: https://www.ripe.net/community/ripe-governance/ripe-community-plenary/minut… Please let me know if you have any comments or corrections. Kind regards, Mirjam Kühne RIPE Chair

1 0

Feedback on the Version 2 (DRAFT) RIR Governance Document
by William Sylvester 10 Nov '25

10 Nov '25

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/em… 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-ic… 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-… 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-… 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-… 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/seizi… 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/em… 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-int… 21. Fact Sheet: The IANA Stewardship Transition Explained, https://www.ntia.gov/other-publication/fact-sheet-iana-stewardship-transiti… 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.p…

3 4