Resumo

  • A versão 2 da proposta exigiria, em todo pedido inicial ou adicional de IPv4 durante a Soft Landing, espaço IPv6 existente ou solicitado simultaneamente, um plano de implantação e resultados graduais: no tráfego, 25% em 12 meses, 50% em 24 e 75% em 48; em serviços hospedados, 25%, 75% e 95% dos registros AAAA disponíveis e alcançáveis pela Internet nos mesmos prazos.
  • O problema decisivo não é a utilidade do IPv6. É o salto entre conferir um pedido ao pool escasso e declarar “violação de política” quando resultados de arquitetura não são atingidos, embora a proposta não defina denominador, unidade de “destino”, prova aceitável, dependências externas, conformidade parcial, correção, consequência ou revisão independente.
  • Uma condição sobre o pool remanescente só é legítima se for estreita, prospectiva, objetiva e limitada a fatos que o solicitante controla. Ela deve terminar no pedido em análise e incluir prova, aviso, correção, continuidade e revisão; não pode transformar o registro em autoridade sobre arquitetura nem alcançar recursos já operacionais.

A D2, como é conhecida a AFPUB-2026-v6-001-DRAFT02, parece à primeira vista uma troca simples. Quem pede IPv4 escasso à AFRINIC deveria mostrar que não está adiando indefinidamente o IPv6. O texto, porém, não se limita a exigir que o solicitante tenha IPv6, faça um pedido simultâneo ou entregue um plano. Ele amarra a elegibilidade para IPv4 a resultados observáveis durante quatro anos e chama o descumprimento do plano de violação de política. Para redes que carregam tráfego, a régua sobe de 25% dos destinos externos habilitados em 12 meses para 50% em 24 e 75% em 48.

Para quem hospeda serviços, aplicações ou conteúdo, a parcela de registros AAAA disponíveis e alcançáveis por IPv6 deve passar de 25% para 75% e depois 95% nos mesmos marcos.

Esse desenho coloca em jogo muito mais do que uma etapa adicional de formulário. A AFRINIC foi criada para coordenar a unicidade de recursos numéricos e manter registros exatos. Ao distribuir o que resta de um pool comum, pode aplicar condições objetivas ao pedido prospectivo: quem solicita, qual recurso é necessário, quais registros precisam ser criados e quais fatos demonstram controle. A D2 atravessa essa superfície. Ela pretende avaliar como o operador desenha a rede, o que seus clientes usam, quais destinos externos oferecem IPv6 e que proporção de serviços responde por uma segunda família de endereços.

O escriturário passaria a julgar o resultado arquitetural.

É por isso que vale acompanhar a proposta mesmo depois de ela ter voltado à lista RPD sem consenso na AFRINIC-37, em 24 de junho de 2026. A D2 não estava em vigor na data de corte; permanecia “Under Discussion”. Mas o texto expõe uma escolha constitucional para a camada de registro. Se “escassez” autorizar qualquer condição que pareça promover uma tecnologia desejável, o pool se torna porta de entrada para um mandato permanente. Se, ao contrário, a escassez estreitar a função — unicidade, exatidão, prova, notificação, correção e continuidade —, o pedido pode ser administrado sem transformar cooperação em governo.

A condição que a D2 realmente cria

A proposta, versão 2.0, foi apresentada por Jordi Palet Martinez, da The IPv6 Company, em 14 de junho de 2026. Sua sequência é cumulativa. Todo pedido inicial ou adicional de IPv4, durante o período de esgotamento, aciona a regra. Se o solicitante não possuir IPv6, deve pedi-lo ao mesmo tempo. Se já possuir ou fizer o pedido simultâneo, precisa satisfazer os critérios pertinentes de alocação ou designação de IPv6. Depois deve apresentar um plano “coerente” de endereçamento e implantação, fazendo referência aos requisitos atuais de implantação e anúncio do manual consolidado.

