Resumo

  • Em junho de 2024, a ARIN disse que a aceitação do padrão comum acionaria suporte a geofeed em RDAP, ARIN Online e Reg-RWS, mantendo a sugestão Open até a funcionalidade ser desenvolvida e implantada.
  • RFC 9877 virou um RFC Standards Track em outubro de 2025. Ele define geofeed1, rel=geofeed e application/geofeed+csv, oferecendo uma declaração de capacidade legível por clientes.
  • Em 12 de setembro de 2026, o registro ACSP ainda mostrava 2024.10 como Open. A resposta help do RDAP em produção não incluía geofeed1; um objeto de rede escolhido como exemplo mantinha a URL somente em Registration Comments.
  • Essas observações não provam inatividade nem ausência em toda a base. Elas sustentam um pedido mais limitado: um comprovante datado do gatilho, de cada interface, da migração, do acesso em massa, da privacidade, dos testes e do encerramento.

A condição externa deixou de ser o fim da conversa

Esperar por um padrão pode economizar anos de incompatibilidade. Se cada RIR inventasse seu próprio campo, clientes de RDAP carregariam cinco parsers e cinco conjuntos de exceções. A coordenação na IETF foi uma escolha sensata.

Só que uma condição pública precisa mudar de estado. Enquanto o texto está em elaboração, a pergunta é o que a comunidade técnica vai definir. Depois da publicação, a pergunta passa a ser como a definição entrou em cada produto e qual evidência permite reconhecer essa entrada.

A Sugestão ACSP 2024.10 foi apresentada em 3 de junho de 2024. Ela pedia um atributo geofeed opcional nos objetos de rede da ARIN. O caso prático era conhecido: colocar Geofeed [URL] em um comentário e depender de consumidores que extraíssem a URL de texto livre. O leitor humano reconhece a intenção; o software precisa adivinhar a gramática.

Na resposta de 7 de junho, a ARIN explicou que os cinco RIRs trabalhavam com a IETF em uma extensão RDAP. Quando o padrão fosse aceito, implementaria a mudança em RDAP e acrescentaria a função a ARIN Online e Reg-RWS. Citou ainda um formato consistente de download em massa. A sugestão permaneceria aberta até o desenvolvimento e a implantação da nova função.

Não houve prazo. “Aceito” não foi definido: publicação do RFC, aprovação anterior, perfil operacional comum ou outro marco poderiam satisfazer a palavra. Portanto, não há base para acusar descumprimento. Há, porém, uma obrigação de memória. Se o evento externo aconteceu, o registro público deve dizer qual etapa o substituiu.

O padrão criou uma promessa verificável do servidor

RFC 9877 foi publicado em outubro de 2025 como Standards Track. Não obriga qualquer servidor a implementar geofeed. Ele registra os elementos de uma implementação interoperável.

A relação geofeed identifica a função do link. O tipo application/geofeed+csv identifica o arquivo. O token geofeed1 declara que o servidor hospeda URLs de geofeed para objetos de rede IP. A IANA mantém esse identificador em seu registro de extensões RDAP.

Se um servidor usa geofeed1, precisa colocá-lo em rdapConformance na resposta help e nas respostas de lookup ou search que tragam objetos de rede IP. Quando possui uma URL para um objeto e pode devolvê-la, deve incluir o link correspondente. Isso permite que o cliente interprete uma ausência dentro de uma declaração explícita de capacidade.

Existe uma ressalva decisiva. O servidor pode usar a relação e o tipo registrados sem declarar geofeed1. Relações registradas cabem numa resposta RDAP comum. O token acrescenta uma promessa para o conjunto do serviço; não é pré-requisito absoluto para cada link tipado.

Essa diferença delimita a investigação. O help pode provar se a extensão foi declarada. Não pode provar que nenhum objeto, em nenhum lugar, contém um link padronizado.

Um help sem o token e um objeto com o comentário

Na captura de 12 de setembro de 2026, a resposta help da ARIN enumerava nível básico de RDAP, perfil NRO, CIDR, origin-AS, pesquisas RIR e outras extensões. geofeed1 não aparecia.

É legítimo dizer que aquela resposta não declarava a extensão naquele momento. Não é legítimo concluir que não exista código, piloto, planejamento ou dependência adicional. Um endpoint público descreve protocolo; não descreve o backlog privado.

O objeto 154.54.100.0/22, selecionado para ilustrar a convenção, continha Geofeed ai.net/geofeed.csv em Registration Comments. Seu rdapConformance também não trazia geofeed1; os links eram self, alternate e up, sem rel=geofeed.

O exemplo não é amostra aleatória. Ele não mede prevalência, não exclui links tipados em outros registros e não valida o conteúdo apontado. A URL é uma rota de descoberta fornecida pelo publicador, não prova de localização física, roteamento, identidade ou direito.

Mesmo assim, o objeto revela o problema de transição. Um campo novo precisa conviver com evidência textual antiga sem promovê-la ou descartá-la de maneira silenciosa.

A fala de abril de 2026 precisa ser conciliada

No ARIN 57, em abril de 2026, o relatório de engenharia citou melhorias de RDAP para geofeed e serviços de diretório RPKI. Disse que o trabalho passava naquele momento pela IETF. O RFC havia sido publicado cerca de seis meses antes.

