O livro-razão da transição dos ASNs: o que a Resolução 200605.27 aprovou — e o que não aprovou

Resumo

• A Resolução 200605.27 aparece no índice do conselho como uma ratificação da passagem de ASNs de dois para quatro octetos e uma instrução de implementação. Mas o relatório da AFRINIC-4 ainda registra discussão e consenso para avançar em 17 de maio de 2006, o arquivo da política situa a última chamada entre 13 e 28 de novembro, e a Resolução 200611.34 volta a registrar uma ratificação. Os documentos formam uma trilha de aprovação em pelo menos dois tempos; não autorizam inventar uma explicação que elimine a divergência.
• O cronograma alterou padrões de emissão, não o comportamento dos roteadores por decreto: ASN de quatro octetos somente mediante pedido a partir de 1º de janeiro de 2007; ASN de quatro octetos como padrão, com o de dois octetos mediante pedido, a partir de 1º de janeiro de 2009; e conjunto indiferenciado a partir de 1º de janeiro de 2010. Negociação de capacidade, AS_TRANS e atributos de preservação de caminho permitiam convivência gradual, mas não tornavam equipamentos, filtros, sistemas de monitoramento, formulários e registros automaticamente compatíveis.
• A transição defensável é aquela que deixa prova portátil desde o texto da política até o inventário, o pedido, a atribuição, o registro público, o teste do operador, o uso em roteamento e qualquer devolução ou troca. A AFRINIC podia coordenar unicidade, mudar padrões de solicitação e manter um livro-razão. Continuava sendo uma escrituradora privada: não adquiriu soberania, poder legislativo, regulatório, policial, acusatório, judicial, punitivo ou confiscatório, nem criou propriedade sobre um ASN.

Uma aprovação de maio que não encerra a história em maio

A maneira mais segura de ler a Resolução 200605.27 começa por recusar uma narrativa excessivamente limpa. No índice público do conselho de 2006, ela é apresentada como parte de uma decisão que ratificava quatro políticas, entre elas a mudança de ASNs de dois para quatro octetos, e instruía a equipe a implementá-las. Tomado isoladamente, esse registro permite dizer que houve uma aprovação registrada pelo conselho em maio e uma ordem interna de execução. Não permite dizer que toda a sequência procedimental terminou ali, porque outros registros contemporâneos preservam uma cronologia diferente.

O relatório da AFRINIC-4 situa a proposta na reunião de 17 de maio. Segundo esse documento, a discussão foi limitada, embora favorável; algumas pessoas ainda consideravam a questão pouco relevante naquele momento. O resultado anotado foi consenso para seguir adiante. Essa fórmula é importante. “Seguir adiante” não é automaticamente sinônimo de uma política cuja consulta, última chamada, ratificação e implementação já estivessem todas concluídas. É uma fotografia do que o relatório da reunião afirmou, não uma licença para preencher as etapas ausentes com suposições.

O arquivo da própria política amplia a tensão. Ele registra o consenso na AFRINIC-4 em 17 de maio, mas também informa uma última chamada de 13 a 28 de novembro de 2006. A página traz ainda uma discrepância de metadados anterior: apresenta 22 de setembro de 2005 como data da política, enquanto o histórico diz que a proposta foi publicada pela primeira vez na lista em 9 de dezembro de 2005. Pode ter havido versões, práticas editoriais ou categorias de data diferentes, mas os materiais disponíveis não explicam isso. O controle documental correto é conservar os dois campos com seus rótulos e não escolher um “verdadeiro” começo por conveniência.

A mesma página do conselho que contém a decisão de maio registra separadamente a Resolução 200611.34 como ratificação da política de ASNs de quatro octetos. O relatório da AFRINIC-5 acrescenta que o conselho havia aprovado a política poucos dias antes daquela reunião do fim de novembro e início de dezembro, e anuncia disponibilidade a partir de 1º de janeiro de 2007. A combinação não desfaz a Resolução 200605.27, tampouco transforma a de novembro em duplicata sem significado.

