Resumo

  • O rascunho de 18 de setembro propõe uma API v3 pública e somente de leitura; as gravações permaneceriam no v2 no início.
  • Uma resposta pública e cacheável não equivale a autorização para montar, armazenar ou redistribuir uma base comercial.

Uma equipe pode consultar um dado da PeeringDB e ainda não saber se pode incorporá-lo a um produto vendido a clientes. O rascunho da API v3 torna essa diferença mais relevante porque promete simplificar a leitura sem anunciar uma nova licença de uso.

O documento de 18 de setembro continua identificado como primeira chamada para comentários. A proposta é uma API pública, somente de leitura e atendida por múltiplas localidades, em paralelo à API atual, chamada de v2. As atualizações continuariam no v2 no lançamento inicial. A v3 adotaria objetos planos, sincronização incremental e instantâneos diários para carga em massa e contingência. Na explicação de 21 de setembro, a PeeringDB diz que a maioria das requisições é de leitura; separá-las das gravações permitiria distribuir servidores de consulta para reduzir latência e melhorar resiliência.

A proposta quantifica a disponibilidade e a atualidade: pelo menos 99,95% de disponibilidade, 99% das mudanças visíveis em até um minuto e um limite de frescor de quinze minutos para respostas mais recentes. Esse limite deve gerar alerta, não interromper o serviço. Instantâneos, consultas históricas, espelhos de terceiros e a frequência de consulta do próprio cliente ficam fora da medição. A API também entregaria o mesmo conjunto público a todos os usuários; uma chave não mudaria a visibilidade.

A política de uso aceitável da PeeringDB, publicada separadamente, trata da permissão. Sem autorização prévia, os dados não podem ser reproduzidos, guardados em sistema de recuperação ou transmitidos, exceto em finalidades de operação da Internet aprovadas pela organização. A política inclui solução de problemas, denúncias de abuso e pesquisa e análise sobre a Internet. O repasse em massa a outra pessoa ou empresa exige aprovação; listas de marketing, mapeamento demográfico e outras aplicações comerciais ficam fora dessa finalidade. Cada pedido é avaliado conforme o uso declarado.

O rascunho da v3 não diz que essa política mudou. Tornar respostas cacheáveis e permitir que um cliente consulte a API a cada cinco minutos para manter uma cópia local são decisões de engenharia, não uma permissão geral para revender um espelho. Da mesma forma, excluir espelhos de terceiros das métricas de frescor e da política de remoção apenas limita o que a PeeringDB promete medir ou retirar de seus próprios serviços; não autoriza redistribuição.

A proposta ainda inclui contatos, notas e coordenadas precisas que já são públicos. A PeeringDB deverá publicar por quanto tempo mantém dados antigos e oferecer remoção emergencial do que ela própria serve. As cópias que terceiros já possuem ficam fora desse alcance. Os deltas precisam mostrar exclusões e retiradas, mas o OpenAPI que definirá as chamadas e respostas ainda não foi publicado.

Acesso, limites de requisição, caminho da v3 e várias escolhas de esquema também seguem pendentes. A PeeringDB solicita contribuições para o desenho e para uma eventual transição, caso decida aposentar a API atual; ainda não há data anunciada. Para quem depende desses dados, a questão comercial começa depois do teste de velocidade: quais cópias são permitidas e para quais finalidades?

Fontes