Resumo

  • AFPUB-2026-IPv4-003-DRAFT01 transforma procedência histórica em uma regra operacional. Todo espaço recuperado passaria primeiro pelo Recovered Pool; a categoria do pool de origem determinaria o destino posterior, enquanto a incerteza levaria, por padrão, ao Pre-Softlanding Pool.

  • A classificação pode mudar saldos e, por consequência, influenciar quais pedidos cabem no Pre-Softlanding Pool, quando ocorre o adiamento automático ao Soft-Landing Pool, quando uma futura lista de espera seria acionada e quais delegações receberiam restrição temporária de transferência.

  • O objeto probatório mínimo é um recibo público de classificação. Ele deve identificar o evento, resumir as provas sem expor dados protegidos, registrar o grau de certeza, mostrar o destino e conciliar os saldos anterior e posterior de cada pool afetado.

  • A proposta está Under Discussion. Não há prova de consenso, ratificação, implementação, inventário operacional com quatro pools, bloco efetivamente classificado, pedido adiado, lista ativa, delegação, transferência ou disputa de procedência.

Um trânsito administrativo em duas etapas

A proposta define espaço recuperado como IPv4 devolvido, revogado, reclamado ou recuperado de outro modo pela AFRINIC. Esse espaço não seguiria diretamente para uso posterior. A Regra 1 o enviaria primeiro ao Recovered Pool, uma área administrativa inicial antes da classificação.

Depois viria a decisão que interessa. A equipe rastrearia a categoria do pool de origem e devolveria o bloco a essa categoria. A proposta distingue Soft-Landing Pool, Policy-Reserved Pool, Pre-Softlanding Pool e Recovered Pool.

Se a origem não pudesse ser determinada com certeza razoável, o destino padrão seria o Pre-Softlanding Pool. Para blocos parciais, a classificação seria proporcional à origem rastreável. O evento teria de ser documentado e anunciado.

Esse desenho cria dois movimentos que precisam fechar. Primeiro, o bloco entra no Recovered Pool. Depois, sai dele para o pool classificado. Em um bloco parcial, a segunda etapa pode ter várias linhas, cuja soma deve corresponder exatamente ao espaço recuperado.

Uma proposta, não um estoque já operante

A página de propostas atuais identifica AFPUB-2026-IPv4-003-DRAFT01, Dynamic IPv4 Pools Exhaustion Management Framework, como Under Discussion. O texto da proposta a apresenta como versão 1.0, submetida em 8 de junho de 2026.

O texto alteraria a seção 5.4 do CPM. Nada nas duas fontes demonstra consenso, ratificação ou implementação. Também não prova a existência de saldos reais separados nesses quatro pools sob a arquitetura proposta.

Por isso, todos os efeitos devem permanecer condicionais. O artigo testa o que precisaria ser publicamente demonstrável caso a política avançasse. Não descreve uma classificação que já ocorreu nem atribui falha, manipulação ou erro à AFRINIC.

Quando procedência vira destino

A categoria de origem não funciona aqui como simples nota histórica. Ela atua como chave de roteamento de estoque. O bloco recuperado volta ao pool de onde, segundo a prova rastreável, veio.

Essa categoria é administrativa. Ela não deve ser tratada como título jurídico sobre o espaço, nem como declaração geral sobre propriedade. Sua função proposta é determinar em qual saldo o bloco reaparece e sob qual caminho poderá ser considerado depois.

O padrão de incerteza também tem efeito material. Quando a origem não pode ser determinada com certeza razoável, o espaço não fica sem destino. Ele é encaminhado ao Pre-Softlanding Pool.

Um padrão é útil porque evita paralisia. Mas ele só é auditável se o leitor puder reproduzir a passagem da prova à conclusão: quais registros foram considerados, que lacuna permaneceu, qual teste de certeza foi aplicado e quem autorizou o destino.

Sem esse rastro, “origem incerta” pode ser uma conclusão correta e ainda assim impossível de verificar. A questão não é presumir má-fé. Linhagem incompleta, nomenclatura antiga, agregação e recuperação parcial bastam para produzir incerteza legítima.

Por que o saldo importa

Cada pool seria acompanhado separadamente, e seus movimentos teriam de ser auditáveis e publicamente reportáveis. Portanto, uma classificação não é apenas uma etiqueta anexada ao prefixo. Ela altera dois ou mais saldos.

O Pre-Softlanding Pool teria máximo normal /18, mínimo /24, justificativa de 12 meses e demonstração de 80% de uso anterior. Uma delegação de até /16 seria possível mediante provas adicionais.

