Resumo

  • O rascunho da API v3 da PeeringDB propõe um serviço público, somente para leitura, distribuído em vários locais, com metas de disponibilidade e atualização dos dados.
  • A proposta ainda está em consulta: as regras de acesso e a especificação completa da API estão pendentes, e não há dados de desempenho em produção.

O rascunho estabelece prazos para uma API futura, mas não informa quando ela entrará no ar. O documento da PeeringDB, datado de 18 de setembro, define disponibilidade mínima de 99,95%, prevê que 99% das mudanças apareçam em até um minuto e estabelece um limite de 15 minutos para respostas com os dados mais recentes, incluindo o atraso de cache. Não há data de implementação. O próprio status descreve o texto como uma primeira chamada para comentários e revisão.

A atualização da PeeringDB publicada pela APNIC em 7 de outubro explica a motivação. Leo Vegoda, gerente de produto, aponta duas frentes: separar leitura e escrita para permitir a distribuição em vários locais e tornar mais eficientes as consultas entre objetos relacionados. Ele pede contribuições de quem usa a API antes da implementação. O contrato detalhado está no documento da PeeringDB; a APNIC é o canal de publicação, não quem opera a API.

O escopo inicial é restrito. A versão 3 seria pública e somente para leitura, ao lado da v2; as gravações continuariam na v2. A primeira busca cobriria nomes e números de sistemas autônomos. Visões privadas ou diferentes por chave, expansão de relações em profundidade, busca textual ordenada por relevância e consultas espaciais ou de distância ficam fora da primeira entrega. Objetos planos, sincronização incremental e instantâneos diários serviriam para que os usuários criem e atualizem suas próprias cópias. As respostas identificariam a versão do conjunto de dados, e um endpoint de versão informaria a atualização da fonte.

As metas de atualização têm fronteiras definidas. A medição começa quando a fonte muda e termina quando uma resposta com os dados mais recentes é servida; o atraso de cache entra nessa conta. Instantâneos diários, consultas históricas, espelhos de terceiros e o intervalo de consulta escolhido pelo cliente ficam de fora. O limite de 15 minutos é para alertar, não para interromper o serviço. O rascunho diz que uma falha na meta deve gerar alerta, sem parar o atendimento.

Isso interessa a operadores que consultam a PeeringDB para examinar redes, instalações e relações com pontos de troca. O projeto propõe uma meta para a atualização da visão pública; não comprova que os registros sejam completos nem que os dados mantidos pelos participantes estejam corretos. A PeeringDB também não é um plano de controle de roteamento: o texto não muda alocações dos RIRs nem decisões de BGP.

Ainda faltam definições antes de qualquer implementação. O OpenAPI deverá fixar a sintaxe das consultas, respostas, erros e regras de compatibilidade. A política de acesso e limite de consultas também será decidida antes da implementação. O documento não informa a janela de medição da disponibilidade nem uma data de lançamento. Um percentual no projeto não é histórico de disponibilidade.

A próxima evidência útil será uma especificação revisada, regras de acesso definidas e, depois da implementação, medições que separem a atualização da fonte do comportamento dos caches e dos clientes. Até lá, a API v3 é um contrato proposto para uma futura via de leitura, não um serviço de que os operadores possam depender hoje.

Fontes