Talvez a referência fosse a outro documento, a um perfil NRO, à coordenação de implementação ou a uma frase de apresentação que ficou desatualizada. A transcrição não oferece como escolher. Ela não prova paralisação.

Ela prova algo menor e útil: dois registros públicos precisam de reconciliação. Uma nota pode dizer que RFC 9877 está concluído e nomear a dependência atual. Corrigir a cronologia não é confessar falha; é impedir que um obstáculo antigo continue explicando uma decisão nova.

O deploy real está na passagem dos dados

ARIN Online é a superfície humana. Reg-RWS é a superfície de automação. RDAP é a publicação. O canal em massa serve consumidores que não deveriam coletar o universo por consultas individuais. A migração decide o que fazer com comentários existentes.

Cada superfície pode estar em fase distinta. O formulário pode aceitar a URL antes da API. Um objeto pode apresentar a relação registrada antes de o help declarar a extensão. A saída em massa pode usar um snapshot posterior. Chamar tudo de “implantado” elimina informação necessária para operar.

Comentários antigos também não formam uma coluna limpa. Pode haver uma URL inequívoca, duas URLs, instruções ao redor, destino morto ou uma frase que apenas menciona geofeed. Um parser que promova qualquer correspondência a campo tipado concede autoridade nova ao texto antigo.

Deixar tudo como está tampouco resolve. Clientes diferentes podem escolher comentário e link, mantendo caches divergentes. A migração precisa começar por inventário e classificação: claro, ambíguo, múltiplo, inacessível e fora de escopo. O titular confirma onde a autoridade muda. O texto original e a decisão ficam preservados. A precedência é publicada e a reversão permanece possível.

Objetos mais específicos exigem atenção particular. Um feed referente a um prefixo estreito não pode ser ignorado por um apontador amplo. A regra precisa aparecer nos testes e nos exemplos, não apenas numa leitura especializada do RFC.

Autenticar não é medir geografia

RFC 9632 explica descoberta em RPSL e um esquema opcional de autenticação com RPKI. A autenticação pode mostrar que a origem está autorizada para os recursos cobertos. Não comprova que máquinas, usuários ou tráfego estejam na localidade informada.

Quatro passos carregam quatro responsabilidades. O titular fornece a URL. A ARIN publica o apontador. Uma assinatura opcional reforça a procedência. O consumidor decide usar a alegação geográfica. Misturar os passos transforma infraestrutura de proveniência em selo de verdade física.

O link tipado torna a coleta eficiente. Isso é desejável, mas amplia o efeito de dados antigos. Retirada, cache, atualização, especificidade e privacidade passam a importar em escala. RFC 9632 diz que RDAP comum não deve ser o mecanismo de recuperação em massa. A menção da ARIN, em 2024, a um formato comum reconheceu que consulta transacional e distribuição completa têm necessidades diferentes.

Um produto em massa precisa de identidade do snapshot, horário, cobertura, hash, retenção e comportamento de retirada. O consumidor deve saber quando recebeu uma cópia velha e quando observou um dado ainda válido.

Como seria um comprovante público

O primeiro bloco fixa o gatilho: RFC 9877, erratas pertinentes, qualquer perfil NRO ou entre RIRs e a data em que a ARIN considerou a condição de 2024 satisfeita. Se restar outra dependência, ela deve receber nome.

O segundo bloco mostra uma matriz. ARIN Online, Reg-RWS, RDAP help, lookup/search de rede e saída em massa recebem estados definidos — projeto, teste, disponível, padrão, descontinuado ou concluído. O token, a relação e o tipo esperados aparecem junto de um exemplo positivo e um negativo seguros.

O terceiro bloco descreve escrita. Quais papéis podem adicionar e remover URLs, quais esquemas são aceitos, qual normalização ocorre, se há preview e o que acontece diante de indisponibilidade temporária. Falha de rede não deveria apagar uma escolha do titular sem consentimento.

O quarto bloco é a migração. Quantos comentários candidatos existem, como foram classificados, quais pedem confirmação, qual fonte tem precedência e como desfazer uma promoção errada. Estatísticas agregadas bastam; não é preciso divulgar URLs.

O quinto separa tempos: mudança aceita, leitura em ARIN Online, leitura em Reg-RWS, visibilidade em RDAP e entrada no lote. Consistência eventual pode ser bem administrada quando sua janela é conhecida.

O sexto lista testes: link válido, ausência, URL malformada, objeto mais específico, links por idioma, supressão e remoção. Inclui datas de deploy e rollback, a conciliação da fala no ARIN 57 e a disposição de ACSP 2024.10 ligada às evidências.

Menos certeza retórica, mais certeza operacional

Sem o comprovante, o crítico pode transformar ausência de geofeed1 em “nenhum trabalho foi feito”. A instituição pode transformar atividade interna em “produto entregue”. As duas inferências usam evidência fora de seu alcance.

Com o comprovante, a ARIN faz uma afirmação limitada e forte: estas interfaces, nesta data, seguem estas regras. O usuário testa a mesma fronteira. O estado Open não vira laudo de produtividade; um objeto não vira censo; a URL não vira local; a assinatura não vira medição.

A resposta talvez mostre uma dependência legítima ainda aberta. Talvez revele interfaces já prontas e documentação atrasada. A clareza não exige antecipar o resultado. Ela exige que o padrão, o produto e o registro público parem de operar em calendários sem conexão.

Fontes