Resumo

  • A AFPUB-2026-ASN-001-DRAFT02 propõe que cada novo AS-SET criado na base da AFRINIC tenha um nome hierárquico enraizado em um ASN controlado pelo criador autenticado. Essa é uma verificação estreita e útil: o catálogo pode recusar, no momento da criação, uma reivindicação nominal que não apresente a prova de controle exigida.
  • A verificação não cria propriedade, validade operacional, correção dos membros do conjunto, autorização de origem em RPKI nem obrigação de routing. A AFRINIC mantém um catálogo; o registro deve descrever a realidade verificável, não fabricá-la. Consenso, Board, equipe, contrato ou interface não convertem essa função administrativa em soberania.
  • Os AS-SETs planos existentes continuariam válidos e editáveis. Essa continuidade evita ruptura, mas conserva a ambiguidade legada. A restauração caso a caso de um nome apagado reabre a discricionariedade justamente onde a regra ordinária deveria permanecer determinística e auditável.
  • Em 9 de agosto de 2026, duas páginas oficiais da AFRINIC apresentavam estados processuais incompatíveis: “Under Discussion” no índice e “Last Call” na página da proposta, que também registrava apresentação no AF37 em 24 de junho. Não havia prova examinada de ratificação, implantação concluída ou validação uniforme em produção.

Um operador que recebe uma expansão divergente ou vazia já está diante do efeito tardio. Precisa descobrir qual base respondeu, qual objeto foi expandido, que membros vieram dele e se a automação deve continuar. A DRAFT02 atua antes desse momento. Ela pergunta se um novo nome que declara um ASN em sua raiz foi criado por quem demonstrou controlar a autenticação daquele ASN.

Essa pergunta pertence ao núcleo legítimo de um catálogo. Um registro comum precisa distinguir entradas, evitar reivindicações nominais conflitantes, guardar a cadeia de controle e permitir que consumidores entendam a proveniência do que consultam. O catálogo pode exigir uma prova objetiva para aceitar uma nova entrada. O que ele não pode fazer é inverter a relação e anunciar que a entrada produz a realidade que deveria apenas registrar.

O nome não cria a rede. A aceitação na base não cria o controle econômico, jurídico ou operacional do ASN. A rejeição de um nome também não desfaz o routing, não decide um acordo de peering e não torna ilegítima a política local de um operador. A AFRINIC pode dizer o que sua própria base conseguiu verificar. Não pode usar essa verificação como título sobre o mundo externo.

Esse limite é decisivo porque uma regra tecnicamente estreita pode ser descrita de dois modos. No primeiro, correto, a AFRINIC melhora a exatidão prospectiva do catálogo: novos nomes ancorados em ASN só entram quando o solicitante apresenta a autenticação correspondente. No segundo, falso, a instituição imagina que seu reconhecimento concede legitimidade ao nome, ao conjunto ou à política de routing que o utiliza. A DRAFT02 só se sustenta no primeiro modo.

O defeito específico dos nomes planos

As instruções publicadas pela AFRINIC para o IRR no MyAFRINIC descrevem nomes planos iniciados por AS- e autorização por senha do mantenedor. A senha prova que alguém autorizado pelo objeto de manutenção executou a operação. O rótulo, porém, não demonstra por si só qualquer vínculo entre o criador e a identidade que o nome parece representar.

É possível, portanto, autenticar corretamente uma operação sem que o próprio nome carregue uma prova sobre sua raiz. Esse é um defeito de exatidão do espaço de nomes, não uma autorização para governar o conteúdo do AS-SET nem a conduta de quem o consulta. A diferença parece pequena, mas organiza todo o caso: autenticação da transação não é o mesmo que prova da reivindicação inscrita no nome.

James Bensley, da Inter.link GmbH, submeteu a DRAFT02 em 8 de junho de 2026. O texto propõe uma nova seção 7.8 para exigir nomes hierárquicos em novos AS-SETs da AFRINIC. O primeiro componente seria AS seguido de um ASN; o segundo, um nome de AS-SET iniciado por AS-; componentes posteriores poderiam ser ASNs ou outros nomes de AS-SET. A forma mínima pode ser representada como AS<ASN>:AS-<nome>.

Os dois-pontos dividem níveis de uma cadeia. Para criar o primeiro conjunto abaixo da raiz, o solicitante teria de autenticar-se com os detalhes de autorização ligados ao ASN que aparece no primeiro componente. Sem essa prova, a via ordinária recusaria a criação. Para descendentes mais profundos, o RFC 2622 atribui a autorização ao mantenedor do conjunto-pai imediato.

