Zusammenfassung

  • PeeringDBs API-v3-Entwurf sieht einen öffentlichen Nur-Lese-Dienst für mehrere Standorte mit Zielen für Verfügbarkeit und Datenaktualität vor.
  • Der Text ist noch eine offene Konsultation, keine Einführung: Zugangsregeln und die genaue API-Spezifikation sind nicht fertig, Betriebsdaten gibt es nicht.

Der Entwurf gibt einer künftigen API messbare Zeitziele, aber keinen Starttermin. Das auf den 18. September datierte PeeringDB-Dokument nennt mindestens 99,95 Prozent Verfügbarkeit, Sichtbarkeit von 99 Prozent der Änderungen innerhalb einer Minute und eine Obergrenze von 15 Minuten für Antworten mit den neuesten Daten, einschließlich Cache-Verzögerung. Einen Umsetzungstermin nennt es nicht. Der Status kennzeichnet den Text als ersten Aufruf zu Kommentaren und Prüfung.

PeeringDBs von APNIC am 7. Oktober veröffentlichte Produktaktualisierung erläutert den Anlass. Produktmanager Leo Vegoda nennt zwei Ziele: Lesen und Schreiben zu trennen, damit der Dienst an mehreren Standorten bereitgestellt werden kann, und häufige Abfragen zu Objektbeziehungen effizienter zu machen. Er bittet API-Nutzer vor der Umsetzung um Rückmeldungen. Die detaillierte Spezifikation steht im Entwurf von PeeringDB selbst; APNIC ist der Veröffentlichungskanal, nicht der API-Betreiber.

Der geplante Umfang ist bewusst eng. Version 3 soll öffentlich und nur lesend neben v2 laufen; Schreibvorgänge bleiben bei v2. Die erste Suche soll Namen und AS-Nummern abdecken. Private oder schlüsselabhängige Ansichten, verschachtelte Tiefenauflösung, gerankte Volltextsuche sowie räumliche und Entfernungsabfragen sind nicht für die erste Version vorgesehen. Flache Objekte, inkrementelle Synchronisierung und tägliche Schnappschüsse sollen Nutzern ermöglichen, eigene Kopien aufzubauen und zu aktualisieren. Antworten sollen die Datensatzversion ausweisen; ein Versionsendpunkt soll die Aktualität der Quelldaten melden.

Für die Aktualitätsziele ist der Messbereich festgelegt. Gemessen wird vom Wechsel an der Quelle bis zu einer Antwort mit den neuesten Daten, einschließlich Cache-Verzögerung. Tages-Schnappschüsse, historische Abfragen, Spiegel Dritter und das Abrufintervall eines Clients sind ausgenommen. Die 15-Minuten-Grenze soll einen Alarm auslösen, nicht die Ausgabe stoppen. Laut Entwurf darf das Verfehlen eines Aktualitätsziels den Dienst nicht stilllegen.

Das ist relevant für Netzbetreiber, die PeeringDB zur Prüfung von Netzen, Standorten und Austauschbeziehungen nutzen. Der Entwurf setzt ein Ziel dafür, wie schnell die öffentliche Ansicht nachziehen soll; er belegt weder Vollständigkeit noch die Richtigkeit von Angaben, die Teilnehmer selbst pflegen. PeeringDB ist auch keine Routing-Steuerungsebene. Der Vorschlag ändert weder Zuteilungen der RIRs noch BGP-Entscheidungen.

Vor der Umsetzung bleiben wichtige Punkte offen. OpenAPI soll Abfragesyntax, Antworten, Fehler und Kompatibilität festlegen. Zugangs- und Ratenbegrenzungsregeln müssen ebenfalls vor dem Bau entschieden werden. Das Dokument nennt weder einen Messzeitraum für die Verfügbarkeit noch ein Startdatum. Ein Prozentwert im Entwurf ist kein Verfügbarkeitsprotokoll.

Als Nächstes wären eine überarbeitete Spezifikation, feste Zugangsregeln und später Produktionsmessungen hilfreich, die Quellenaktualität, Caches und Client-Verhalten getrennt betrachten. Bis dahin bleibt API v3 ein vorgeschlagener Vertrag für einen künftigen Leseweg, kein Dienst, auf den Betreiber heute bauen können.

Quellen