O que mudou
Não é possível determinar o que mudou na política ripencc/2019-08, pois a cronologia verificada não contém versões, datas, alterações textuais, etapas processuais ou eventos.
RIPE NCC · Monitoramento de RIR
Comece aqui pelo registro de cada proposta: o que mudou, por que isso foi relevante, quem defendeu cada posição, como as posições evoluíram, o que foi decidido e onde ainda há lacunas nas evidências.
Fatos com fonte
Quem realmente moldou o debate?
Análise BTW
Não é possível determinar o que mudou na política ripencc/2019-08, pois a cronologia verificada não contém versões, datas, alterações textuais, etapas processuais ou eventos.
Não é possível caracterizar o objeto substantivo do debate. Não foram fornecidas mensagens, posições, argumentos, respostas ou transições de posição, e essa insuficiência não demonstra que nenhum debate tenha ocorrido no mundo real.
O conjunto não registra atividade de discussão: são zero mensagens, zero dias ativos, zero participantes de discussão e zero atores formais. Também não contém ato decisório, responsável, data, fundamentação ou status de implementação; portanto, não permite inferir aprovação, rejeição, retirada, abandono ou implementação.
As participações top1, top5 e top10, o HHI, a contagem efetiva de participantes e os núcleos de 50% e 80% são todos zero porque não há mensagens nem participantes registrados. Esses valores indicam ausência de uma distribuição mensurada, e não participação ampla, equilibrada ou desconcentrada.
O único gargalo demonstrável é informacional: a ausência de cronologia, mensagens, autores, posições e ato decisório impede relacionar participação, argumentos e resultado. Não há base para atribuir poder de veto, controle de agenda ou influência decisiva a qualquer participante, ator formal ou instituição.
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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)Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
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.Fatos com fonte ↗
Parcial
Primeiro registro: 30 de jun. de 1992
Último registro: 9 de out. de 2026