Ela sustenta uma conclusão mais modesta e mais robusta: existe uma aprovação e instrução de implementação registradas em maio, ao lado de uma trilha procedimental que continuou e culminou em uma ratificação separada no fim de novembro.

Essa diferença não é preciosismo arquivístico. Uma organização que reduz tudo a uma única coluna “data de aprovação” pode apagar a distinção entre deliberação em reunião, consenso para avançar, instrução do conselho, última chamada e ratificação posterior. Anos depois, uma pessoa encarregada de auditar uma atribuição não saberá qual versão, qual padrão ou qual exceção estava valendo. O conflito maio/novembro deve permanecer visível como achado de auditoria até que surja uma reconciliação documentada; a ausência dessa reconciliação não pode ser coberta por uma teoria jurídica inventada.

Também é preciso resistir à tentação oposta: usar a inconsistência para declarar que nada aconteceu. A entrada de maio é evidência de um ato institucional registrado. O relatório da reunião é evidência de como a reunião descreveu sua discussão e seu consenso. O histórico da política é evidência das datas que o arquivo conserva. A decisão de novembro é evidência de outra ratificação anotada. Cada documento prova uma proposição delimitada. A análise séria não escolhe entre credulidade total e cinismo total; ela preserva a granularidade da prova.

Três etapas de emissão, nenhuma ordem aos roteadores

O núcleo operacional da política era um cronograma de padrões de atribuição. Em 1º de janeiro de 2007, a regra previa que um ASN pertencente apenas ao espaço de quatro octetos estaria disponível mediante solicitação específica, enquanto a escolha padrão continuaria sendo um valor representável em dois octetos. O primeiro estágio, portanto, abria uma via voluntária para operadores preparados, sem impor uma mudança imediata àqueles que ainda dependiam de equipamentos, softwares ou pares legados.

Em 1º de janeiro de 2009, a presunção se invertia. Um ASN de quatro octetos passaria a ser o padrão, e quem necessitasse de um valor representável em dois octetos teria de pedir expressamente. Esse desenho fazia o recurso mais amplo se tornar a rotina e preservava o conjunto mais estreito para necessidades de compatibilidade declaradas. O relatório da AFRINIC-9, em 2008, serve como ponto de controle sobre como a organização descrevia o mapeamento dos conjuntos e lembrava a segunda fase; não comprova, por si só, que cada componente interno e cada rede cliente estivesse pronta.

Em 1º de janeiro de 2010, o cronograma eliminava a distinção de atribuição e previa um conjunto indiferenciado de quatro octetos. “Indiferenciado” dizia respeito ao método de seleção no inventário, não a uma transformação instantânea de toda a Internet. A política afirmou explicitamente que não implicava nenhuma outra mudança na política de atribuição de ASNs. Logo, a passagem tratada aqui não deve ser usada para reabrir critérios de qualificação, necessidades de roteamento ou condições de elegibilidade: seu objeto era a largura numérica e o padrão temporal de emissão.

Os intervalos ajudam a entender o problema, desde que não sejam confundidos com disponibilidade irrestrita. Um campo de dois octetos representa valores de 0 a 65535. A faixa que exigia quatro octetos segundo a política ia de 65536 a 4294967295, e o campo completo de quatro octetos abrange de 0 a 4294967295. Há reservas de protocolo e de registro; nem todo número representável estava livre para atribuição. Expandir o campo tampouco converte o número em bem, título, licença ou concessão soberana. Trata-se da capacidade de representar e coordenar identificadores únicos.

O benefício da sequência era real. Ela avisava fornecedores e operadores com antecedência, permitia experiência inicial antes que a escassez do conjunto estreito se tornasse mais aguda, invertia o padrão somente depois de dois anos e evitava um “dia da virada” em que todas as redes precisariam mudar simultaneamente. Sem cronograma, compras, atualizações e testes tenderiam a ocorrer em regime de urgência. Com uma obrigação imediata em 2006, redes com equipamentos incompatíveis poderiam ser excluídas artificialmente por uma decisão do coordenador privado.