Até esse ponto, há duas obrigações que precisam ser separadas. A primeira é registral: não criar duplicidade, identificar o titular, documentar o pedido e verificar requisitos objetivos do pool. A segunda já é operacional: mostrar que a arquitetura futura produzirá determinados resultados. A D2 torna a segunda condição da primeira. Uma rede que transporta tráfego teria de revelar seus 25 principais destinos reais de tráfego IPv4 e demonstrar as parcelas estipuladas de IPv6 para os destinos externos que estejam habilitados.

Uma rede que hospeda conteúdo teria de medir a proporção de seus registros AAAA que não só existem, mas também permanecem acessíveis pela Internet em IPv6.

O contraste com a regra atual ajuda a dimensionar o salto. A seção 5.4.4 do manual diz que não há limite explícito para o número de vezes em que um LIR ou usuário final pode pedir IPv4 adicional durante o período de esgotamento. Na Fase 2 da Soft Landing, o pedido máximo é um /22 e o mínimo, um /24; a necessidade considerada cobre oito meses. Para IPv4 adicional, a seção 5.4.6.1 exige utilização de 90% da alocação anterior, enquanto o primeiro pedido é dispensado desse teste. São condições sobre o recurso pedido e sobre aquilo que o solicitante usou.

Podem ser criticadas, mas pelo menos apontam para um objeto verificável na relação imediata entre solicitante e pool.

Os critérios IPv6 atuais também já têm um horizonte. O mínimo para um LIR é /32; para usuário final, /48 por local. Os critérios iniciais citados contemplam implantação ou anúncio em 12 meses. Um /32 contém 65.536 unidades /48, uma escala do plano de endereçamento, não uma medida de utilização ou de clientes. A D2 faz algo diferente ao acoplar esses critérios à fila de IPv4 e prolongar a verificação por 48 meses. O pedido deixa de ser apenas o momento em que a documentação é conferida. Torna-se o gatilho para acompanhamento de comportamento futuro.

Há até uma inconsistência textual que recomenda cautela. O corpo normativo diz alterar a seção 5.4.4, mas os metadados da avaliação de impacto listam as seções 6.4.4, 6.5.1.1.1 a 6.5.1.1.4 e 6.8.2.2.d, sem listar 5.4.4. Não é possível concluir, a partir do material publicado, qual lista está errada. A divergência, contudo, reforça a pergunta que deveria preceder qualquer implementação: qual obrigação exata nasce, em qual etapa, com qual prova e qual consequência?

“Top 25” não é um padrão de prova

Os números da D2 transmitem precisão. Eles não entregam determinação. “25% dos 25 principais destinos” parece uma fração calculável até que se pergunte o que constitui um destino e o que entra no denominador. Pode ser endereço IP, prefixo, ASN, domínio, aplicação, serviço ou provedor de conteúdo. Um destino dinâmico pode aparecer sob endereços diferentes. Um serviço pode usar anycast, redes de distribuição e múltiplos nomes. A classificação pode mudar conforme se contem bytes, pacotes, fluxos, sessões, usuários ou consultas.

A proposta não escolhe uma dessas unidades. Tampouco determina intervalo de observação, tamanho mínimo de amostra, método de coleta, normalização, tratamento de picos ou procedimento de validação. Não diz se um destino deve permanecer entre os 25 principais por todo o período ou apenas no instante da medição. Não diz como tratar tráfego criptografado, serviços agregados ou mudanças sazonais. Não se deve preencher essas lacunas por suposição. Uma porcentagem sem objeto e denominador não é uma regra objetiva; é espaço para interpretação administrativa.

A parte de hospedagem sofre do mesmo defeito. O texto exige registros AAAA “disponíveis” e serviços alcançáveis pela Internet. Mas qual inventário de serviços é contado? Nomes internos ficam de fora? Como entram aliases, múltiplos endereços, anycast, protocolos diferentes e alcance parcial? De quais pontos de observação a conectividade seria testada? Uma falha externa transitória reduz conformidade? Não há respostas publicadas. A meta de 95% em 48 meses pode parecer ambiciosa ou moderada conforme o inventário adotado; sem inventário definido, não é uma norma.

