Dear Colleagues,
Ahead of RIPE 93 and the Security WG session on Tuesday, I wanted to share an important update regarding Proposal 2026-02 ("Contractual Accountability Framework for Infrastructure-Level Network Abuse").
I want to sincerely apologise to all of you for dropping this in your laps so close to the meeting. This is not some kind of tactical move. I have literally been working through the night for the last two days (when I am supposed to be resting) to finalise this dramatic change.
Following feedback on the initial draft, the administrative restriction mechanics in the proposal have completely changed: I have pivoted entirely away from RPKI and moved to Internet Routing Registry (IRR) Database Object Management.
I have formally submitted Version 2.0 of the proposal and the updated Support Document to the Policy Development Officer (PDO) and the Working Group Chairs tonight. I hope that Version 2.0 can somehow be made available to the list or referenced during Tuesday's session, even if everyone accepts it as a pre-reviewed draft ahead of formal post-meeting publishing.
100% RPKI-Agnostic & Universal: Version 1.0 encountered technical friction regarding Hosted vs. Delegated RPKI. Version 2.0 completely bypasses RPKI. Restrictions are executed strictly by programmatically modifying or injecting exact-match route/route6 IRR objects assigned to a designated Quarantine ASN (origin: AS65535) locked under an authoritative maintainer (mnt-by: RIPE-ABUSE-MNT).
Automated Global Isolation: Tier-1/Tier-2 transit providers run automated daily toolsets (e.g., bgpq4) that parse IRR route objects. Placing origin: AS65535 on the specific abusive prefix causes global transit filters to drop ingress traffic for the targeted criminal infrastructure automatically, while leaving the member's main allocation, operational ASN, and innocent adjacent customers 100% untouched.
High-Level Governance in Policy Text: Article 3.6 of the main policy proposal grants the RIPE NCC high-level authority to perform required database object modifications, keeping specific BGP/IRR syntax housed cleanly inside Section 3 of the separate Support Document.
I appreciate your understanding, and I hope this dramatic improvement gives the Working Group a clear, viable path forward during Tuesday's discussions.
cheers,
Denis Walker
Retired RIPE Database Senior Analyst/Engineer