A cadeia permite uma delegação reconhecível. O controlador autenticado do ASN abre o primeiro ramo. O mantenedor de um conjunto-pai pode criar o filho seguinte. Cada nível informa de onde veio a capacidade de criar o próximo nome. Essa gramática protege uma reivindicação limitada: quem abriu aquela posição do catálogo apresentou a prova exigida pelo nível anterior.

Ela não sustenta uma reivindicação ilimitada. O controlador da raiz não passa a possuir todas as políticas de routing associadas ao nome. O mantenedor do pai não se torna soberano sobre redes listadas como membros. A AFRINIC, por verificar a cadeia, não se apropria dela. O teste autentica uma criação no catálogo; não coroa nenhum dos participantes.

Especificação, catálogo e running code

O RFC 2622, publicado em junho de 1999, define a sintaxe e a semântica dos nomes hierárquicos em RPSL. Também atribui ao mantenedor do pai a criação de um filho. O próprio RFC, contudo, deixa os processos de registro fora de seu alcance. Ele fornece a gramática; não transforma a AFRINIC, ou qualquer outro registro, em autoridade sobre redes.

Essa distinção impede um erro comum. A existência de uma sintaxe padronizada não significa que todas as bases a imponham. A publicação de uma proposta não significa que o software a execute. A aprovação por um processo interno, se ocorrer, não torna a regra uma realidade operacional universal. E o funcionamento do validador não cria um veredito sobre o mérito de uma política de routing.

Há, na verdade, quatro planos separados. O RFC descreve uma forma. A proposta declara a mudança que seu autor deseja para o catálogo da AFRINIC. A equipe avalia como poderia implantá-la. WHOIS, MyAFRINIC e APIs decidem, pelo código efetivamente executado, se uma solicitação é aceita ou rejeitada. Depois disso, cada operador escolhe fontes, expande conjuntos, produz filtros e decide o que instala.

Nenhum desses planos recebe soberania dos demais. O processo de política pode organizar uma escolha institucional, mas não é legislatura. A equipe pode avaliar sistemas e custo, mas não é fonte de autoridade sobre o operador. O Board não aparece no pacote como criador da regra e, ainda que praticasse um ato corporativo, um ato corporativo não fabricaria poder público. O RSA não transforma manutenção de catálogo em jurisdição sobre routing. A realidade continua com as redes que a executam.

É por isso que Running-Code Primacy não é uma perspectiva entre outras. É o teste que separa coordenação de governo privado. Uma regra só ganha efeito técnico onde participantes a implementam e dependem dela. Publicação não é realidade. Consenso não é realidade. Uma etiqueta processual não é realidade. O catálogo descreve o estado que conseguiu verificar; não declara uma obrigação universal por ter preenchido um campo.

Uma camada comum legítima e estreita

A exigência de autenticação na raiz cabe na camada comum porque responde a condições localmente verificáveis. O serviço recebe o nome, identifica o ASN, consulta a autorização e aceita ou rejeita a solicitação. Sintaxe, conflito nominal e prova de controle são objetos de coordenação. O resultado pode ser repetido em cada canal e auditado contra o mesmo predicado.

Esse desenho protege quatro bens sem exigir um soberano. Primeiro, melhora a exatidão: o rótulo novo passa a carregar uma relação verificável com o ASN raiz. Segundo, fortalece a prova de controle: a criação depende da autenticação associada ao recurso declarado. Terceiro, reduz uma classe de colisão prospectiva dentro da base que aplica a regra. Quarto, melhora a coordenação de rotas porque o consumidor recebe um sinal de proveniência mais forte antes de decidir como usar o conjunto.

O quarto benefício precisa permanecer bem delimitado. Melhor coordenação não é imposição de política. Um provedor pode rejeitar o conjunto, preferir outra fonte, exigir confirmação bilateral, combinar sinais ou não usar AS-SETs. A regra de entrada não escolhe por ele. A coordenação funciona justamente porque fornece informação comum e deixa a decisão posterior com quem opera a rede.

Também não há punição. Uma tentativa sem a autenticação exigida deve ser rejeitada como transição inválida para aquele catálogo, não tratada como desobediência, fraude presumida ou base para qualquer sanção sobre recursos, serviços ou redes. Estado inválido é recusado localmente. Não se cria um processo moral contra quem não conseguiu ou não quis criar o objeto.