Não é preciso imaginar essas objeções. A própria avaliação da equipe da AFRINIC identificou “coerente” como termo não definido e apontou lacunas na medição dos 25 principais destinos, na validação de quais destinos são habilitados para IPv6, na evidência aceitável, na conformidade parcial e no atraso justificado. Na AFRINIC-37, participantes advertiram que nem todo operador dispõe de NetFlow, que clientes não podem ser obrigados a adotar uma tecnologia, que metas de tráfego podem estimular manipulação e que talvez fosse necessário um período de carência para pedidos iniciais.

Os copresidentes consideraram as preocupações não resolvidas e devolveram o texto à lista.

Essa sequência importa porque o problema não se resolve com uma frase dizendo que o Hostmaster usará bom senso. Quanto menos determinado o padrão, mais poder migra do texto para quem examina o caso. Dois solicitantes com redes semelhantes podem produzir bases diferentes; dois analistas podem pedir evidências diferentes; um terceiro pode considerar um atraso justificável onde outro enxerga violação. A flexibilidade pode ser útil para corrigir exceções, mas, quando antecede qualquer protocolo de prova e está ligada a uma palavra punitiva, ela substitui regra por discricionariedade.

Uma média regional não julga uma rede

O problema de medição começa antes do teste individual. A justificativa da D2 apresenta valores arredondados de capacidade IPv6 no mundo e na África: 44% e 6%. Esses números são compatíveis com a série regional do APNIC Labs em 14 de junho de 2026. Na leitura bruta daquele dia, a capacidade era 43,822740% no mundo e 5,869934% na África, valores que arredondam para as porcentagens citadas. Séries suavizadas de dez, 30 e 90 dias também produzem números próximos.

A coincidência, porém, não torna a citação reproduzível. O rascunho não informa data de observação, janela de suavização nem consulta. Também apresenta contagens de países africanos acima de 20%, entre 10% e 19% e abaixo de 1% sem fornecer universo, lista de países, data ou série. Esses agrupamentos continuam sendo afirmações da proposta; não podem ser reconstruídos apenas a partir do texto divulgado.

Mais importante, “IPv6 capable” no APNIC Labs tem significado específico. O experimento baseado em anúncios mede se endpoints amostrados conseguem buscar um objeto disponível apenas por IPv6; os resultados são agregados com ponderação. A métrica não conta alocações IPv6, não conta redes configuradas e não mede a parcela de todos os bytes da Internet transportada em IPv6. Ela descreve capacidade observada em uma população amostrada. Não demonstra que um solicitante controla cada fator que determina seus próprios resultados.

O erro institucional seria usar a distância entre 6% e 44% como autorização para qualquer instrumento que prometa fechá-la. Uma estatística regional pode explicar por que a adoção é tema de interesse. Não define uma obrigação individual, não atribui causalidade a um operador e não escolhe uma prova justa. A função registral não se amplia porque a diferença estatística é grande. Ao contrário: quanto mais heterogêneas forem as condições por tipo de rede, equipamento, cliente e contraparte, menos uma média legitima julgamento uniforme.

A parcela que o solicitante não controla

Uma condição justa só pode recair sobre evidência que o solicitante produz e sobre fatos que consegue alterar. A D2 mede resultados coproduzidos. Tráfego depende de escolhas de clientes, capacidade de equipamentos, suporte de upstreams, disponibilidade de conteúdo e comportamento de aplicações. Alcance de um serviço depende de DNS, hospedagem, rotas e pontos externos. O solicitante pode configurar sua própria infraestrutura; não pode obrigar cada dispositivo do cliente, fornecedor de CPE, rede de trânsito ou destino externo a tornar-se compatível.

