O que mudou
Não é possível determinar o que mudou na política ripencc/2019-02, pois a cronologia verificada está vazia e não foram fornecidas versões, alterações textuais ou marcos processuais.
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-02, pois a cronologia verificada está vazia e não foram fornecidas versões, alterações textuais ou marcos processuais.
Não há base verificável para caracterizar o objeto substantivo do debate. O conjunto fornecido não contém mensagens, argumentos, participantes ou linhas do tempo de posições.
Não há discussão mensurável nesta extração: foram registrados zero mensagens, zero dias ativos, zero participantes de discussão e zero atores formais. Também não há registro de ato decisório; portanto, não é possível declarar adoção, rejeição, retirada, abandono, consenso ou dissenso.
As participações top-1, top-5 e top-10, o HHI e o número efetivo de participantes são todos zero porque a base contém zero mensagens e zero participantes. Esses valores não indicam participação equilibrada ou desconcentrada; indicam apenas ausência de atividade observável sobre a qual calcular concentração.
Nenhum ponto de estrangulamento decisório ou processual pode ser identificado. Sem cronologia, participantes, atores formais, posições ou resultado, não é possível atribuir controle, influência ou poder de veto a qualquer etapa ou identidade.
Exhaustion trigger based on a /22 equivalent · Version 1 starts the waiting list when a single /22 can no longer be allocated. Version 2 instead uses the point at which an equivalent of a /22 can no longer be allocated, while retaining the preceding section's ability to assemble that total from more than one block. This distinguishes exhaustion of a contiguous /22 from exhaustion of the aggregate amount available for an allocation. Both versions then use a /24 waiting-list allocation size.
In case an allocation of a single /22 as per clause 1 can no longer be made, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve waiting list.Fatos com fonte ↗
Once an equivalent of a /22 can no longer be allocated, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-served waiting list.Fatos com fonte ↗
Small-fragment holding rule before the waiting list · Version 2 keeps section 5.1 and adds an explicit rule holding blocks smaller than /24 until missing fragments are recovered. Version 1 instead stops the ordinary allocation phase when a single /22 cannot be supplied; its stated rationale avoids handing an LIR fragmented blocks. The new /24 floor accompanies the move to a /22-equivalent exhaustion trigger. Both drafts separately retain a holding rule for fragments below the allocation size in the waiting-list phase.
To prevent allocating the last /22s from multiple smaller fragments, this proposal starts the waiting list scheme as soon as no contiguous /22 can be allocated anymore. This prevents LIRs from receiving fragmented blocks (which they would need to announce separately in the BGP routing table).Fatos com fonte ↗
Keep existing text of 5.1 and add: All address blocks smaller than a /24 will be held by the RIPE NCC and are declared unallocatable until the missing fragments are received/recovered by the RIPE NCC.Fatos com fonte ↗
Waiting-list assignment confirmation and contiguous block wording · Version 2 omits the separate sentence in version 1's waiting-list section requiring the LIR to confirm that it will make assignments from the allocation. It also explicitly says that, if a single /24 cannot be supplied, allocation waits until contiguous /24s are available again. The omission is specific to this proposed waiting-list wording; it does not demonstrate that all assignment obligations elsewhere in the policy disappear.
Once this allocation limit has been reached or exceeded an LIR can not request any further IPv4 resources under this policy. The LIR must confirm it will make assignment(s) from the allocation. In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous allocations again.Fatos com fonte ↗
If this allocation limit has been reached or exceeded, an LIR cannot request an IPv4 allocation under this policy. In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous /24 allocations again.Fatos com fonte ↗
Narrower declared scope of the second draft · Version 2 explicitly narrows the proposal's stated focus to creating a /24 waiting list after the existing allocation policy can no longer operate, and says the other proposed changes have been removed. Version 1's summary had also described removing the special treatment of the 14 September 2012 date. This is a change in the authors' explanation of scope: version 1's operative text already contained a /22 phase, so its summary should not be read as an immediate /24-only rule.
This policy proposal changes the allocation size to a /24, and because the LIRs that have existed since before 14 September 2012 (the day the main RIPE NCC IPv4 pool ran out) have had plenty of time to request their /22, this policy proposal also removes that "special" date from the policy text and treats all IPv4 allocations equally.Fatos com fonte ↗
Version 2 changes the focus of the proposal, looking only at creating a waiting list based on an allocation size of /24 after the current policy no longer works. All other changes have been removed from this proposal and the proposal name has been changed accordingly.Fatos com fonte ↗
Carregando
Parcial
Primeiro registro: 30 de jun. de 1992
Último registro: 12 de nov. de 2026