Esse é o sentido de uma especificação inicial mínima. A camada comum define somente o necessário para que o nome seja único dentro de sua regra, verificável e ligado a uma prova de controle. Escolha de fonte, política de peering, composição dos membros, filtros e estratégia operacional permanecem locais. A segurança da regra vem de sua estreiteza, não de uma promessa de boa governança.

O que a proposta não valida

Uma raiz autenticada não comprova a correção dos membros do AS-SET. O mantenedor autorizado pode inserir uma entrada desatualizada, omitir um membro, cometer um erro ou deixar de fazer manutenção. A DRAFT02 não cria revisão de conteúdo e não afirma que cada ASN listado autorizou sua presença.

A proposta também não alcança route-sets nem outros tipos de conjuntos em RPSL. Não corrige route objects antigos, não resolve resíduos de transferências, não elimina membros duplicados e não trata a confiabilidade geral do IRR. Esses assuntos pertencem a objetos e ciclos de vida diferentes.

RPKI permanece separado. A avaliação da equipe colocou o sistema entre os que não exigiriam mudança. A fonte da NRS examinada também distingue o contexto de política de routing do IRR da autorização criptográfica de origem fornecida por RPKI. Um nome hierárquico não é ROA, não substitui validação de origem e não certifica que todo anúncio observado é correto.

Por fim, a regra não governa o consumo. Um resolvedor pode combinar bases, aplicar precedência, preservar qualificação de fonte, lidar com conjuntos vazios ou usar cache. Um gerador pode transformar a expansão em filtros diferentes. O comportamento que converte ambiguidade em bloqueio, vazamento ou operação normal depende dessas escolhas locais. O pacote factual não contém um traço reproduzível que permita quantificar esse efeito.

O mecanismo de colisão e o limite da prova

O proponente afirma que nomes de AS-SET não são únicos entre os IRRs operados pelos cinco registros regionais e que resolvedores que agregam fontes podem devolver uma expansão errada ou vazia. A alegação descreve um mecanismo plausível. RFC 2622 não cria uma autoridade global sobre todos os bancos, e nomes planos podem reaparecer em namespaces autônomos.

Uma análise operacional da MANRS mostrou a diferença de autorização entre as duas formas. Um mantenedor não relacionado conseguiu criar um nome plano, enquanto a criação de um nome hierárquico ancorado em ASN falhou sem a autorização correspondente. O mesmo material documentou AS-AMAZON em RADB e RIPE. Isso prova um exemplo de colisão e um contraste no teste de criação. Não prova intenção maliciosa.

O exemplo também não fornece uma taxa. As fontes examinadas não continham inventário de AS-SETs planos da AFRINIC, denominador de colisões entre bases, série de incidentes ou cálculo de perdas. Não se sabe quantas vezes uma divergência resulta em expansão vazia, filtro incorreto ou dano. O mecanismo pode ser verdadeiro e o benefício da correção pode ser real sem que se invente uma incidência.

O proponente também afirma que, se a AFRINIC implantar a proposta, a ocupação indevida de nomes entre os cinco grandes RIRs deixará de ser possível. As provas disponíveis não sustentam essa conclusão ampla. A ARIN havia colocado a funcionalidade numa lista de trabalho futuro, sem anúncio de produção. As fontes técnicas da LACNIC mostravam uso hierárquico, mas não documentavam, por si sós, rejeição em todo caminho de criação. Nomes planos legados continuariam. IRRs de terceiros permaneceriam fora da regra.

A conclusão exata é mais estreita: se o mesmo teste for implantado em todos os caminhos da AFRINIC, novas entradas ASN-rooted daquele catálogo terão uma cadeia prospectiva de controle mais forte. Esse ganho não cria unicidade global. Ele melhora a verdade que uma fonte pode afirmar sobre as entradas que aceitou.

O legado não deve ser tratado como propriedade da instituição

A DRAFT02 protege os AS-SETs já existentes em três pontos. Não exige renomeação. Permite que nomes planos continuem em uso. E impede que uma edição ordinária acione uma mudança de nome. A decisão evita que referências instaladas sejam quebradas por uma reforma do catálogo.

Essa proteção é correta porque o registro não criou a realidade que passou a depender do nome. Scripts, documentos, acordos de peering e configurações podem ter incorporado a referência. A AFRINIC não adquire o direito de interrompê-los só porque decidiu mudar o formato preferido de novas entradas. Continuidade operacional prevalece sobre a estética de uma migração total.

