Resumo

  • O relatório de experiência da AFRINIC de 2018 registrou um caso concreto: um End User anônimo não poderia receber um /24 adicional para o segundo data center redundante porque o uso agregado permanecia abaixo de 90%.
  • O AFPUB-2026-IPv4-002-DRAFT02, hoje em Last Call, permitiria afastar o limite para uma finalidade técnica demonstrada que os recursos atuais não consigam atender na prática. Porém, a regra comum exige apenas uma justificativa suficientemente documentada, e a discussão rejeitou uma lista única de documentos.
  • Flexibilidade não exige uma decisão invisível. Um recibo protegido e versionado pode guardar o cálculo normal, a classe de exceção, a custódia das provas, as perguntas, os códigos de motivo e o recurso, sem decidir a arquitetura pelo operador.

O problema já estava na mesa dos Hostmasters

A primeira prova desta matéria não foi produzida para defender o Draft 2. Ela está no Policy Implementation Experience Report apresentado na AFRINIC-29, em 2018.

O slide descreve uma solicitação de um membro End User. Ele queria um /24 IPv4 adicional para redundância de data center. A soma do uso atual era inferior a 90%. Pela interpretação de Soft Landing aplicada pela AFRINIC, o membro não podia receber mais recursos e, assim, não conseguiria montar o segundo data center.

O registro é anônimo e curto. Não informa país, data do ticket, prefixo original, separação de energia, rotas, alternativas avaliadas, recurso ou resultado posterior. Também não prova que todo segundo site mereça um /24 novo.

Ele demonstra algo mais limitado: o estado de utilização e a necessidade de simultaneidade não são a mesma variável. A primeira mede endereços já entregues. A segunda exige que o outro domínio de falha esteja funcionando antes que o primeiro falhe. Uma regra sequencial pode conservar o pool e, ainda assim, impedir a própria redundância que precisa analisar.

A exceção continua sendo uma proposta

O rastreador independente da NOG Alliance indexa AFPUB-2026-IPv4-002-DRAFT02 sob o rótulo mais amplo Under discussion. A gravação da AFRINIC-37 registra rough consensus e o envio para Last Call. A primeira versão foi enviada em 6 de maio de 2026; a segunda data de 16 de junho e foi apresentada em 24 de junho. Em 23 de agosto, ainda é proposta, não exceção implementada.

O limite comum permaneceria. Durante a Exhaustion Phase, um LIR ou End User que pedir outra allocation ou assignment IPv4 deve demonstrar pelo menos 90% de utilização de todos os recursos IPv4 anteriores. Uma entidade nova, sem alocação ou designação anterior, continua isenta no primeiro pedido.

O Draft 2 criaria a possibilidade de waiver. Uma finalidade técnica importante e demonstrada poderia afastar o limite quando não fosse possível atendê-la de modo prático com o pool existente ou quando ela gerasse uma restrição técnica nesse pool. Redundância, alta disponibilidade, mecanismos de transição IPv6 e expansão para novos sites são exemplos não exaustivos. Para essa disposição, o pedido seria tratado como primeira allocation ou assignment.

Toda a interface pública de prova termina na última frase: a justificativa precisa estar suficientemente documentada para que a AFRINIC verifique a conformidade com ela.

Isso impede que alta disponibilidade seja aceito como senha automática. O requerente tem de apresentar fatos, e a AFRINIC deve verificá-los. O texto não identifica, entretanto, quais fatos mínimos permanecem no registro nem qual relação um segundo avaliador deve refazer.

Há um número para a regra normal e nenhum tipo para a exceção

O Consolidated Policy Manual atual se identifica como versão 1.6. Além do limite de 90%, ele admite planos de engenharia, subnetting, topologia e roteamento e exige previsões realistas e justificáveis. Também determina aplicação justa sem discriminação por local, nacionalidade ou porte e protege informação comercial que serve à avaliação, mas não precisa constar do registro público.

Existe, portanto, uma base para avaliação profissional e para sigilo. O que falta é tipar a exceção nova.

Imagine dois pedidos com o mesmo percentual. Uma empresa quer outra cidade porque um contrato comercial prefere essa localização. Outra precisa separar energia, trânsito e tradução para que uma falha não derrube as duas funções. Ambas podem escrever redundância. Só a ligação entre a função, o espaço existente e o bloco solicitado mostra se a restrição é técnica ou apenas operacional.

