Resumo

  • O dump oficial da AFRINIC, atualizado em 30 de agosto de 2026, contém 3.790 objetos RPSL com a forma exata remarks: Geofeed HTTPS-URL; 3.573 são objetos de endereço inetnum ou inet6num, o escopo relevante para a descoberta da RFC 9632.
  • O formato em remarks não é um erro. A RFC 9632 o define para bases sem geofeed: e exige que consumidores entendam as duas representações durante a migração.
  • Os schemas ativos de endereço da AFRINIC ainda exibem remarks:, mas não geofeed:. O arquivo público do DBWG registra um pedido de work item e avaliação de impacto, seguido de cobranças, sem disposição pública posterior encontrada até agosto de 2026.
  • Um recibo de migração limitado poderia registrar decisão, direitos de escrita, sintaxe, conflitos, tratamento do acervo, projeção WHOIS/RDAP, limites de autenticação e privacidade, testes e rollback.

O número 3.790 descreve o texto. O número 3.573 descreve o objeto. A diferença entre ambos descreve a dívida de schema.

Uma busca estrita no banco público da AFRINIC encontra 3.790 objetos com a sequência especificada pela RFC 9632: remarks:, o token Geofeed sensível a maiúsculas e minúsculas e uma URL HTTPS. Quando cada bloco RPSL é classificado, surgem 3.483 objetos inetnum e 90 inet6num. São 3.573 objetos de endereço.

As 217 ocorrências restantes estão em 168 objetos route, 41 route6, cinco domain, dois as-set e um organisation. A forma textual é exata; a classe não é aquela em torno da qual a RFC organiza a descoberta de endereços.

Isso não autoriza dizer que há 217 cadastros quebrados. Mostra apenas que remarks é um recipiente genérico. O mesmo campo pode carregar um ponteiro Geofeed, uma instrução operacional, um certificado ou uma nota administrativa. O significado existe porque produtores e coletores reconhecem uma convenção; o schema não sabe que o texto ganhou função de interface.

Por isso o título usa 3.573. O total de 3.790 mede a presença da string em todas as classes. O total de 3.573 mede os objetos de endereço pertinentes ao mecanismo normalizado. Uma auditoria responsável preserva os dois números e recusa a tentação de dar a ambos o mesmo nome.

O fallback merece ser defendido antes de ser substituído

A forma atual é um contrato de compatibilidade, não um improviso fora do padrão.

A RFC 9632 prevê que os RIRs evoluam em ritmos diferentes. Se a base ainda não implementou geofeed:, ela define o formato estrito em remarks:. Até que todos os produtores declarem suporte ao novo campo e os registrantes migrem seus objetos, os consumidores precisam aceitar os dois. Um coletor que pare de ler remarks antecipadamente passa a ser menos interoperável, mesmo que pareça mais moderno.

O mecanismo tem adoção material. Os 3.573 objetos apontam para 106 URLs HTTPS distintas. A distribuição inclui 3.461 ASSIGNED PA, 71 ALLOCATED PA, 17 ALLOCATED-BY-RIR, 13 ASSIGNED PI e 11 SUB-ALLOCATED PA. Uma mesma URL pode servir a diversos prefixos de um operador, portanto repetição não é, por si, defeito.

Esses dados não comprovam que toda URL responde, que toda localização está correta ou que todo serviço de geolocalização a utiliza. Comprovam que a convenção é parte do cadastro instalado. Uma migração que altere referências sem mapa e sem período de coexistência pode destruir compatibilidade real para obter limpeza abstrata.

Há também uma defesa operacional para a cautela. Um campo novo alcança autenticação de updates, formulários, e-mail, dump, WHOIS, RDAP, validadores, documentação e suporte. Objetos com as duas formas precisam de precedência. Variantes históricas precisam de tratamento. Clientes atualizam em calendários diferentes. Uma linha nova no template cria obrigações em várias superfícies.

A pergunta justa não é “por que a AFRINIC não copiou outro RIR?”. É “qual avaliação foi feita, qual decisão resultou e que prova mostrará que a transição preservou o que já funciona?”.

Quando metadado mora em prosa

A RFC 9632 afirma que a forma em remarks não pode ser verificada formalmente pelo RIR. Assim, a recomendação de no máximo uma referência por objeto também não pode ser imposta com precisão no schema. Um campo dedicado poderia validar HTTPS, limitar cardinalidade, apontar duplicidade e oferecer um valor estruturado para exportação.

O inventário mostra o custo da prosa. Há 3.592 objetos de endereço com alguma linha parecida com Geofeed sem considerar caixa. Cento e seis linhas fogem do formato estrito: algumas adicionam dois-pontos, outras usam minúsculas, outras usam HTTP. Não há evidência de que todos os coletores rejeitem cada variante. Há evidência de que o campo genérico não consegue barrar a deriva semântica.

Mesmo o campo perfeito resolveria apenas a primeira de três perguntas:

  1. Estrutura: esta é uma referência Geofeed sintaticamente válida para o objeto?
  2. Autoridade: quem publica o arquivo pode falar pelo espaço de endereços?
  3. Conteúdo: as localizações são corretas, atuais e cuidadosas com a privacidade?

HTTPS autentica o endpoint nomeado e protege o transporte; não autentica a alocação do espaço IP. Por isso a RFC descreve uma assinatura RPKI opcional para fortalecer o vínculo com um certificado de recursos. Ainda assim, uma assinatura não transforma cada cidade ou código de país em fato físico certificado.

