What changed
No policy change can be identified because the supplied verified policy chronology is empty and no proposal versions, change log, or implementation record are provided.
RIPE NCC · RIR Watchdog
Start here for the proposal-by-proposal record: what changed, why it mattered, who argued for what, how positions evolved, what was decided, and where the evidence still has gaps.
Source facts
Who actually shaped the debate?
BTW Analysis
No policy change can be identified because the supplied verified policy chronology is empty and no proposal versions, change log, or implementation record are provided.
No substantive debate theme can be established. The verified dataset contains zero messages, zero discussion participants, zero formal actors, no stance timelines, and no recorded arguments.
Neither a formal decision nor an observed discussion is documented. The supplied facts do not establish whether the proposal was accepted, rejected, withdrawn, appealed, implemented, or otherwise resolved; zero participation metrics cannot determine its procedural or substantive disposition.
The top-one, top-five, and top-ten message shares, HHI, effective participant count, and core-group counts are all zero because the observed dataset contains zero messages and zero participants. These values do not demonstrate broad or evenly distributed participation, nor do they demonstrate concentration; there is no nonempty participation distribution to assess.
No participant, coalition, formal actor, or institutional stage can be identified as a policy-process chokepoint from the supplied facts. The immediate analytical chokepoint is the absence of chronology, messages, stance records, formal milestones, and final-disposition evidence, which prevents reconstruction of agenda control, deliberation, consensus formation, or decision authority.
Separate trust anchor for registry-created AS0 ROAs · Version 2 adds a dedicated trust anchor and TAL file for RIPE NCC's AS0 ROAs, so tools and researchers can distinguish registry-created records for unallocated or unassigned space from operational ROAs created by resource holders. Version 1 stated the registry's authority to create these ROAs but did not specify this separate distribution arrangement.
Only the RIPE NCC has the authority to create RPKI ROAs for address space not yet allocated or assigned to its members.Source facts ↗
RIPE NCC creates all its AS0 ROAs under a specific Trust Anchor, and provides a specific Trust Anchor Locator (TAL) file. This way, tools and researchers could benefit from a distinction between operational ROAs created by holders of the address space, and ROAs created by RIPE NCC for unallocated/unassigned address space.Source facts ↗
Revocation wording before an allocation · Version 1 explicitly allowed allocation only after the AS0 ROAs had been fully removed and were no longer visible in repositories. Version 2 retains the requirement to revoke the relevant AS0 ROAs when allocating space, but omits that explicit repository-visibility condition and the word 'beforehand'. Its opposing-arguments section still discusses a delay of at least 24 hours; this comparison does not turn that discussion into an adopted timing rule.
If the RIPE NCC wants to allocate address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked beforehand. Address space can only be allocated once the ROA or ROAs with origin AS0 have been fully removed and are not visible in the repositories.Source facts ↗
If the RIPE NCC wants to allocate address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked.Source facts ↗
Discussion of less-specific announcements · Version 2 adds an explicit limitation: a less-specific covering announcement can circumvent the AS0 ROA protection. The authors argue that a covering route spanning allocated resources would attract monitoring alerts. This is a qualified threat assessment added to the rationale, not a guarantee that monitoring prevents such announcements.
Given the state of today's RPKI infrastructure, there should be a period of at least 24 hours between the revocation of the ROA or ROAs and the notification to the LIR that a given prefix has been allocated to them. This might delay allocations considerably, unless a different procedure can be created.Source facts ↗
The authors note that it is possible to circumvent the protection of the AS0 ROA through the announcement of a less specific covering prefix. However, it is thought that hijackers of unallocated resources are likely to try staying under the radar and by announcing a supernet which by definition also spans an allocated resource, will trigger alarms through the various DFZ monitoring services available (for example as available in the RIPE RPKI Dashboard)Source facts ↗
Registry and validator processing costs · Version 2 adds the possible registry cost and validator processing burden of a large AS0 ROA set. It distinguishes the limited IPv4 pools described in the proposal from the potentially much larger IPv6 set associated with sparse allocation. These are the draft's operational concerns, not measured costs or a forecast that every validator will be overloaded.
This might delay allocations considerably, unless a different procedure can be created.Source facts ↗
Distribution through SLURM assertions · Version 3 replaces the proposed registry-created AS0 ROAs with a downloadable SLURM file containing AS0 assertions for unallocated and unassigned IPv4 and IPv6 space under RIPE NCC administration. It specifies a well-known URL and automated use by relying parties under RFC 8416. Version 2 instead separated the registry's ROAs under a dedicated trust anchor and TAL. This is a proposed distribution change, not evidence that either design was deployed.
RIPE NCC creates all its AS0 ROAs under a specific Trust Anchor, and provides a specific Trust Anchor Locator (TAL) file. This way, tools and researchers could benefit from a distinction between operational ROAs created by holders of the address space, and ROAs created by RIPE NCC for unallocated/unassigned address space.Source facts ↗
The RIPE NCC will create a SLURM file containing assertions with origin AS0 for all the unallocated and unassigned address space (IPv4 and IPv6) for which it is the current administrator. The file will be available for download from a well-known URL published by the RIPE NCC, so that Relying Parties (the so-called Validators) will be able to, in an automated way, fetch them and make use of them as described in RFC 8416.Source facts ↗
Relying-party choice and configuration · Version 3 explicitly makes use of the file a relying-party choice: a configuration directive can enable or disable processing, and users can incorporate the assertions or leave them out. The rationale also suggests CDN distribution and frequent updates. Version 2 described a separate TAL for distinguishing registry ROAs; it did not include this SLURM-specific configuration and distribution explanation. The proposal's claim of equivalent information does not mean all networks would choose identical validation policy.
This way, tools and researchers could benefit from a distinction between operational ROAs created by holders of the address space, and ROAs created by RIPE NCC for unallocated/unassigned address space.Source facts ↗
Creating and publishing a SLURM file gives users the chance to decide if they want to use the information or not for their networks. Relying Parties can decide to incorporate all the assertions from this file, or they can be left out. The SLURM file could be distributed using a CDN, and it should be frequently updated to reflect the status of the unallocated and unassigned address space held by RIPE NCC.Source facts ↗
Updating protection when resources are allocated · Version 3 requires the relevant AS0 entry in the SLURM file to be updated at the time space is allocated to a member. This replaces Version 2's requirement to revoke the relevant AS0 ROAs. The earlier opposing-arguments discussion of waiting at least 24 hours between revocation and notification is absent from Version 3; the new text does not establish how quickly every relying party will retrieve an update.
If the RIPE NCC wants to allocate address space to one of its members, the RPKI ROA or ROAs with origin AS0 will have to be revoked.Source facts ↗
The RIPE NCC will update the relevant entry in the SLURM file with origin AS0 at the time of allocating address space to one of its members.Source facts ↗
Cost concern shifts to relying-party memory · Version 2 discusses RIPE NCC's operational cost and validator processing time for many ROAs. Version 3 reframes this concern around relying-party software needing more memory to process many assertions. The IPv4-versus-IPv6 distinction remains: the draft expects a relatively limited IPv4 set and a considerable IPv6 set because of sparse allocation. Neither version supplies a measured capacity benchmark.
The addition of potentially a large number of ROAs covering all the unassigned and unallocated space might increase the operational costs for the RIPE NCC. It might also have an impact on the time needed by validators to process the data.Source facts ↗
The addition of potentially a large number of assertions covering all the unassigned and unallocated space might increase the operational costs for the Relying Party software by requiring them to run using more memory needed to process all the data.Source facts ↗
Partial
Earliest captured: Jun 30, 1992
Latest captured: Oct 11, 2026