Preservar o legado, porém, conserva a ambiguidade. Um nome plano que aparece em mais de uma base pode continuar produzindo respostas diferentes. A regra prospectiva não apaga o estoque, e não existe contagem oficial que permita calcular quando os nomes enraizados passariam a predominar. A transição depende de novas criações e aposentadorias voluntárias.

Essa consequência não legitima uma renomeação forçada. Mostra apenas o preço honesto da não retroatividade. O catálogo pode melhorar as novas entradas sem transformar as antigas em reféns. O operador continua livre para qualificar a fonte, migrar voluntariamente, substituir referências ou manter a configuração que considera compatível com sua rede.

A permanência de nomes planos tampouco concede à AFRINIC propriedade sobre eles. O registro guarda a entrada e a história disponível. Ele não cria a identidade operacional que o mercado e as redes passaram a reconhecer. A função correta é refletir essa história com exatidão, inclusive quando a forma antiga já não seria aceita para uma criação nova.

A restauração deve corrigir o catálogo, não conceder favores

A exceção é o ponto mais perigoso do texto. A DRAFT02 manda a AFRINIC permitir exceções caso a caso e apresenta a restauração de um AS-SET plano apagado por engano como exemplo. Há um problema real de continuidade: a exclusão pode ocorrer enquanto o nome ainda é usado em sistemas externos, e a via comum não permitiria recriá-lo.

Mas “caso a caso” não pode significar permissão soberana. A instituição não recebe autoridade para decidir quem merece um nome plano. Ela deve apenas reconstruir, a partir de evidência verificável, se o pedido corrige o catálogo para refletir uma continuidade anterior. O teste precisa permanecer ligado à realidade, não à preferência do administrador.

Hoje, segundo o pacote, esse teste não está publicado. O texto não identifica o decisor, os critérios de elegibilidade, o limiar de prova, o prazo, a revisão, a expiração ou o desenho de auditoria. Também não explica se o objeto restaurado preservaria mantenedor anterior, data original, histórico de alterações ou marca de restauração. Sem essas condições, duas decisões semelhantes podem divergir sem que o consumidor entenda por quê.

A equipe da AFRINIC reconheceu o risco em sua avaliação de 15 de junho. Ela advertiu que restauração ou recuperação poderia se tornar uma brecha operacional e prejudicar o objetivo da proposta; sugeriu documentar a razão da exceção. Essa é uma constatação atribuída à equipe, não uma concessão de autoridade. Documentar razões é insuficiente se o predicado que autoriza a restauração continuar oculto.

Uma justificativa posterior pode explicar o que alguém fez. Não torna a decisão legítima nem reproduzível. Para preservar a natureza estreita da regra, a restauração precisaria demonstrar, por evidência do próprio histórico, que uma entrada existia, que houve exclusão e que o solicitante mantém a continuidade de controle relevante. O objetivo seria corrigir um apagamento, jamais outorgar um rótulo novo por conveniência.

A experiência documentada da RIPE Database marca a fronteira oposta. Nomes planos existentes podiam ser atualizados ou apagados, mas um nome apagado não poderia ser recriado. Essa opção elimina a discricionariedade e acelera a convergência, ao custo de tornar um erro mais difícil de desfazer. Ela é um comparador, não um árbitro para a AFRINIC.

As duas alternativas expõem o verdadeiro desenho. Uma proibição absoluta protege a regra, mas pode sacrificar continuidade. Uma restauração probatória protege continuidade, mas exige critérios determinísticos, trilha de auditoria e um resultado limitado à correção do registro. Uma dispensa opaca não protege nenhum dos dois: mantém o custo da regra e reabre a permissão administrativa.

Nenhuma interface pode criar uma soberania lateral

A avaliação da equipe distribuiu impacto por seis sistemas. WHOIS e a interface IRR do MyAFRINIC exigiriam alterações diretas. RDAP refletiria os dados do WHOIS. NetSuite, NMRP e RPKI foram classificados como sem mudança. Essa avaliação descreve planejamento da equipe; não prova implantação.

No WHOIS, o serviço precisaria validar a forma, identificar o ASN raiz e consultar a autorização correspondente. O MyAFRINIC teria de impedir combinações inválidas e orientar o solicitante. APIs teriam de produzir o mesmo resultado. Variações de caixa, pais inexistentes, níveis aninhados, exclusão e restauração exigiriam tratamento consistente.

