Resumo

  • Andy Clyde disse no RIPE 93 que a equipe Internet Society/Pulse usa a PeeringDB para analisar pontos de troca e precisa de registros desde 2019 para refazer cálculos.
  • O rascunho v3 estabelece metas para dados atuais, exclui consultas históricas desse cronômetro e exige uma janela de retenção publicada sem definir ainda sua duração.

Um endpoint pode ficar mais rápido sem conservar a história que o pesquisador procura. No painel da PeeringDB no RIPE 93, Andy Clyde falou como usuário analítico, não como operador que precisa atualizar um roteador. Adaptar o cliente ao rascunho da nova API talvez leve algumas semanas, estimou. Voltar aos dados de 2019 e processá-los outra vez é uma exigência diferente.

Na transcrição oficial, Clyde cita o rastreador de IX e pede também dados de tráfego, classificação de redes e tipos de conjuntos de dados. Reconhece que parte disso pode estar fora do escopo da PeeringDB. Manter duas APIs custa trabalho dos dois lados. Mas reescrever o programa resolve uma troca de interface; não repõe observações antigas que deixaram de ser servidas.

O rascunho oficial da v3, de 18 de setembro, prevê leitura pública ao lado da v2, sincronização incremental e instantâneos diários. A meta é expor 99% das mudanças atuais em até um minuto. Percursos históricos ficam expressamente fora dessa conta. O texto manda publicar por quanto tempo dados antigos continuarão disponíveis, sem fornecer um número. Os endereços dos dumps existentes permanecem como estão nesta proposta.

A pergunta de Clyde cabe numa verificação simples: qual é o registro mais antigo que um analista consegue recuperar, e conseguirá repetir a mesma análise no ano seguinte?