Se um pedido não pudesse ser atendido pelo Pre-Softlanding Pool, ele seria automaticamente adiado para o Soft-Landing Pool, com registro do adiamento e aviso ao solicitante.

Assim, um bloco classificado para um pool, e não para outro, pode influenciar a capacidade disponível e o momento em que um pedido deixa de caber. O recibo não precisa prever esse efeito, mas deve permitir que ele seja calculado a partir dos saldos.

Quando os dois pools principais chegassem a zero, as delegações passariam a uma lista de espera pós-esgotamento alimentada apenas pelo Recovered Pool. A data desse gatilho dependeria dos saldos e dos movimentos registrados.

A proposta também aplicaria 24 meses sem transferência voluntária às delegações do Pre-Softlanding Pool e da futura lista, salvo fusões, aquisições e incorporações. A procedência pode, portanto, influenciar o caminho que leva a uma restrição posterior.

Nenhum desses efeitos está comprovado na prática. O ponto é estrutural: quando uma classificação alimenta o saldo que condiciona atendimento, adiamento, fila ou restrição, a prova da classificação passa a integrar a prova do resultado posterior.

Certeza razoável precisa deixar vestígio

A expressão “certeza razoável” dá espaço para julgamento técnico. Isso pode ser necessário, porque registros históricos raramente oferecem a mesma qualidade de prova em todos os casos.

O espaço de julgamento, porém, aumenta a necessidade de um recibo. A publicação não precisa expor documentos confidenciais, contatos ou detalhes operacionais. Precisa revelar classes de prova, datas, coerência entre elas e a razão da conclusão.

Uma referência de delegação anterior pode mostrar o vínculo histórico sem reproduzir o arquivo inteiro. Datas de registros, atos de devolução ou revogação e relações entre prefixos podem ser descritas em forma resumida.

O recibo também deve distinguir ausência de prova de prova contraditória. No primeiro caso, a linhagem termina antes da categoria. No segundo, fontes diferentes apontam para origens diferentes. Ambas podem levar à incerteza, mas não são o mesmo problema.

A certeza deve ser vinculada à decisão, não apenas ao bloco. Se uma correção posterior mudar a origem, o registro original precisa continuar visível, acompanhado da nova autoridade, da nova prova e da reversão contábil correspondente.

O problema especial dos blocos parciais

A regra proporcional evita que um agregado inteiro receba uma única origem quando apenas parte dela é rastreável. Esse é um ganho de precisão, mas também aumenta a superfície de prova.

Um recibo de bloco parcial deve mostrar o cruzamento entre prefixos ou faixas recuperadas e as categorias atribuídas. A soma das quantidades classificadas precisa igualar a quantidade total do evento de recuperação.

Se uma parte for rastreável e outra permanecer incerta, cada fração deve ter destino próprio. A fração incerta seguiria o padrão do Pre-Softlanding Pool; a rastreável retornaria à categoria demonstrada.

Não basta informar percentuais soltos. O leitor deve conseguir verificar como cada percentual corresponde a subprefixos ou intervalos e por que não há lacuna, sobreposição ou dupla contagem.

A fragmentação também precisa aparecer nos saldos. Uma única entrada no Recovered Pool pode gerar várias saídas. O anúncio público deve conservar a relação entre o evento-mãe e cada linha resultante.

Um recibo público de classificação

O recibo abaixo não presume adoção de formato específico. Ele testa quais campos mínimos tornariam o evento reproduzível, conciliável e corrigível sem publicar material protegido.

Campo do recibo Conteúdo público mínimo Teste que permite
Versão e status AFPUB-2026-IPv4-003-DRAFT01, versão aplicável e condição da regra Distinguir proposta, regra ratificada e texto posteriormente alterado
Evento e hora da recuperação Identificador público, data, hora e tipo geral de recuperação Fixar quando o espaço entrou no Recovered Pool
Prefixo e quantidade Prefixo, subprefixos ou faixas e total de endereços Impedir lacunas, sobreposição e dupla contagem
Referência anterior Referência pública ou protegida à delegação precedente Sustentar a linhagem sem expor o dossiê completo
Categoria de origem Soft-Landing Pool, Policy-Reserved Pool, Pre-Softlanding Pool ou origem não determinada Mostrar qual regra de destino foi aplicada
Classes e datas das provas Tipos de registros examinados e respectivas datas Avaliar atualidade, convergência e lacunas
Certeza e motivo Conclusão, grau ou categoria de certeza e justificativa curta Reproduzir o uso do padrão de certeza razoável
Cruzamento parcial Relação entre cada subprefixo ou faixa e sua origem Verificar a classificação proporcional
Destino Pool que recebeu cada parcela depois da classificação Ligar procedência ao saldo alterado
Autoridade e hora Unidade decisora, data e hora da classificação Separar análise, autorização e anúncio
Anúncio público Referência ao aviso da classificação Confirmar que o evento foi publicamente reportado
Saldos antes e depois Saldo anterior, movimento e saldo posterior de cada pool Conciliar entrada, saída e destino
Restrição posterior Marcador de eventual regime de 24 meses aplicável à delegação futura Explicar a origem de uma condição posterior
Contestação e correções Estado da contestação, decisão, versão anterior e nova conciliação Corrigir sem apagar a história

