Resumo

  • A proposta correta era a AFPUB-2018-V6-001-DRAFT01, apresentada por Jordi Palet Martinez em março de 2018. Ela substituiu uma referência obsoleta ao RFC 3177 pelo RFC 6177, retirou a recomendação automática de /128, atualizou a terminologia, redefiniu utilização por quantidade de prefixos, corrigiu uma remissão interna e eliminou uma seção de revisão que havia envelhecido.
  • Essas mudanças eram estreitas, mas materialmente relevantes. Um tamanho inadequado de prefixo pode produzir renumeração, alterações de provisionamento, custos de registro e atrito com clientes; uma definição ambígua de utilização ou uma remissão quebrada pode mudar o planejamento de um membro e o tipo de justificativa que a equipe pede, mesmo sem haver prova de que algum resultado concreto de alocação tenha mudado.
  • O melhor argumento favorável à proposta deve ser aceito: esse foi o tipo de manutenção sóbria que um registro técnico competente deveria realizar, com comparação visível entre o texto vigente e o proposto. A lição não é que a AFRINIC adquiriu autoridade pública, mas que uma entidade privada responsável por registros precisa deixar correções verificáveis, versões claras e recibos de implementação.
  • O procedimento público forneceu evidência, contestação e revisão. Ele não foi legislação nem consentimento soberano regional. A AFRINIC é apenas uma escrituradora e coordenadora técnica privada, legitimada para proteger unicidade, exatidão registral, contactabilidade, metadados interoperáveis de segurança, resistência a fraudes e continuidade operacional — nunca para regular, punir, confiscar ou julgar.

L3 — A referência obsoleta escondida no manual

O defeito cabia em poucas linhas, mas não era pequeno para quem dependia delas. Em 2001, o RFC 3177 havia recomendado, em termos gerais, um /48 para um sítio final, um /64 quando se soubesse que haveria apenas uma sub-rede e um /128 quando se soubesse que haveria apenas um dispositivo. Em março de 2011, o RFC 6177 tornou o documento anterior obsoleto. A orientação nova recusou a ideia de um único tamanho padrão para todos os sítios, desaconselhou limitar um sítio final a somente um /128 e deixou a escolha exata para o julgamento operacional, respeitados os parâmetros arquitetônicos do IPv6.

Ainda assim, em março de 2018, a seção de IPv6 do manual da AFRINIC continuava apontando o leitor para a orientação de 2001 e reproduzindo parte daquela fórmula.

Esse intervalo de sete anos é o ponto de partida adequado. Não porque demonstre dolo, negligência ou dano comprovado — o registro disponível não autoriza nenhuma dessas conclusões —, mas porque expõe a dependência entre um texto administrativo e a prática técnica que ele pretende organizar. Uma referência externa não funciona como ornamento bibliográfico quando está incorporada ao manual usado por membros e funcionários. Ela orienta expectativas sobre tamanho de atribuição, desenho de sub-redes, persistência de endereços e justificativas.

Quando a referência envelhece, o manual pode conservar uma presunção que a comunidade técnica já abandonou. O erro passa então da página para o planejamento, ainda que não exista um ato individual documentado que permita medir esse efeito.

O nome correto da iniciativa também importa para a auditabilidade. O instrumento oficial foi o IPv6 Policy and References Update Draft 1, identificado como AFPUB-2018-V6-001-DRAFT01. O código V6-002 pertencia a outra proposta, dedicada à clarificação de subatribuições de IPv6. Corrigir essa identificação não transforma um desencontro de catálogo no centro da história; apenas impede que duas iniciativas diferentes sejam fundidas retrospectivamente. V6-001 tratou de referências, redação, utilização, remissões e uma seção obsoleta.

Não cabe atribuir a ela os méritos, problemas ou efeitos da proposta de subatribuições, tampouco os das iniciativas vizinhas sobre alocação inicial ou endereçamento independente de provedor.

A página oficial registra Jordi Palet Martinez como autor, a submissão em 11 de março de 2018 e a postagem da primeira minuta na lista rpd em 14 de março. O problema declarado era que a implantação de IPv6 e mudanças anteriores de política haviam deixado inconsistências e referências incorretas no texto então vigente. A iniciativa foi apresentada como clarificação e correção, não como mudança na aplicação. Essa descrição oficial é relevante, mas precisa ser lida com precisão.

Ela informa a intenção alegada e a natureza formal da alteração; não prova que a redação antiga fosse inócua para todos os leitores nem que a redação nova jamais pudesse influenciar interpretação e planejamento.