Um campo dedicado deve assumir uma promessa pequena: reconhecer e validar o ponteiro. Não deve induzir uma promessa grande: garantir a verdade de todo dado no arquivo. Essa modéstia separa a função de registro da função de observação do mundo.

Um artigo anterior sobre APNIC já tratou do limite entre autenticar um link e acreditar em todas as localizações. O objeto exclusivo aqui é anterior: na AFRINIC, o link ainda não tem identidade própria no modelo.

A linha do tempo pública parou antes da decisão

Em 27 de outubro de 2025, um participante do Database Working Group propôs adicionar geofeed: e permitir atualização pelos titulares. Ele reconheceu remarks como alternativa atual e relatou que, em sua experiência com recursos PI, precisava da ajuda do hostmaster.

No dia seguinte, o cochair abriu duas semanas de discussão e pediu ao staff uma avaliação de impactos, com vantagens e desvantagens. Em 14 de novembro, após informar que não houve discordância, pediu que a AFRINIC tratasse a proposta como work item e explicasse como poderia implementá-la, incluindo a avaliação.

O proponente voltou a cobrar foco em 6 de abril de 2026. Em 16 de abril, o cochair pediu confirmação de que o item estava ativo e reiterou o pedido. Outro participante acrescentou apoio em 17 de abril.

O índice oficial mostra meses com mensagens em janeiro, fevereiro, março, abril e agosto de 2026, sem arquivos mensais em maio, junho ou julho. Nos tópicos examinados até agosto, não há assunto Geofeed posterior a 17 de abril.

A conclusão precisa é limitada: não foi encontrada resposta ou disposição posterior no arquivo público examinado. Isso não prova que o staff não trabalhou. Pode haver ticket interno, avaliação técnica, conversa privada ou dependência. A lista pública não contém todos os atos institucionais.

O que falta é um estado de fechamento para um pedido público. Aceito, adiado, recusado, incorporado a outro projeto ou dependente de condição: qualquer estado pode ser defensável. O silêncio não permite distinguir nenhum deles.

A amostra PI confirma o mecanismo, não a universalidade

O relato sobre PI pode ser confrontado com o dump. Há 13 objetos de endereço ASSIGNED PI com a forma estrita, e todos têm AFRINIC-HM-MNT em mnt-by. Maintainers ligados aos recursos aparecem em atributos inferiores.

O padrão é coerente com uma separação entre quem protege o objeto e quem administra objetos ou dados mais específicos. Não revela cada canal de suporte, exceção ou decisão de autenticação. Treze observações não permitem dizer que todos os titulares PI estão impedidos de atualizar.

Uma matriz seria mais útil: para cada classe, status e relação entre mnt-by e mnt-lower, quem pode incluir, alterar, retirar e corrigir a referência? Por qual interface? Com qual autenticação? Se a escrita direta não for possível, qual canal assume e qual protocolo comprova o resultado?

Explicar permissões não é liberar alterações sem controle. É tornar simultaneamente verificáveis a proteção contra abuso e o caminho para corrigir um dado antigo.

O exemplo RDAP mantém o significado dentro do texto

A resposta RDAP da AFRINIC para 160.115.0.0 contém uma URL Geofeed dentro de uma descrição genérica de remarks. Sua lista de conformidade declara rdap_level_0, nro_rdap_profile_0 e cidr0. Não declara geofeed1 nem oferece link estruturado.

A RFC 9877 define rel: geofeed e a extensão opcional geofeed1. Um servidor pode publicar esses links. Se anunciar a extensão, deve fornecer o link quando possui a URL e pode expô-la. Como a resposta observada não anuncia geofeed1, a ausência não demonstra descumprimento.

Ela demonstra uma escolha de interface. Um humano e um parser especializado reconhecem a URL. Um cliente RDAP geral não descobre pela conformidade que o serviço oferece Geofeed estruturado e precisa interpretar texto novamente. A informação atravessou a API; o tipo não atravessou.

O recibo que cabe no problema

Uma decisão verificável precisa registrar:

  1. ID, responsável, data de admissão, estado e próxima revisão do work item;
  2. versão atual e versão-alvo do schema;
  3. impacto em updates, dump, WHOIS, RDAP e coletores;
  4. direitos de escrita por classe, status e relação de maintainer;
  5. sintaxe HTTPS, cardinalidade e erros;
  6. convivência e prioridade entre as duas formas;
  7. inventário e destino de registros estritos, variantes e ocorrências fora das classes de endereço;
  8. decisão sobre geofeed1 e projeção RDAP;
  9. separação entre sintaxe, endpoint HTTPS, autoridade RPKI e exatidão;
  10. orientação de privacidade e granularidade;
  11. grupo de teste, compatibilidade, correção e condição de rollback;
  12. recibo de implantação ou encerramento com versão, data, métricas e exceções.

Esse recibo pode justificar adiamento. Pode manter remarks e melhorar apenas a documentação. Pode introduzir o campo sem migração automática e decidir RDAP depois. Prestação de contas não significa aceitar a proposta; significa deixar a decisão e seus limites disponíveis para verificação.

Um registro confiável não é aquele que se apresenta como fonte de toda verdade. É aquele que distingue o dado que estrutura da declaração que transporta. A AFRINIC não precisa garantir a geografia de cada endereço. Precisa dizer o que seu livro reconhece, quem pode corrigi-lo e como um pedido público chega a uma decisão pública.