Zusammenfassung

  • Andy Clyde sagte bei RIPE 93, sein Team bei Internet Society/Pulse nutze PeeringDB analytisch und brauche Daten bis 2019 zurück, um frühere Auswertungen erneut rechnen zu können.
  • Der API-v3-Entwurf setzt Ziele für aktuelle Daten, nimmt historische Abfragen ausdrücklich aus der Frist heraus und fordert eine veröffentlichte Aufbewahrungsdauer ohne konkrete Zahl.

Für einen Routerbetreiber ist eine frische PeeringDB-Antwort ein unmittelbarer Betriebswert. Andy Clyde schaut auf eine andere Uhr. In der RIPE-93-Runde zur neuen API erklärte er, dass sein Team Entwicklungen bei Internetknoten untersucht. Ein Umstieg auf den API-Entwurf könne vielleicht ein paar Wochen dauern. Ob die Daten von 2019 weiterhin abrufbar und neu auswertbar sind, entscheidet dagegen über Jahre von Forschung.

Im offiziellen Wortprotokoll nennt Clyde weitere Wünsche für den IXP-Tracker: Verkehrsdaten, Netzklassifikationen und Arten von Datensätzen. Einiges davon könne außerhalb von PeeringDBs Zuständigkeit liegen. Zwei parallel gepflegte APIs verursachen Arbeit auf beiden Seiten. Fehlende historische Beobachtungen lassen sich jedoch nicht mit einem neuen Client ersetzen.

PeeringDBs v3-Entwurf vom 18. September plant eine öffentliche, schreibgeschützte Schnittstelle neben v2, inkrementelle Synchronisierung und tägliche Momentaufnahmen. 99 Prozent aktueller Änderungen sollen binnen einer Minute sichtbar sein. Historische Abfragen zählen bei diesem Ziel ausdrücklich nicht mit. Eine Aufbewahrungsfrist für ältere bereitgestellte Daten soll veröffentlicht werden; ihre Länge fehlt noch. Die bisherigen Dump-Adressen bleiben durch diese Arbeit unverändert.

Clyde braucht eine Antwort in Form eines Datums: Wie weit reicht die angebotene Vergangenheit? Erst dann weiß ein Analyst, ob sich eine Auswertung später mit denselben Beobachtungen wiederholen lässt.