O que mudou
Nenhuma mudança na política pode ser estabelecida a partir dos fatos verificados. A cronologia está vazia e não há versões, datas, alterações materiais ou ligações entre debate e texto que permitam reconstruir uma evolução.
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
Nenhuma mudança na política pode ser estabelecida a partir dos fatos verificados. A cronologia está vazia e não há versões, datas, alterações materiais ou ligações entre debate e texto que permitam reconstruir uma evolução.
Não é possível determinar o objeto substantivo do debate. A base não contém mensagens, argumentos, posições, participantes ou incentivos verificáveis; atribuir uma controvérsia central, interesses ou motivações extrapolaria os fatos fornecidos.
Não há discussão observável nem decisão verificável. As contagens de zero mensagens, zero participantes e zero atores formais não demonstram adoção, rejeição, retirada, abandono ou ausência de consenso. Também não há votos, declaração de consenso, decisão de presidência ou outro registro formal que estabeleça um resultado.
As métricas de concentração iguais a zero não indicam participação dispersa ou equilibrada, pois foram calculadas sobre zero mensagens e zero participantes. HHI, parcelas dos participantes mais ativos, contagem efetiva e núcleos de 50% e 80% são não informativos neste conjunto; não é possível avaliar domínio, pluralidade, retenção ou continuidade de participação.
Não é possível identificar um ponto de estrangulamento decisório ou deliberativo. A base verificada não contém mensagens, participantes, atores formais, cronologia, posições ou registros de decisão; portanto, não permite localizar quem controlou agenda, redação, consenso ou encerramento. O principal limite analítico é a ausência desses dados, sem que seja possível distinguir ausência real de atividade de ausência de registros na revisão examinada.
Larger replacement assignment for an IXP · Version 2 raises the proposed maximum replacement assignment from /23 to /22 when an IXP outgrows its default /24. The IXP must still return its current assignment, or existing PI space used for the peering LAN, and meet the stated 50% utilisation condition after one year unless special circumstances apply. The change enlarges the proposed growth allowance; it does not turn every existing IXP assignment into a /22.
New IXPs will be assigned a /24 by default. Should they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement /23. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined.Fatos com fonte ↗
New IXPs will be assigned a /24 by default. Once they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement up to maximum of a /22. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined.Fatos com fonte ↗
Availability threshold for smaller IXP assignments · Both drafts allow assignments down to /27 on request. Version 2 changes the alternative availability trigger from depletion of the reserved pool to the absence of available /24-or-larger assignments. This explicitly allows the smaller-block path when the pool still contains fragments but cannot supply a /24; the /27 option itself is not new in this version.
On request or upon depletion of the reserved pool, assignments down to a /27 can be made.Fatos com fonte ↗
On request or once there are no more assignments of /24 (or larger) available, assignments can be made down to /27.Fatos com fonte ↗
Routing returned addresses and small fragments into pools · Version 1 says that IPv4 space returned by IXPs goes to the reserved IXP pool. Version 2 adds a more specific recovery rule: space originally assigned by RIPE NCC exclusively for IXPs returns to that pool; other returned blocks of /24 or larger follow section 5.1, while smaller blocks enter the IXP reserve. This distinguishes the original purpose and size of a returned block rather than treating every return from an IXP identically.
Any IPv4 space returned by IXPs will be added to the reserved pool maintained for IXP use. Any assignments made previously from this pool will remain unchanged.Fatos com fonte ↗
Any IPv4 address space that was originally assigned by the RIPE NCC for exclusive use by Internet Exchange Points (IXPs) will be added to the reserved IXP pool upon return. Other address space blocks of a /24 or larger that are returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1 – smaller blocks will be put into the reserved pool for IXP use.Fatos com fonte ↗
Carregando
Parcial
Primeiro registro: 30 de jun. de 1992
Último registro: 12 de nov. de 2026