Mas um padrão de emissão não é um comando ao plano de controle de uma rede. A AFRINIC podia programar seu motor de alocação, alterar formulários, treinar suporte e publicar registros. Não podia inserir uma implementação em roteadores de terceiros, corrigir um sistema de faturamento antigo, atualizar filtros nos pares, nem obrigar um fornecedor a eliminar um limite de 16 bits. A data da política cria uma pergunta de prontidão; não oferece a resposta.

Como a convivência técnica evitava uma virada simultânea

O desenho de compatibilidade disponível quando a política regional estava sendo discutida era incremental. O Internet-Draft de novembro de 2005 descrevia uma forma de um participante BGP anunciar, na abertura de uma sessão, se entendia números de sistema autônomo de quatro octetos. A negociação de capacidade permitia que cada par escolhesse a codificação compatível com os dois lados. Em vez de uma bandeira global acionada numa data única, a transição aconteceria por falante e por relação de vizinhança.

Quando um falante capaz de quatro octetos se comunicava com outro limitado a dois e o número real não cabia no campo legado, a visão antiga podia mostrar AS_TRANS, de valor numérico 23456, no AS_PATH. Esse substituto não entregava ao equipamento antigo uma compreensão mágica do novo número. Ele preenchia o espaço representável para que a sessão pudesse continuar. Informações mais ricas sobre o caminho eram carregadas em um atributo opcional e transitivo, de modo que um falante posterior, já compatível, pudesse reconstruir uma parte maior do caminho original.

A terminologia precisa seguir a cronologia. O rascunho de novembro de 2005 chamava os atributos de NEW_AS_PATH e NEW_AGGREGATOR. O RFC 4893, publicado em maio de 2007, padronizou os nomes AS4_PATH e AS4_AGGREGATOR, além da capacidade de quatro octetos e do uso de AS_TRANS. Não é correto escrever como se os nomes do RFC já fossem a nomenclatura final do rascunho usado no debate de 2005. Também não é correto tratar aquele rascunho como RFC ou o RFC posterior como prova de implementação em cada rede. A especificação descreve um mecanismo; a implantação precisa de outra espécie de evidência.

O mecanismo resolvia uma incompatibilidade fundamental, mas tinha limites. O RFC 4893 supunha que os falantes BGP dentro de um sistema autônomo seriam atualizados antes que esse sistema usasse um ASN de quatro octetos. Essa premissa coloca a responsabilidade técnica onde ela realmente está: na rede que opera o software e conhece seus equipamentos. Uma atribuição no livro-razão não satisfaz a premissa. Antes de ativar o novo identificador, o operador precisava conhecer versões, caminhos internos, pares externos e comportamento em falhas.

A agregação feita por um falante antigo podia descartar informação necessária para uma reconstrução perfeita. Dados inconsistentes entre o AS_PATH legado e o atributo de quatro octetos podiam mascarar um laço ou introduzir risco de roteamento e segurança. Por isso, “a sessão subiu” não era um teste suficiente. Era necessário observar anúncios brutos, reconstrução do caminho, ocorrência de AS_TRANS, pontos de agregação, detecção de laços e reação a atributos incoerentes. O rollback também deveria ser ensaiado antes de uma migração real, e não improvisado durante uma perda de alcance.

Convenções operacionais ao redor do BGP constituíam outro domínio de compatibilidade. Filtros, comunidades, modelos de configuração e ferramentas podiam embutir a suposição de que um ASN caberia em 16 bits. O RFC apontava comunidades estendidas específicas para ASNs de quatro octetos como caminho para usos comparáveis. Isso não significava que cada política local, script de geração de filtros ou plataforma de monitoramento passaria a usá-las automaticamente. A equipe precisava inventariar dependências e testar limites, inclusive aquelas que não apareciam na sessão BGP em si.

Assim se revelam quatro superfícies distintas. A primeira é a emissão: qual conjunto e qual padrão se aplicavam na data do pedido. A segunda é o protocolo no fio: capacidade, substituição por AS_TRANS, preservação e reconstrução do caminho. A terceira é o ambiente do operador: roteadores, softwares, filtros, comunidades, monitoramento e pares. A quarta é a identidade nos registros: largura de campo, notação, busca e reconciliação entre sistemas. O sucesso numa superfície não pode servir de atalho probatório para as outras três.