Essa distinção não é uma desculpa abstrata. A equipe da AFRINIC registrou que operadoras menores, incluindo WISPs, poderiam ser afetadas de modo desproporcional quando compatibilidade de dispositivos, realidade comercial ou prontidão técnica retardassem a implantação apesar de necessidade genuína de IPv4. Após a reunião, Ben Roberts formulou na lista uma objeção em nome de uma startup rural: redes novas que conectam escolas podem não possuir ferramentas de análise de tráfego e já enfrentam barreiras suficientes. O autor respondeu que IPv6 e monitoramento básico não deveriam ser opcionais.

A divergência é factual e distributiva: quem controla o resultado e quem paga para prová-lo?

Custos de conformidade desse tipo têm uma parcela fixa. Coletar fluxos, reter dados, inventariar DNS, testar alcance, preparar um plano e responder a pedidos de prova exige trabalho antes de se considerar o número de assinantes. A avaliação prevê mudanças de fluxo e interface no MyAFRINIC, possíveis alterações de integração no NetSuite, mudanças no processo de gestão de recursos numéricos, treinamento de Hostmasters e talvez contratação. Ela não prevê mudanças em WHOIS, RDAP ou RPKI. Também não fornece estimativa financeira. Não há base para inventar um custo por operador ou um custo agregado.

Mesmo sem um valor, a incidência é clara. Uma rede grande pode diluir telemetria, pessoal e revisão por muitos clientes. Uma rede pequena carrega a despesa sobre uma base estreita. O atraso de um pedido de IPv4 enquanto se discute uma evidência de IPv6 pode impedir expansão que já tem demanda, embora o fator em disputa esteja fora do controle do solicitante. A regra, portanto, pode ser regressiva mesmo se sua porcentagem for idêntica para todos. Igualdade de meta não equivale a igualdade de carga.

Há ainda uma assimetria de confidencialidade. A lista de principais destinos e os fluxos que a sustentam podem revelar concentração de conteúdo, composição de clientes, padrões de trânsito ou dependências comerciais. Trata-se de inferência a partir do dado exigido, não de notícia de vazamento. Nem a D2 nem a avaliação publicada especificam minimização, retenção, acesso, agregação ou proteção dessa informação. Uma instituição que pede telemetria comercialmente sensível deve primeiro definir por que cada campo é necessário, quem pode vê-lo, quanto tempo será guardado e como será contestada uma leitura incorreta.

A ausência desse desenho não é detalhe operacional; é razão para não coletar.

Da condição à punição, há um vazio

A frase mais importante da D2 é a mais curta: o não cumprimento do plano seria tratado como violação de política. O rascunho não explica o que acontece depois. Não diz se a consequência é apenas negar o pedido pendente, abrir uma revisão, afetar pedidos futuros ou acionar algum remédio contratual. Não define período de correção, exceção, padrão de prova, recurso, efeito suspensivo ou tratamento dos recursos já existentes. Por isso seria incorreto afirmar que a D2 determina revogação automática. Ela não determina.

O silêncio, contudo, não é tranquilizador. O Acordo de Serviços de Registro cria uma ponte entre políticas adotadas e deveres do membro. Ele define política adotada de modo a incluir a que for aprovada durante a vigência do acordo e obriga cumprimento. Permite pedidos de informação e revisões de utilização. Falta de cooperação pode levar, conforme o texto contratual, à retenção de serviço, revogação, consequências para futuras alocações, encerramento de LIR ou término do acordo. Para término por violação, o acordo exige particularidades por escrito, oportunidade de explicar ou corrigir, prazo de 30 dias para responder e prova de remediação.

Também contém cláusula de recurso e uma rota de revisão pelo Board para decisões de um registro atribuidor.

Essas garantias gerais não consertam a D2. Elas mostram por que a palavra “violação” precisa de uma cadeia expressa. O acordo foi escrito para uma relação contratual ampla; a proposta cria um teste novo. É preciso saber qual constatação aciona qual consequência, qual registro probatório sustenta a decisão, quem revisa a leitura e o que acontece enquanto o recurso corre. Sem essa ligação, um rótulo indeterminado pode importar o peso de remédios gerais sem definir o caminho que os limita.