Campos comuns não substituem a perícia do Hostmaster. Eles preservam a matéria sobre a qual a perícia decidiu. Essa diferença permite flexibilidade sem criar precedente privado.

Não ter uma lista universal não significa não ter uma interface comum

A gravação da AFRINIC-37 registra a pergunta central: quais documentos técnicos um membro apresentaria para obter recursos para sites diferentes antes de alcançar 90%? O autor respondeu que não deveria existir uma lista única, pois uma transição IPv6 e uma implantação multissite precisam de provas diferentes. O processo seria um diálogo de entrada e saída com a equipe.

A resposta reconhece a realidade. Um diagrama de data center pode não dimensionar um pool de tradução. Uma ordem de compra não comprova independência entre domínios de falha. Uma previsão de tráfego não mostra, sozinha, a separação de rotas.

Outro participante apoiou a proposta, mas advertiu que a linguagem ampla permitiria a qualquer membro alegar redundância ou alta disponibilidade e dificultaria um tratamento justo. O autor recusou um catálogo de todos os exemplos porque ele excluiria casos legítimos e microgerenciaria a equipe. O Head of Member Services marcou a fronteira que importa: technical constraints podem justificar o waiver; operational constraints não.

A reunião excluiu dois extremos. Um dossiê universal seria rígido. Um adjetivo sem estrutura seria difícil de auditar. Ainda falta a camada intermediária: nomes de campo comuns, preenchidos com provas específicas de cada desenho.

Os cochairs declararam rough consensus na reunião e mandaram o texto para Last Call. A gravação diz também que o Secretariado compartilharia uma definição de utilização nessa etapa. O rastreador neutro mantém o rótulo mais amplo, e nenhuma fonte pública usada aqui comprova ratificação, implementação ou schema de exceção por campos. Isso não demonstra que nenhuma definição circulou em outro lugar; delimita o que proposta e reunião não permitem reconstruir.

A salvaguarda foi colocada dentro do ticket

A apresentação e discussão da proposta colocam a proteção na expressão “suficientemente documentada”. O requerente teria de demonstrar a finalidade técnica, provar que o espaço atual não a atende de forma prática e permitir que a AFRINIC confira essa relação.

O teste implícito tem três partes:

função técnica → impossibilidade prática com o pool atual → fatia IPv4 adicional

Cada seta precisa de evidência. Qual é a função? Quais blocos existentes foram examinados? Por que não cabem reutilização, renumeração, outra agregação ou posicionamento? Qual site ou domínio de falha receberá a nova fatia? Por quanto tempo os recursos coexistirão? Que fato tornaria a justificativa falsa?

Sem respostas nomeadas, a salvaguarda vive na correspondência. O requerente de hoje pode entender a decisão; um substituto, auditor ou recorrente encontra um resultado e anexos diferentes para cada caso.

Discrição, motivo e recurso fazem trabalhos diferentes

A gravação da reunião descreve a análise como diálogo, não como dossiê universal. Ela não estabelece decisão final nem comprova direito jurídico específico de recurso. Discrição profissional, motivos registrados e qualquer caminho aplicável de correção ou revisão são escolhas distintas.

Discrição é o espaço para interpretar fatos que não viram um teste automático. Motivo é o registro de como esse espaço foi usado. Recurso é o caminho para testar se regra, fatos e motivo foram conectados corretamente.

Preservar o primeiro não obriga a esconder o segundo ou fechar o terceiro. Sem um decision record, a correção ou revisão apenas repete a conversa em outro nível. É preciso saber se falharam a arquitetura, a impossibilidade de reutilização, o tamanho pedido, a qualidade da prova, a classificação ou a versão da regra.

Um exemplo multi-PoP não cria direito automático

A apresentação da proposta usa uma implantação 464XLAT multi-PoP como exemplo motivador. É cenário de desenho, não auditoria de rede de membro, direito automático a novo espaço ou topologia universal. Seu alcance é menor: uma função técnica pode precisar existir ao mesmo tempo em vários domínios de falha antes de a utilização agregada alcançar um limite sequencial.

A arquitetura 464XLAT do RFC 6877 combina tradução stateful no core e stateless na borda para fornecer conectividade IPv4 limitada por uma rede IPv6-only. O RFC é Informational. Não exige quatro PoPs, dois dispositivos em cada site nem um tamanho específico de prefixo público.

O campo comum deve perguntar qual função e domínio de falha usam o endereço, por que o espaço existente não serve e como a demanda foi dimensionada. Produto, colocação, protocolo de redundância e roteamento continuam com o operador.