Quando 1.10 e 65546 precisam ser a mesma identidade

A política inicial usava a notação asdot em seus exemplos. Nela, o valor decimal 65546 poderia aparecer como 1.10. O RFC 5396, posterior ao ato de 2006, escolheu a representação decimal asplain para todos os ASNs justamente porque a convivência de notações gerava confusão operacional. A mudança parece visual, mas alcança busca, inventário e responsabilização: se um tíquete usa 1.10 e o WHOIS exibe 65546, um sistema ingênuo pode criar duas identidades para o mesmo número.

O controle adequado é armazenar um inteiro canônico de 32 bits separado da forma de exibição. A apresentação original deve ser retida como evidência histórica, junto da regra de conversão. Buscas precisam encontrar ambos os formatos; importações devem normalizar sem apagar o texto recebido; exportações devem declarar a notação. Um teste de ida e volta precisa provar que 1.10 se converte em 65546 e retorna à forma histórica quando necessário, sem colisão com outro registro.

O risco aumenta quando um banco de dados, uma API ou uma ferramenta de monitoramento aceita apenas 16 bits. O valor pode ser rejeitado, truncado, sofrer volta aritmética ou ser gravado de forma silenciosamente corrompida. Cada interface deve ser testada com valores limítrofes e acima do limite legado. Escritas com perda precisam falhar de modo visível. Logs de migração devem identificar a tabela, o campo, a versão do esquema, a linha afetada e a correção realizada.

Essa disciplina vale para o conjunto inteiro: solicitação, motor de atribuição, WHOIS ou aut-num, estatísticas delegadas, coletores de rota, tíquetes, filtros, CRM, faturamento e relatórios. A ausência de anúncio observado não torna automaticamente inválida uma atribuição; uma rede pode ainda não ter ativado o ASN ou um coletor pode não enxergá-la. O objetivo da reconciliação é explicar as diferenças, não forçar todos os sistemas a contar a mesma história mediante apagamento.

Um anúncio público de que os sistemas de alocação e WHOIS suportavam o conjunto completo é uma afirmação implementacional testável. Ele não garante que formulários de clientes, ferramentas externas, equipamentos ou bancos comerciais tenham a mesma capacidade. Da mesma forma, a padronização de asplain resolve uma convenção de texto, não a compatibilidade de todo o ecossistema. A precisão exige declarar qual componente foi observado e em qual data.

Do bloco da IANA às trocas: uma trilha que mostra avanço e atrito

O registro da IANA fornece um ponto de controle a montante: o bloco de 327680 a 328703 aparece atribuído à AFRINIC em 29 de novembro de 2006. Esse lançamento ajuda a reconstruir o inventário disponível antes da primeira fase, mas não informa quando ocorreu a primeira atribuição a jusante nem quando um desses valores apareceu pela primeira vez em roteamento. O saldo local deveria reconciliar recebidos, disponíveis, atribuídos, reservados e exceções, com ajustes documentados.

O material da AFRINIC-9, de 2008, mostra como a organização apresentava a transição pouco antes da inversão do padrão em 2009. Seu valor probatório é de briefing e acompanhamento: ele permite comparar o discurso de implementação com o cronograma e o mapeamento de conjuntos. Não substitui ordens de mudança de sistema, testes, tíquetes de atendimento ou resultados de laboratório. Uma auditoria precisa perguntar se o formulário, o motor de atribuição, o WHOIS, as estatísticas delegadas e os procedimentos de suporte foram alterados e quando cada alteração entrou em produção.

O relatório anual de 2012 afirma que a opção de escolher entre ASNs de 16 e 32 bits foi removida do formulário em 2011 e que, a partir daí, as atribuições vieram de um conjunto comum de 32 bits. Essa data é relevante porque ocorre depois do marco de conjunto indiferenciado de janeiro de 2010. Ela não prova por si só uma falha da fase de política; mostra que a forma de pedir ainda teve uma mudança posterior e que “política em vigor” e “cada interface já simplificada” são estados distintos.

