Résumé

  • Le projet d’API v3 de PeeringDB propose un service public en lecture seule, prévu pour plusieurs sites, avec des objectifs de disponibilité et de fraîcheur des données.
  • Il s’agit d’un texte soumis aux commentaires, pas d’un lancement : les règles d’accès et le contrat API détaillé restent à définir, sans preuve de performance en production.

Le projet donne une horloge à une future API, mais pas de date de lancement. Le document de PeeringDB, daté du 18 septembre, vise une disponibilité d’au moins 99,95 %, prévoit que 99 % des changements soient visibles en une minute et fixe à 15 minutes le plafond de fraîcheur des réponses portant sur les données les plus récentes, cache compris. Il n’indique pas quand le service sera mis en œuvre. Son statut le présente comme un premier texte soumis aux commentaires et à l’examen.

La mise à jour PeeringDB publiée par APNIC le 7 octobre explique l’origine du chantier. Leo Vegoda, responsable produit, cite deux objectifs : séparer la lecture de l’écriture pour pouvoir servir les données depuis plusieurs sites, puis rendre plus efficaces certaines requêtes sur les relations entre objets. Il invite les utilisateurs de l’API à contribuer avant l’implémentation. Le contrat détaillé figure sur la page de PeeringDB ; APNIC est le canal de publication, pas l’exploitant de l’API.

Le périmètre proposé reste volontairement limité. La version 3 serait publique et en lecture seule, en parallèle de la version 2 ; les écritures resteraient sur v2. La première recherche porterait sur les noms et les numéros d’AS. Les vues privées ou propres à chaque clé, l’expansion imbriquée, la recherche plein texte classée et les requêtes de distance ou spatiales sont écartées de la première version. Des objets plats, la synchronisation incrémentale et des instantanés quotidiens doivent permettre aux utilisateurs de créer et d’actualiser leurs copies.

Les réponses indiqueraient une version du jeu de données et un point d’accès préciserait la fraîcheur de la source.

Les chiffres de fraîcheur ont des limites définies. La mesure va d’un changement à la source jusqu’à une réponse portant sur les données les plus récentes, délai de cache inclus. Elle exclut les instantanés quotidiens, les parcours historiques, les miroirs tiers et l’intervalle de requête choisi par le client. Le plafond de 15 minutes sert à déclencher une alerte, pas à interrompre le service : le projet dit qu’un dépassement ne doit pas empêcher les réponses.

Cette distinction intéresse les opérateurs qui consultent PeeringDB pour examiner des réseaux, des installations et leurs relations avec les échanges. Le projet propose un objectif de délai pour la mise à jour de la vue publique ; il ne prouve ni son exhaustivité ni l’exactitude des informations fournies par les participants. PeeringDB n’est pas non plus un plan de contrôle du routage : le projet ne change ni les allocations des RIR ni les décisions BGP.

Avant toute mise en œuvre, plusieurs éléments restent ouverts. OpenAPI devra préciser la syntaxe des requêtes, les réponses, les erreurs et la compatibilité. Les règles d’accès et de limitation du débit restent également à décider. Le texte ne précise ni la fenêtre de mesure de la disponibilité ni une date de lancement. Un objectif inscrit dans un projet n’est pas un relevé de disponibilité.

Les prochains éléments probants seront une spécification révisée, des règles d’accès arrêtées, puis des mesures en production distinguant la fraîcheur de la source du comportement des caches et des clients. D’ici là, l’API v3 reste un contrat envisagé pour un futur service de lecture, pas un service sur lequel les opérateurs peuvent déjà compter.

Sources