Especificação mínima não é especificação vaga

A Minimum Initial Specification de Lu Heng separa as regras determinísticas mínimas necessárias à coordenação das escolhas futuras que podem permanecer com os participantes que operam a rede.

A AFRINIC controla um pool finito. Verificar necessidade, preservar unicidade, manter registros corretos e aplicar critérios de forma equitativa são funções reais do registro. O fornecedor do data center, a plataforma NAT64, o roteamento interno e a ordem da obra não se tornam invariantes comuns por causa disso.

A síntese é menor do que um manual de arquitetura e mais forte do que um adjetivo: fixar os campos que toda decisão conserva; permitir provas adequadas a cada desenho; proteger anexos sensíveis; publicar apenas a versão e agregados que não revelam membros ou topologia.

Uma camada comum vaga força cada requerente e cada Hostmaster a inventar uma especificação privada. A interface mínima escreve a parte realmente compartilhada e deixa o restante local.

Dezoito campos para o recibo de exceção

Esta é uma proposta analítica do artigo, não um formulário AFRINIC existente.

  1. ID do pedido ou ticket. Une uma solicitação às provas, ao diálogo e ao resultado.
  2. Identidade da regra. Guarda política, draft ou versão implementada e o parágrafo aplicado.
  3. Requerente e tipo de pedido. Distingue LIR ou End User, allocation ou assignment, inicial ou adicional.
  4. Base normal. Congela o portfolio e o cálculo exato dos 90% que valeria sem exceção.
  5. Classe de exceção. Nomeia redundância, alta disponibilidade, transição IPv6, novo site ou outra finalidade técnica.
  6. Unidades funcionais. Identifica sites, PoPs ou funções no arquivo protegido e usa rótulos anônimos na saída pública.
  7. Fatias solicitadas. Associa cada prefixo ou quantidade ao site ou à função correspondente.
  8. Janela de simultaneidade. Explica por que as funções precisam entrar juntas e por quanto tempo os recursos coexistem.
  9. Relação de impraticabilidade. Registra a razão topológica, de roteamento, tradução ou domínio de falha que impede usar o espaço atual.
  10. Plano de endereçamento. Preserva uso atual e previsto, unidade e horizonte de cada fatia relevante.
  11. Análise do espaço ocioso. Inventaria o que está livre e justifica descartar reúso, renumeração ou outra posição.
  12. Custódia da evidência. Lista arquivos, hashes, controlador, limite de acesso e retenção sem publicar topologia sensível.
  13. Histórico do diálogo. Acrescenta perguntas, respostas e timestamps sem apagar raciocínio anterior.
  14. Classificação e motivos. Registra technical, operational ou mixed com reason codes estáveis e explicação.
  15. Decisão e condições. Conserva aprovação ou negação, tamanho concedido, condições, validade e revisão futura.
  16. Correção e recurso. Liga aviso, canal de correção factual, prazo e rota de appeal aplicável.
  17. Substituição de versão. Aponta a regra posterior que altera o teste, mantendo a usada na decisão.
  18. Agregados públicos. Publica contagens, classes, faixas de processamento, resultados e correções sem expor membro ou rede.

Os dezoito campos não decidem se uma arquitetura de quatro PoPs é verdadeira. Tornam a avaliação repetível. Outro revisor recebe o mesmo portfolio, a mesma restrição e a mesma pergunta em aberto. O requerente corrige um fato sem reescrever a história. A AFRINIC identifica diferenças não explicadas entre classes, portes ou etapas.

Antes de operar a exceção, publique o que ela deixa

A direção do Draft 2 é defensável. O segundo domínio de falha não deveria esperar o primeiro se aproximar da lotação; isso faria a redundância chegar depois da falha. O relatório de 2018 mostra que o conflito apareceu numa avaliação real da AFRINIC.

O texto preserva outra disciplina: a finalidade técnica deve ser provada, não apenas declarada. O problema não é haver julgamento profissional. É a regra comum não definir o registro que permanece depois dele.

“Suficientemente documentada” pode abrir uma conversa. Não é o arquivo duradouro de uma exceção sobre recurso escasso. Antes de implementar o waiver, a AFRINIC deveria publicar campos mínimos, proteção de provas e códigos de motivo. Assim, o registro conserva o pool sem desenhar a rede, e o operador desenha a rede sem inventar seu próprio padrão de evidência.

Fontes