Em 11 de maio de 2012, uma comunicação pública na lista RPD declarou que os sistemas da AFRINIC suportavam um conjunto indiferenciado e a representação asplain do RFC 5396. A mensagem data uma reivindicação pública de implementação. Não estabelece o primeiro momento exato em que cada sistema interno adquiriu essa capacidade, muito menos a prontidão universal dos operadores. É uma peça do dossiê, a ser confrontada com mudanças de código, registros públicos e experiências reais.

O mesmo relatório anual informa 145 ASNs atribuídos em 2012, dos quais seis eram de 32 bits, e relata trocas caso a caso motivadas por incompatibilidade de equipamento: ASNs de 32 bits com valores mais altos eram substituídos por valores mais baixos, ainda no espaço de 32 bits. O detalhe impede duas simplificações. Primeiro, quatro octetos estavam sendo usados de fato, ainda que em uma fração das atribuições relatadas. Segundo, a compatibilidade continuava produzindo exceções depois do marco de 2010 e do ajuste de formulário de 2011.

Em 2014, a NRO relatou, numa perspectiva de vários registros regionais, que roteadores incompatíveis levaram alguns clientes a devolver ou trocar ASNs de quatro octetos por ASNs de dois octetos. Esse registro reforça que o atrito não era puramente teórico. Não identifica, contudo, cada troca como caso da AFRINIC. A evidência regional específica e a observação multi-RIR devem permanecer separadas, sem extrapolar a amostra.

As trocas são o teste mais exigente do livro-razão. Substituir um número sem um vínculo imutável entre o registro antigo e o novo pode interromper continuidade técnica e contratual. O dossiê precisa mostrar motivo, sistemas afetados, autorização, atualização dos registros públicos, migração de rotas e encerramento. O ASN antigo não deve desaparecer; deve permanecer como referência histórica, com estado e datas. Só assim uma pessoa externa consegue distinguir correção controlada de perda de registro.

Esses marcos compõem uma trilha de progresso e fricção, não uma sentença simples de sucesso ou fracasso. O bloco de 2006 mostra inventário a montante. O briefing de 2008 mostra preparação declarada. O marco de 2010 muda a regra de emissão. A alteração de formulário em 2011 e o anúncio de 2012 registram implementação posterior. Os seis ASNs de 32 bits, as trocas e o relato de 2014 mostram uso e dificuldade. O resultado mais fiel é um processo gradual, mensurável e incompleto em componentes diferentes em momentos diferentes.

O arquivo necessário para provar implementação

Uma auditoria independente deveria conseguir percorrer a decisão sem aceitar a conclusão da instituição como premissa. O primeiro elo é o texto exato da proposta: referência, versão, metadados de publicação e uma cópia datada ou hash retido. O segundo preserva separadamente agenda e relatório da AFRINIC-4, resultado do consenso, datas da última chamada, Resoluções 200605.27 e 200611.34 e uma nota explícita sobre o conflito cronológico. Essa nota não “corrige” as fontes; impede que um banco de dados as comprima.

O terceiro elo é a implementação interna. Ordens de trabalho ou registros de mudança devem abranger formulário de solicitação, motor de alocação, esquema do WHOIS, estatísticas delegadas, documentação pública e suporte. Para cada componente, interessam versão anterior, mudança aprovada, responsável operacional, horário de implantação, teste e rollback. Sem isso, a resolução demonstra intenção e instrução, não execução.

O quarto elo é o inventário a montante. O recebimento do bloco 327680–328703 e a data de 29 de novembro de 2006 precisam ser conciliados com o estoque local. A equação deve fechar entre disponível, atribuído, reservado e excepcional, depois de ajustes explicados. Uma diferença sem justificativa é sinal para investigação, não motivo para arredondar ou reclassificar o saldo até que ele pareça correto.

