Résumé

  • Andy Clyde a expliqué à RIPE 93 que son équipe Internet Society/Pulse utilise PeeringDB pour l’analyse et doit pouvoir revenir aux données de 2019 afin de refaire ses calculs.
  • Le projet API v3 de PeeringDB fixe des délais pour les données récentes, exclut les parcours historiques de ce calcul et exige une durée de conservation publiée sans la préciser encore.

Le débat sur une nouvelle API tourne facilement à la vitesse et au format des réponses. Andy Clyde a ramené la discussion à une date: 2019. Lors du panel PeeringDB à RIPE 93, il a dit que son équipe consulte les données pour analyser les points d’échange, puis les retraite si nécessaire. Passer à une API provisoire pourrait lui prendre quelques semaines, selon son estimation. Accéder au passé est une autre affaire.

Dans la transcription officielle, Clyde demande aussi davantage de matière pour son suivi des IX: trafic, catégories de réseaux et types de jeux de données. Il reconnaît que tout ne relève peut-être pas de PeeringDB. Deux API à maintenir coûtent du temps à l’équipe cliente comme à l’organisation qui les sert. Mais une archive tronquée ferait perdre quelque chose qu’un nouvel appel HTTP ne répare pas: la possibilité de refaire une série.

Le texte officiel de v3, daté du 18 septembre 2026, prévoit une interface publique en lecture seule à côté de v2, une synchronisation incrémentale et des instantanés quotidiens. Il vise la visibilité de 99 % des changements courants en une minute. Les parcours historiques sont exclus du chronomètre. Le document demande une fenêtre de conservation pour les anciennes données servies par PeeringDB, sans encore en donner la durée. Les adresses des exports existants restent inchangées dans ce projet.

Clyde ne réclame donc pas simplement une API rapide. Il veut savoir jusqu’où elle laisse remonter le lecteur, et si une étude peut être relancée demain avec les mêmes observations.