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