A avaliação jurídica publicada não resolve a questão. Sua conclusão se resume a “No legal issue”; a parte operacional informa que nenhuma atualização contratual foi identificada. Não há raciocínio público sobre confidencialidade dos dados de tráfego, dependências externas, confiança legítima, prova, correção ou recurso. A frase demonstra apenas o que a instituição registrou em sua avaliação. Não constitui parecer independente, decisão judicial nem explicação suficiente para um poder que poderia afetar continuidade operacional.

Uma política fina exigiria a ordem oposta: primeiro, objeto definido; depois, evidência proporcional; em seguida, constatação escrita; então, aviso e oportunidade de corrigir; por fim, revisão independente antes de qualquer efeito difícil de reverter. E o resultado deveria permanecer limitado ao pedido prospectivo do pool. Recursos que já sustentam redes não podem se tornar reféns de uma meta arquitetural posterior. A escrituração pode dizer “a evidência para este novo pedido não foi demonstrada”. Não pode dizer “sua rede existente perdeu legitimidade porque não atingiu a arquitetura preferida”.

A melhor defesa da proposta

A D2 merece a forma mais forte de seu argumento. O IPv4 remanescente não é abundante. A AFRINIC já condiciona alocações do pool a necessidade e utilização. Pedir a quem busca um benefício escasso que possua IPv6 e apresente trabalho prospectivo, mensurável e com prazos não é, por si só, absurdo. A regra proposta não submete imediatamente todos os titulares existentes; segundo a leitura do autor e da equipe, o gatilho é um pedido novo ou adicional de IPv4. Os marcos de 12, 24 e 48 meses dão tempo, em vez de exigir migração instantânea.

Medir o tráfego próprio do solicitante poderia, em tese, adaptar a condição à rede, em lugar de impor uma arquitetura universal.

Há também um problema real de prova simbólica. Receber um prefixo IPv6, anunciá-lo ou produzir um plano não garante que usuários e serviços obtenham conectividade útil. O autor sustentou que implantação efetiva seria um compromisso melhor do que manter IPv6 inerte. Afirmou que redes menores poderiam migrar com mais facilidade e que 464XLAT poderia custar menos do que CGNAT. Em uma troca anterior na lista, defendeu que redes de conteúdo comuns tornariam os percentuais alcançáveis. São alegações relevantes a favor do desenho, mas a D2 não contém estudo de custo que permita tratá-las como resultado geral.

O comparador da ARIN reforça uma versão limitada dessa defesa. A NRPM 4.10 reserva um /10 e entrega /24s para necessidades imediatas de implantação de IPv6. Isso mostra que uma organização registral pode ligar uma pequena reserva IPv4 a um propósito IPv6. Mas o desenho é mais estreito: um pool dedicado e uma concessão para viabilizar implantação imediata, não uma condição de desempenho por quatro anos aplicada a todo pedido ordinário de IPv4 da Soft Landing. O precedente sustenta vínculo específico; não sustenta mandato arquitetural aberto.

A melhor defesa, portanto, chega até aqui: o pool escasso pode ser oferecido com condições prospectivas, objetivas e previamente publicadas; exigir um pedido simultâneo de IPv6 e um plano controlável pode reduzir solicitações puramente formais; evidência de prontidão pode informar o tratamento daquele pedido. Ela não atravessa o passo seguinte. A escassez não transforma a AFRINIC em regulador tecnológico, e o desejo de acelerar IPv6 não cria poder punitivo sobre escolhas de rede.

Por que esclarecer métricas não basta

Uma revisão poderia definir “destino”, escolher bytes ou fluxos, estabelecer janela e criar formulário. Isso melhoraria reprodutibilidade. Ainda assim, sobraria a pergunta anterior: por que a AFRINIC deve punir um resultado arquitetural? Um padrão perfeitamente mensurável pode continuar fora do mandato. A precisão não converte preferência tecnológica em dever registral.