O quinto elo é cada decisão de atribuição. O arquivo deve conter a solicitação, a preferência declarada, o padrão aplicável naquela fase, o inteiro decimal canônico, a forma histórica exibida, os horários do tíquete e o papel operacional responsável. Isso permite explicar por que um valor de dois ou quatro octetos foi escolhido numa data específica. Não se deve inferir que a pessoa pediu quatro octetos apenas porque recebeu um número alto depois de 2009; o padrão e as exceções precisam estar documentados.

O sexto elo pertence ao operador: versões de roteador e software, negociação de capacidade, testes de laboratório ou implantação limitada, revisão de filtros e comunidades, ferramentas de monitoramento, compatibilidade de pares e plano de retorno. A rede, e não o registro, conhece seu desenho interno e assume os efeitos de uma ativação. Evidência de prontidão precisa ser produzida por quem executa a mudança, ainda que o coordenador forneça ferramentas de teste e publique informações de compatibilidade.

O sétimo elo reconcilia a decisão com o mundo observável. Tíquete, banco de alocação, WHOIS ou aut-num, estatísticas delegadas e observação de rota devem concordar sobre o valor e as datas relevantes, ou explicar a divergência. O método de continuidade da NRS — verificar o dado atual, guardar cópias datadas e comparar organização, datas e contatos — ajuda a tornar a constatação limitada no tempo e reproduzível. Isso não faz da NRS um registro: ela pode pesquisar, defender, reunir e representar membros que a autorizaram, mas não opera alocação, RPKI, WHOIS, apelações, eleições, custódia ou continuidade.

O oitavo elo registra todas as exceções, devoluções e trocas. Número anterior e substituto, motivo, sistemas afetados, autorização, atualização pública, migração de rotas e fechamento devem formar uma sequência imutável. O método editorial do arquivo de alocação acrescenta uma pergunta útil: é possível reconstruir pedido, avaliação, aprovação, inventário e registro público, em vez de começar pela versão final e presumir que as etapas intermediárias existiram? Para este tema, a resposta deve incluir também teste e aceitação do operador.

Por fim, o conjunto probatório deve ser exportável. Se o acesso depender de uma única interface privada, um operador ou coordenador substituto não consegue verificar continuidade durante falha, disputa ou migração. Cópias portáteis, formatos documentados e identificadores canônicos reduzem a dependência institucional. Portabilidade não concede propriedade sobre o ASN; preserva a capacidade de provar o que foi registrado, quando, por quem e com qual efeito.

A melhor defesa do cronograma — e a melhor objeção

O caso mais forte a favor da decisão parte de uma restrição concreta: um campo finito de dois octetos não sustentaria indefinidamente novas atribuições. Um roteiro conhecido era preferível a uma corrida tardia. A primeira fase permitia adesão por pedido; a segunda fazia do espaço amplo o padrão somente depois de dois anos; a terceira retirava a distinção. O desenho de protocolo tolerava falantes novos e antigos numa transição incremental. Essa é precisamente a utilidade de uma camada comum estreita: coordenar sem exigir que todos mudem ao mesmo tempo.

Há ainda um efeito distributivo favorável. Ao reservar valores estreitos para compatibilidade documentada depois de 2009, o cronograma podia conservar uma margem operacional para redes que ainda enfrentassem dependências reais. Fornecedores recebiam datas para planejar suporte; operadores podiam inserir atualizações em ciclos de compra e manutenção; a AFRINIC podia desenvolver seus sistemas antes de tornar o padrão mais amplo. Sem esse sinal, os custos tenderiam a se concentrar perto do esgotamento.

A objeção mais forte, porém, não é negar a necessidade de transição. É negar que o calendário prove prontidão. Na AFRINIC-4, algumas pessoas ainda consideravam a questão prematura. A sequência formal continuou até novembro. Anos depois, relatórios ainda registravam formulários em alteração, equipamentos incompatíveis e trocas. O custo recaía sobre operadores que precisavam atualizar roteadores e softwares, testar em laboratório, reservar janelas, revisar filtros, comunidades, monitoramento, provisionamento, tíquetes, relatórios e coordenação com pares.