Se uma interface recusar um nome plano e outra aceitá-lo, a regra não existirá como invariante. Existirá apenas uma preferência de tela. Objetos semelhantes poderão nascer sob garantias diferentes, e corrigir o software depois não apagará automaticamente as entradas criadas no intervalo. A autoridade nominal prometida pelo texto dependerá do canal usado, o oposto de uma regra comum.

A AFRINIC anunciou a integração do IRR ao MyAFRINIC em produção em 14 de abril de 2020, com senha de mantenedor e PGP opcional. Essa base de autenticação ajuda a explicar por que a equipe considerou a mudança viável. Ainda assim, viabilidade atribuída à equipe não substitui testes de produção.

Running-Code Primacy exige evidência observável. O mesmo pedido, com a mesma prova, deve receber a mesma resposta no servidor, no formulário e na API. O teste não precisa de um Board para se tornar verdadeiro. Precisa de código que aplique o predicado e de operadores que decidam confiar no sinal produzido.

A cronologia não prova vigência

A DRAFT01 foi submetida em 15 de maio de 2026. A DRAFT02 veio 24 dias depois, em 8 de junho, após comentários e com a disposição explícita sobre exceção. Em 15 de junho, sete dias depois, a equipe datou sua avaliação. A página registra apresentação no AF37 em 24 de junho, nove dias após a avaliação.

Em 9 de agosto, as superfícies oficiais divergiam. O índice de propostas classificava o texto como “Under Discussion”. A página individual exibia “Last Call”. Nenhuma fonte examinada explicava a discrepância. Escolher a etiqueta mais avançada seria transformar uma inconsistência documental em conclusão.

Também não havia, nas fontes examinadas, anúncio de ratificação, texto final incorporado ao CPM, nota de versão do WHOIS ou teste de aceitação em produção. A avaliação publicada estava marcada “v1 Draft / Internal”. Ela prova que a equipe publicou uma análise e fez determinadas estimativas. Não prova que a proposta entrou em vigor.

A equipe vinculou capacidade de entrega ao MyAFRINIC v2, então esperado para 15 de novembro de 2026, e disse que a política seria priorizada depois. A data ficava 98 dias após o corte desta investigação. Era uma expectativa atribuída à equipe, não um compromisso de implantação já cumprido.

Mesmo uma futura ratificação não criaria a realidade de routing. No máximo, produziria um ato interno sobre o catálogo. A realidade técnica começaria onde o teste passasse a ser executado e onde os consumidores escolhessem aceitar o sinal. O consenso do processo não possui poder para converter um nome em verdade universal.

Comparadores não fabricam consenso global

As fontes oficiais de APNIC e RIPE NCC fornecem os dois comparadores com implantação diretamente verificada. A APNIC registra a prop-151 como implementada e preserva objetos existentes. A RIPE Database implantou a restrição NWI-19 na versão 1.105, em 13 de dezembro de 2022, também sem renomear o legado.

Esses fatos mostram que uma validação prospectiva pode coexistir com nomes antigos. Não provam que a escolha é soberanamente correta nem que a mesma regra deve vincular todos. Cada base descreve a prática que adotou; cada operador continua responsável pelo modo como usa suas fontes.

Na LACNIC, as páginas técnicas examinadas apresentam nomes hierárquicos ancorados em ASN. Elas corroboram uso, mas não bastam para afirmar rejeição uniforme de toda criação plana. A limitação é da prova consultada; não autoriza inferir ausência de enforcement.

Na ARIN, o Conselho Consultivo rejeitou em 30 de abril de 2025 uma proposta sobre o tema por considerá-la fora do escopo de política de recursos numéricos e direcionou o assunto ao processo de sugestão de serviço. Depois de consulta entre 23 de abril e 23 de maio, a ARIN informou em 30 de maio que a funcionalidade entraria numa lista de trabalho futuro. Não anunciou implantação.

O quadro, portanto, não sustenta a imagem de cinco RIRs já alinhados. Dois tinham enforcement verificado nas fontes. Um mostrava uso sem documentação completa de todos os caminhos. Um tinha trabalho futuro. A AFRINIC mantinha um rascunho com etiquetas processuais incompatíveis. IRRs de terceiros não estavam sujeitos a nenhum desses atos.