A camada comum precisa permanecer fina porque é justamente sua indispensabilidade que produz poder. Redes cooperam com um registro para evitar duplicidade, manter contatos, provar controle, registrar mudanças e preservar segurança e continuidade. Nenhum desses invariantes exige que uma parcela específica do tráfego seja IPv6. Duas redes podem continuar interoperando se uma implantar IPv6 mais devagar. Um cliente pode continuar recebendo serviço se seu CPE for legado. Uma aplicação pode permanecer em IPv4 sem criar dois titulares para o mesmo prefixo. A escolha pode ter custos e benefícios locais, mas não quebra a unicidade.

Tratar não adoção como violação inverte a ordem da Internet. A mudança técnica deveria tornar-se realidade por implementação, operação e aceitação das redes que a sustentam. A documentação pode orientar. O registro pode refletir fatos. O pool pode ter requisitos estreitos. Mas uma sala de política não ganha soberania sobre empresas, clientes ou capital ao adotar um número. Cooperação não é autoridade; consenso entre participantes não é legislação sobre ausentes.

Essa fronteira é mais importante no IPv6 porque incentivos divergem. O solicitante paga equipamento, equipe, monitoramento e risco de falha. Quem administra a política recebe relevância institucional ao ampliar a superfície de avaliação. O autor da proposta tem afiliação a uma consultoria de IPv6, fato que deve ser registrado sem inferir motivo impróprio. A decisão correta não depende de adivinhar intenções. Depende de impedir que qualquer interesse — comercial, burocrático ou ideológico — seja incorporado como poder permanente na camada de unicidade.

Há ainda a realidade do coexistir. IPv6 funciona, mas a implantação pode significar operação paralela: roteamento, políticas de firewall, monitoramento, treinamento e tratamento de falhas em duas famílias. Esse custo não é idêntico em toda rede, e a D2 não o quantifica. O argumento de que 464XLAT reduz custo em relação a CGNAT pode ser verdadeiro em casos específicos; não autoriza a AFRINIC a decidir o balanço de investimento de todos. Quem assina contratos, atende clientes e suporta interrupções precisa conservar a decisão arquitetural.

Por isso a correção não é fazer do Hostmaster um árbitro mais bem equipado da transição. É retirar o juízo de arquitetura da função registral. Métricas podem ser oferecidas como evidência voluntária ou como porto seguro ligado apenas ao novo pedido. Podem ajudar um solicitante a mostrar prontidão. Não podem produzir a presunção de que uma rede em operação deve obediência tecnológica ao registro.

Uma condição compatível com um registro fino

Se a ligação entre IPv4 escasso e prontidão IPv6 for mantida, o desenho precisa começar com limites, não com porcentagens. O gatilho deve ser exclusivamente um pedido inicial ou adicional ao pool ainda administrado. A regra deve ser publicada antes do pedido, aplicar-se prospectivamente e terminar nele. Não deve reabrir recursos anteriores, alterar reconhecimento de controle, ameaçar rotas, RPKI, DNS reverso ou outros serviços essenciais. Uma insuficiência só pode afetar a concessão solicitada, após prova e revisão; nunca a continuidade do que já opera.

O núcleo aceitável seria modesto. O solicitante poderia demonstrar que possui IPv6 ou o pediu simultaneamente, que elaborou um plano datado e que executou ações sob seu controle: endereçamento interno, configuração de roteadores próprios, preparação de DNS sob sua administração, testes de serviços próprios ou arquitetura de tradução documentada. Esses são fatos verificáveis sem responsabilizá-lo por clientes, upstreams, fornecedores e conteúdo externo. O objetivo não seria obrigar um resultado de mercado, mas impedir que a condição do pool se torne meramente nominal.

Se números forem mantidos, devem funcionar como portos seguros refutáveis, não como gatilhos de punição. O texto teria de definir unidade de destino, denominador, janela, amostragem, validação e correção. Deveria permitir caminhos equivalentes: fluxos, habilitação de prefixos de clientes, inventário de serviços com AAAA e alcance, ou arquitetura de tradução documentada. A escolha do método precisa considerar o tipo de operador. O solicitante que não tiver NetFlow não pode perder elegibilidade só porque uma ferramenta foi implicitamente transformada em pré-requisito.