O primeiro conjunto de mudanças estava na seção 6.0. O texto antigo falava em ISP, preservava a sequência de exemplos /48, /64 e /128 e enviava o leitor ao RFC 3177. A proposta trocou ISP por LIR, conservou /48 e /64 como referências contextuais, retirou a recomendação de /128 e substituiu o documento obsoleto pelo RFC 6177. Não era uma ordem para dar /48 a todo sítio, nem uma declaração de que toda atribuição /64 estaria errada. Era justamente o afastamento de uma receita rígida.

O princípio atualizado era que diferentes redes finais podem ter necessidades diferentes e que o tamanho deve ser escolhido com base nessas necessidades e na boa prática operacional.

Essa nuance é essencial. O RFC 6177 não substituiu uma fórmula universal por outra fórmula universal. Ele rejeitou o automatismo de um /48 para qualquer situação, sem transformar o /64 em resposta única, e advertiu contra a extrema restrição de somente um /128. A proposta da AFRINIC acompanhou esse deslocamento: uma infraestrutura mais simples poderia receber a recomendação de /48, mas a decisão deveria nascer da necessidade operacional. O texto também passou a recomendar prefixos persistentes e /64 globais unicast em enlaces ponto a ponto.

Essas orientações encontravam respaldo na prática operacional registrada no RIPE-690, publicado em outubro de 2017.

Persistência não é um detalhe abstrato. Um prefixo planejado para sobreviver a mudanças razoáveis reduz a probabilidade de que clientes, equipamentos, filtros, listas de controle, registros e procedimentos de suporte tenham de ser alterados depois. Do mesmo modo, um desenho que reserva espaço coerente para sub-redes evita que a economia inicial se converta em renumeração cara. O RIPE-690 chamou atenção para o fato de que escolhas ruins de tamanho ou persistência podem causar falhas operacionais, trabalho de renumeração, custos adicionais de registro e atrito com usuários.

A inclusão de uma referência contemporânea no manual, portanto, conectava a redação do registro a problemas concretos que operadores tentavam evitar.

O segundo delta relevante tratava de utilização. O texto antigo media a utilização pela quantidade de /48 atribuídos a sítios finais. A proposta passou a defini-la pela quantidade de prefixos atribuídos, e não pelo tamanho de cada prefixo nem pela contagem de endereços efetivamente usados dentro deles. Essa mudança parece terminológica até se perguntar o que um LIR precisaria contabilizar. Se diferentes sítios podem receber prefixos de tamanhos diferentes, um denominador fixado em blocos /48 distorce o retrato da atividade.

Se, por outro lado, alguém tentasse contar endereços individuais usados, importaria para IPv6 uma métrica inadequada à sua arquitetura. Contar prefixos atribuídos produzia uma definição compatível com a flexibilidade reconhecida no restante da correção.

A importância da definição está em sua função. Utilização pode influenciar como uma organização planeja crescimento, organiza seus registros internos e apresenta informações quando solicita recursos. Uma definição imprecisa abre espaço para dois erros opostos: o membro pode preparar dados que não respondem à pergunta real, e a equipe pode pedir comprovação excessiva ou insuficiente por interpretar de outra maneira a unidade de medida. Não há evidência fechada de que isso tenha acontecido em casos específicos.

Há, porém, um mecanismo plausível e direto: quando manual, planilha interna e análise de pedido usam unidades diferentes, a transação custa mais e se torna menos previsível.

Outra correção atingia a seção 6.5.4.1. O manual remetia uma exceção à seção 6.3.3, mas a referência correta era 6.5.2. A proposta consertou o caminho e manteve a indicação de que informações detalhadas sobre redes de usuários normalmente não seriam solicitadas. Uma remissão quebrada é um defeito clássico de governança documental porque impede que o leitor encontre a condição que limita ou explica uma regra. Em um romance, um número errado de capítulo irrita. Em um manual operacional, pode mudar a resposta à pergunta sobre quais documentos apresentar e sob quais circunstâncias uma exceção existe.

O fato de a redação preservar a expectativa de que detalhes da rede do usuário não seriam ordinariamente pedidos também merece atenção. O limite sobre coleta de informação precisa ser encontrável e inteligível para ambos os lados. Um membro deve poder antecipar a carga probatória; um funcionário deve poder justificar por que pediu ou deixou de pedir determinado material. A referência correta não cria direitos soberanos nem um regime público de devido processo. Ela torna uma prestação privada menos arbitrária porque amarra a atuação cotidiana à versão verificável de um texto comum.