Não há vergonha nessa ausência de um centro. A autonomia das fontes é uma condição do sistema. A coordenação melhora quando regras estreitas são verificáveis e adotadas; não quando uma instituição tenta converter convergência parcial em mandato global.

A defesa mais forte: fonte explícita e decisão local

O argumento contrário mais forte é que nomes hierárquicos não são necessários nem suficientes para resolver a ambiguidade entre bases. Um operador já pode qualificar a fonte. O registro público da Google LLC no PeeringDB identifica o ASN 15169 e a referência RADB::AS-GOOGLE, preservando fonte e objeto em um único identificador.

Um resolvedor pode aplicar precedência explícita, e um gerador pode manter a qualificação ao produzir filtros. RPKI pode validar origem. Verificação bilateral pode confirmar intenção. Nomes hierárquicos voluntários podem ser usados onde a sintaxe é aceita. Nenhuma dessas práticas depende de a AFRINIC declarar o objeto legítimo.

Essa defesa acerta ao preservar o operador como decisor. Também acerta ao lembrar que a forma do nome não corrige membros, objetos antigos, fontes externas ou comportamento inseguro do consumidor. Sem inventário e incidência mensurada, não há base para quantificar economia ou redução de incidentes.

Mas a qualificação de fonte e a autenticação de raiz ocupam momentos diferentes. A primeira administra a leitura depois que o objeto existe. A segunda impede, numa base que a aplique, uma classe de reivindicação nova sem prova. Um controle não precisa anular o outro. Ambos podem permanecer estreitos e sob decisão operacional.

O resultado correto não é escolher a AFRINIC em lugar do operador. É oferecer ao operador uma informação melhor. A base diz: esta nova entrada passou pela autenticação do ASN raiz. O operador responde: aceito, combino, verifico ou ignoro esse sinal conforme minha política. O catálogo serve; não manda.

O que permanece desconhecido

Não se sabe qual etiqueta processual era formalmente correta no corte: “Under Discussion” ou “Last Call”. Não se sabe se houve adoção ou implantação posterior. Não há inventário de nomes planos da AFRINIC, colisões inter-registro, incidentes nem perdas. Não há regra publicada para a exceção, identidade do decisor, recurso ou auditoria.

Também não se sabe como uma restauração preservaria histórico e mantenedor; se toda interface da LACNIC rejeita nomes planos; quando a ARIN implantará sua funcionalidade, se o fizer; se todos os caminhos da AFRINIC aplicarão a mesma validação; se o MyAFRINIC v2 e o trabalho posterior seguirão o calendário; ou qual configuração de consumidor converte uma ambiguidade em dano.

Essas incertezas limitam alegações factuais. Não tornam incerto o limite da instituição. Nenhuma atualização de status, implantação de interface ou taxa de colisão poderia transformar a AFRINIC em proprietária da realidade de routing. Evidência futura pode demonstrar que o catálogo ficou mais exato. Não pode produzir uma soberania que a função nunca teve.

Julgamento

A AFPUB-2026-ASN-001-DRAFT02 contém uma correção valiosa quando lida na escala correta. A criação de um novo nome ASN-rooted pode ser vinculada a uma prova de controle verificável. Essa regra reduz a dependência de rótulos planos e melhora a proveniência prospectiva de entradas na base da AFRINIC.

Seu mérito termina onde termina o teste. Ela não valida conteúdo, não decide fonte, não instala filtro, não muda RPKI, não governa IRRs externos e não reescreve o legado. Não concede à AFRINIC poder sobre redes. O registro descreve uma relação de autenticação; não cria a realidade operacional, jurídica ou econômica que a relação pretende refletir.

A exceção só é compatível com essa função se corrigir, por prova reproduzível, um erro no catálogo. Se funcionar como favor, dispensa ou julgamento de merecimento, a AFRINIC deixará de verificar e passará a conceder. Esse é o ponto em que o mantenedor do livro começa a confundir a proximidade do registro com autoria sobre o mundo.

Nenhum processo pode reparar essa confusão. Consenso pode aconselhar. Board pode praticar atos corporativos. Equipe pode escrever e implantar código. RSA pode organizar uma relação contratual. Nenhum deles fabrica soberania. A única promessa defensável é mais simples: nomes novos que exibem uma raiz devem apresentar a prova daquela raiz, e o catálogo deve conservar uma trilha fiel do que verificou.

Os dois-pontos são um instrumento de exatidão. Não são uma coroa.

Fontes