Dependências externas precisam ser excluídas ou ajustadas quando documentadas. O operador deve responder por sua configuração, não pela decisão de um cliente de manter equipamento antigo ou pela incapacidade de um destino de oferecer IPv6. Conformidade parcial precisa ter tratamento claro. Atraso justificável deve acionar correção, não acusação. Uma startup pode receber uma carência inicial acompanhada de plano e data de revisão; isso não cria isenção eterna, apenas evita que o custo fixo da prova elimine quem a política diz querer preparar.

A prova deve seguir uma programação confidencial publicada antes da aplicação. O registro precisa dizer quais dados solicita, por que, por quanto tempo os retém e quem os acessa. Resultados públicos devem ser agregados por faixa de tamanho de operador e método de evidência, sem expor inteligência de tráfego. Após 12 e 24 meses, a instituição poderia divulgar número de solicitantes, tipos de evidência, casos aprovados, corrigidos e revisados, além da mudança observada em IPv6. Isso produziria conhecimento sobre causalidade em vez de presumir que média regional e regra individual são equivalentes.

Por fim, uma constatação adversa exigiria razões escritas, acesso à evidência usada, possibilidade de corrigir e revisão independente. Enquanto houver revisão, a continuidade deve ser preservada. A decisão deve dizer somente se aquele pedido satisfaz a condição prospectiva. A palavra “violação” deve desaparecer quando estiver sendo usada para punir arquitetura. Se houver fraude no material apresentado ou duplicidade registral, essas são categorias próprias, com prova própria. Falhar uma meta de implantação não é fraude e não ameaça unicidade.

O teste final

A D2 deve ser julgada por quatro perguntas: qual condição exata está proposta; como seria medida; quem controla o resultado; e qual processo converte uma falha em consequência. Hoje, a sequência quebra em todos os pontos críticos. O texto oferece seis metas, mas não define os objetos que elas medem. Solicita evidência cujo resultado depende de terceiros. Usa a linguagem de violação sem ligar constatação, correção e revisão. E tenta resolver um objetivo de arquitetura por meio da porta estreita de acesso ao IPv4.

O fato de a AFRINIC-37 não ter encontrado consenso foi, nesse sentido, prudente. Ele não decide o futuro do rascunho, mas impede que ambiguidades operacionais sejam confundidas com norma adotada. Uma versão posterior pode retirar metas, acrescentar carência ou abandonar a linguagem punitiva; não há base para prever. O ponto de referência deve permanecer estável mesmo que o texto mude: a AFRINIC é coordenadora de unicidade, não soberana da arquitetura.

Isso não exige hostilidade ao IPv6. Exige respeito à competência de quem opera redes e ao limite da camada comum. A AFRINIC pode registrar IPv6, manter dados exatos, conferir prova de controle, processar pedidos, notificar inconsistências e corrigir o cadastro. Pode publicar orientação e oferecer apoio. Pode desenhar uma condição estreita para um pedido futuro ao pool, desde que objetiva e baseada no que o solicitante controla. Não pode transformar o acesso a um /22 ou /24 em juramento de quatro anos sobre tráfego, clientes e serviços, muito menos usar recursos já operacionais como garantia desse juramento.

O resultado correto não é “aprovar com métricas melhores”. É devolver a D2 à sua dimensão legítima. O pool pode ter critérios de entrada; a rede conserva sua autonomia arquitetural. A prova deve servir à decisão específica; não alimentar uma jurisdição permanente. Aviso e correção vêm antes de qualquer efeito. Revisão independente vem antes de irreversibilidade. Continuidade não é prêmio por conformidade, mas limite do poder registral.

Escassez, afinal, não dá ao escriturário as chaves da rede. Torna ainda mais necessário que o livro seja exato, o critério seja estreito e a mão que registra não se confunda com a mão que governa.