O campo de versão é indispensável porque a proposta está em discussão. Um recibo futuro precisaria apontar para a regra efetivamente vigente, não apenas repetir o identificador do primeiro rascunho.

O campo de restrição posterior não deve afirmar que houve transferência. Ele apenas preservaria a relação entre o pool de delegação e uma condição que a proposta pretende aplicar durante 24 meses.

Conciliação, não apenas anúncio

A proposta exige que a classificação seja documentada e anunciada. Um anúncio é necessário, mas pode ser insuficiente se informar somente o prefixo e o destino.

A prova pública precisa fechar os movimentos. O saldo do Recovered Pool aumenta na recuperação e diminui na classificação. O saldo do destino aumenta na mesma quantidade, salvo a decomposição explícita de um bloco parcial.

Esse fechamento permite testar relatórios mensais. A proposta prevê tamanho da fila, endereços disponíveis, espera média e espaço recuperado processado. As somas dos recibos deveriam explicar a variação dos agregados.

Relatório agregado e recibo de evento cumprem funções diferentes. O primeiro mostra escala e tendência. O segundo permite reconstruir por que um saldo mudou e qual decisão administrativa produziu essa mudança.

Sem conciliação, um total mensal pode estar correto e ainda não demonstrar a procedência dos blocos que o compõem. Sem relatório agregado, recibos isolados não mostram efeito acumulado sobre estoque e fila.

Correção sem reescrever o passado

Uma classificação pode ser contestada ou corrigida sem que isso implique erro culposo. Nova prova pode surgir, uma referência antiga pode ser esclarecida ou um limite de prefixo pode ser revisto.

A correção deve acrescentar um novo evento, não substituir silenciosamente o anterior. O novo registro precisa apontar o predecessor, explicar a razão e reverter os saldos antes de aplicar o novo destino.

Se o bloco já tiver influenciado atendimento ou adiamento, o registro deve indicar o alcance da correção. Isso não significa desfazer automaticamente decisões posteriores; significa tornar visível quais efeitos dependiam da classificação alterada.

Um mecanismo de recurso, caso seja criado, precisa separar quem contesta, quem decide e qual padrão de revisão se aplica. O recibo deve mostrar o estado do recurso sem divulgar informações protegidas.

Estimativa não substitui inventário

As estimativas de vida dos pools, volume recuperado e pedidos sucessivos são alegações dos autores da proposta. As páginas fornecidas não incluem conjunto de dados nem planilha de cálculo que permita reproduzi-las.

Essas estimativas podem integrar a avaliação da proposta, mas não comprovam saldos, classificações ou efeitos operacionais. A vida de um pool depende de entradas, saídas, tamanho de pedidos e regras aplicadas.

O recibo trata de outro objeto. Ele não tenta prever quanto tempo o estoque durará. Mostra por que determinado espaço foi para determinado pool e como o movimento alterou os saldos.

Essa separação protege o debate. Uma estimativa pode ser revisada sem mudar a procedência de um bloco. Uma classificação pode ser corrigida sem validar ou invalidar toda projeção de esgotamento.

O limite correto da conclusão

Nenhuma fonte prova que a AFRINIC já opere o Recovered Pool proposto, classifique blocos pela nova regra ou mantenha uma lista de espera decorrente dela.

Também não há prova de saldo real, adiamento real, restrição aplicada, transferência, manipulação ou disputa. A análise não atribui essas ocorrências nem presume resultado do processo de políticas.

A conclusão é condicional e estreita. Se a procedência histórica decidir o pool de destino, o evento de classificação precisará de prova pública suficiente para ser reproduzido e conciliado.

Esse recibo deve proteger privacidade sem transformar o motivo em caixa-preta. Deve mostrar o que entrou, o que foi examinado, o que se concluiu, quem autorizou, para onde o espaço foi e como os saldos fecharam.

Na proposta, a procedência não encerra uma discussão histórica. Ela abre um caminho operacional capaz de afetar estoque, ordem, adiamento, fila e restrição posterior. Por isso, o recibo precisa existir antes que o destino produza consequências difíceis de desfazer.

Fontes