Colleagues, Ahead of tomorrow's session, I wanted to provide the community with advanced notice regarding the upcoming publication of Policy Version 2.0 and a summary of its further revised architectural direction (separate from the core policy document). As some of you noted during the initial review of Version 1.0, relying exclusively on RPKI management freezes introduced structural routing loopholes. So version 1.0 of the implementation logic Support Document has been completely deprecated. I also previously considered route injection on its own, but that approach has also been shelved. Moving quickly through these technical iterations is part of the process. I want to emphasize that these major structural changes apply mostly to the technical Support Document—offering suggestions on how to implement this policy effectively—and do not alter the core of the policy proposal document itself. Version 2.0 now shifts entirely to a highly targeted approach. By combining simultaneous RPKI AS0 injections, traditional IRR route object locks, and Reverse DNS name server nullifications, Version 2.0 ensures that only specific, verified malicious infrastructure is isolated at the global Tier-1 boundary. Adjacent, legitimate downstream customer networks sharing the same aggregate block should remain unaffected and secure. Key Principles of the Version 2.0 Framework: 1. Zero RIPE NCC Investigative Burden: The RIPE NCC acts strictly as a deterministic data clerk, entirely insulated from making content evaluations or subjective judgments. The framework is driven mechanically by explicit subject-line keywords within the existing RIPE ticketing infrastructure. 2. Objective, Publicly Verifiable Triggers: Workflows are initiated exclusively by authenticated IRT entities. The submission requires a mandatory, direct URL pointing to an approved blocklist’s public historical archive, proving a 14-day infraction. Nobody is inventing evidence; the data is public and auditable by anyone at any time. 3. Safeguards and Timelines: To protect legitimate operators from false positives or active blocklist removal disputes, the policy introduces a 72-hour flapping escrow window, extendable to a hard 7-day ceiling upon verification of an active blocklist dispute. Persistent violators who fail these windows face automated data locks, and systemic evasion may trigger standard LIR closure. That has to be considered if an LIR provides bulletproof hosting services multiple times. 4. Investigator Anonymity: All communication occurs through an automated proxy script within the RIPE ticketing system, sanitizing metadata and utilizing randomized case hashes to protect threat investigators from digital or physical retaliation by criminal networks. The core philosophy of Version 2.0 is not about turning the RIPE NCC into the internet police. It is about providing the community with the automated tools necessary to ensure that the registry’s own data and cryptographic signatures are not weaponized to harbor bulletproof hosting environments. As I am unable to be at the microphone live tomorrow due to a medical appointment, I have submitted a brief, 7-minute recorded video presentation to introduce this framework and kick off the discussion in the room. I look forward to reviewing your feedback from the floor and collaborating on the mailing list to refine the final routing mechanics. cheers, Denis Walker Retired RIPE Database Senior Analyst and Engineer