Para uma rede pequena com equipamento antigo, uma falha de interpretação podia virar perda de alcance ou uma reconfiguração cara. O registro assumia custos de desenvolvimento e suporte, mas podia transferir parte substancial do ônus de atualização e tratamento de exceções a terceiros. Se a exceção fosse opaca ou humilhante, o padrão técnico se tornaria mecanismo de exclusão. Como a AFRINIC não tinha autoridade regulatória, ela não deveria usar incompatibilidade como punição nem compelir implantação insegura apenas para cumprir uma data interna.

A solução não é abolir o cronograma nem tratá-lo como mandamento. É manter a sequência, publicar prontidão por componente, oferecer evidência de testes, documentar exceções e trocas, reconciliar notação e inventário e permitir adoção reversível. O coordenador informa o que seu livro-razão e seus sistemas conseguem fazer. O operador decide quando ativar, condicionado pelas relações reais de interconexão. A restrição de interoperabilidade é concreta, mas não transforma a decisão do coordenador em lei.

Os contrafactuais esclarecem o equilíbrio. Sem cronograma, há menos aviso e mais corrida. Com emissão e uso imediatamente obrigatórios em 2006, há risco de exclusão técnica artificial. Com cronograma, mas sem trilha de prova, a transição parece concluída no papel enquanto registros e redes divergem. Com padrões graduais, auditoria portátil e adoção baseada em código funcional, é possível administrar a escassez, testar a convivência e registrar exceções sem fabricar autoridade pública.

O escriturador privado e o limite da coordenação

A AFRINIC tinha um papel indispensável e estreito. Podia manter um livro-razão único, receber inventário a montante, registrar atribuições, mudar os padrões de solicitação, manter registros públicos compatíveis, publicar políticas datadas, documentar exceções e facilitar testes. Um ecossistema de identificadores não funciona se dois participantes puderem usar o mesmo número sem tratamento de conflito. A unicidade exige coordenação comum.

Nada disso significa que a AFRINIC possuía o ASN, a rede, a rota ou o operador. Uma linha num banco de dados não é um título de propriedade, licença estatal ou instrumento judicial. A Resolução 200605.27 não conferiu soberania, poder legislativo, regulatório, policial, acusatório, judicial, punitivo ou confiscatório. Tampouco o uso da palavra “consenso” produz legitimidade pública por si só. Os documentos mostram atos de uma instituição privada dentro de uma função técnica.

Essa distinção não diminui o impacto prático da decisão. Uma mudança de padrão no registro pode quebrar silenciosamente processos de infraestrutura se formulários, ferramentas e pares não acompanharem. O relato voltado a operadores da LARUS ajuda a formular esse risco de continuidade: governança de coordenação pode ter efeitos materiais mesmo sem força de lei. Impacto não é autoridade. Justamente porque o coordenador influencia condições operacionais, seus registros devem ser verificáveis, suas exceções transparentes e suas decisões reversíveis sempre que a unicidade permitir.

A doutrina do escriturador privado impede duas apropriações. A primeira seria a instituição alegar que, por registrar o número, criou o direito do operador e pode retirá-lo como sanção extratécnica. A segunda seria o operador confundir continuidade de uso e prova histórica com propriedade sobre o identificador. O objeto comum é a semântica estável, a validade determinística, a unicidade, o tratamento de conflitos, a interoperabilidade no fio e a prova portátil. Questões futuras permanecem locais, salvo quando a interconexão realmente exige acordo.

O teste decisivo é o código em funcionamento. Uma resolução pode alterar a fila de pedidos e ordenar mudanças internas. Não pode fazer um roteador antigo compreender um ASN de quatro octetos. A transição existe efetivamente quando implementações compatíveis negociam a capacidade, preservam o caminho, identificam o mesmo inteiro nos registros e são implantadas voluntariamente por operadores dispostos a assumir a mudança. O papel legítimo do coordenador é tornar esse caminho previsível e verificável — não substituir a realidade operacional por uma declaração.