A proposta ainda marcou para exclusão a antiga seção 6.5.4.2, que tratava da atribuição de vários /48 a um único sítio final. A disposição continha exigência abrangente de documentação e revisão no nível da AFRINIC. Retirá-la eliminava uma etapa que já não se ajustava à orientação baseada em necessidade e à variedade de tamanhos de prefixo. A eliminação podia reduzir papelada desnecessária e margem de decisão discricionária. Mas essa conclusão deve permanecer modesta: os registros não quantificam quantos membros haviam apresentado tal documentação, quantas revisões foram evitadas ou que custos efetivamente desapareceram.

Há também uma mudança curta na introdução da seção 6.8, relativa ao espaço independente de provedor. A proposta condensou a redação introdutória, mas não substituiu toda a arquitetura de elegibilidade desse tipo de recurso. Uma iniciativa distinta, V6-004, cuidava de atualização mais ampla nessa matéria. Manter essa fronteira evita inflar o alcance de V6-001. A correção de referências não deve ser narrada como reforma geral da política de IPv6, assim como uma alteração introdutória não deve receber efeitos que pertenciam a outro debate.

Considerados em conjunto, os deltas formavam um trabalho editorial com consequências técnicas: atualizar o RFC citado; retirar o caso /128; substituir a nomenclatura antiga por LIR; reconhecer escolha de tamanho baseada em necessidade; recomendar persistência e /64 em enlaces ponto a ponto; contar prefixos na definição de utilização; corrigir uma remissão; retirar uma revisão obsoleta; encurtar uma introdução sem redesenhar seu regime. Dizer que a proposta “apenas arrumou referências” seria incompleto. Dizer que ela revolucionou alocações ou direitos também ultrapassaria a prova disponível.

Em 9 de maio de 2018, a proposta foi discutida na AFRINIC-28. O autor afirmou que ela não afetaria a emissão de recursos nem as informações de justificativa, e a equipe disse que o texto poderia ser implementado como estava, sem impacto operacional para a AFRINIC. O resultado anunciado pelo copresidente encaminhou a iniciativa para a fase de consulta final, ou Last Call. Mais tarde, a alteração foi implementada no manual. O registro de implementação informa que a versão 1.3 do CPM incorporou mudanças nas seções 6.0, 6.1 e 6.5.4.1 e eliminou a antiga 6.5.4.2; com a renumeração, a anterior 6.5.4.3 tomou seu lugar numérico.

A data registrada para as mudanças no CPM é 1º de novembro de 2018, e o anúncio de implementação foi publicado em 29 de novembro.

Essa cronologia fornece um encadeamento suficiente para distinguir minuta, discussão, consulta final e implementação, mas não autoriza preencher todas as lacunas. O material disponível não traz o conjunto completo de mensagens da consulta final, a ata específica de ratificação do Conselho nem a data exata dessa ratificação. A página arquivada da proposta ainda a apresenta como “em discussão”, embora outros registros oficiais mostrem que ela avançou e foi implementada. A divergência é, por si só, instrutiva: uma etiqueta isolada em uma página não constitui um histórico completo do ciclo de vida.

Um sistema documental confiável precisa reconciliar página da proposta, registro de reunião, versão do manual e aviso de implementação.

Também é preciso interpretar com cuidado a frase “sem impacto operacional”. Na boca da equipe, ela era uma avaliação de viabilidade e de efeito sobre as operações da própria AFRINIC. Não constitui prova de custo zero para cada operador nem de efeito interpretativo zero. É perfeitamente possível que uma alteração seja simples de implementar internamente e ainda ajude membros a planejar de modo diferente. É igualmente possível que grande parte dos operadores já seguisse o RFC 6177 e o RIPE-690, tornando a correção apenas uma sincronização tardia do manual. Sem dados de casos, não se pode escolher uma dessas hipóteses como fato.

O que se pode afirmar é mais importante e mais limitado: o manual era uma superfície de controle do serviço privado. Seus números de seção, unidades de medida e referências externas estruturavam o diálogo entre quem pedia e quem processava. Torná-los coerentes diminuía a probabilidade de interpretações divergentes. A correção não transferia propriedade de recursos, não decidia uma controvérsia, não criava sanção e não convertia uma recomendação técnica em lei. Ela melhorava o instrumento pelo qual uma escrituradora técnica descrevia suas rotinas.