Zusammenfassung

  • Der am 18. September veröffentlichte Erstentwurf sieht eine öffentliche, schreibgeschützte API v3 vor; Änderungen sollen zunächst weiter über v2 laufen.
  • Öffentliche Lesbarkeit und Cachebarkeit sind keine pauschale Erlaubnis, Daten in großen Mengen zu speichern oder kommerziell weiterzuverwenden.

Wer einen API-Aufruf absetzen kann, hat damit noch nicht automatisch das Recht, die Antwort in einem kommerziellen Datenprodukt zu speichern. PeeringDBs API-v3-Entwurf verbessert den vorgesehenen Leseweg; eine Änderung der Nutzungsregeln kündigt er nicht an.

Das Dokument vom 18. September ist weiterhin als erste Bitte um Kommentare gekennzeichnet. Es beschreibt eine öffentliche, schreibgeschützte Schnittstelle, die von mehreren Standorten bedient werden soll und parallel zur heutigen API läuft, die der Entwurf v2 nennt. Schreibzugriffe blieben zunächst dort. Vorgesehen sind flache Objekte, inkrementelle Synchronisierung und tägliche Snapshots für den Masseneinstieg und als Rückfallweg. Die Erklärung vom 21.

September nennt zwei Gründe: Da Abfragen zahlreicher sind als Änderungen, könnte eine Trennung von Lesen und Schreiben weit verteilte Query-Server ermöglichen und Latenz wie Ausfallsicherheit verbessern.

Die Leistungsziele sind bereits beziffert: mindestens 99,95 Prozent Verfügbarkeit, 99 Prozent der Änderungen binnen einer Minute sichtbar und höchstens 15 Minuten Frische für Antworten zum neuesten Datenstand. Diese Obergrenze ist ein Alarmziel, keine Abschaltregel. Snapshots, historische Abrufe, Spiegel Dritter und die eigene Abfragehäufigkeit des Clients zählen nicht zur Frischemessung. Alle Aufrufer sollen denselben öffentlichen Datenbestand sehen; API-Schlüssel sollen die Sichtbarkeit nicht verändern.

PeeringDBs geltende Acceptable-Use-Policy regelt dagegen die Nutzung. Ohne vorherige Erlaubnis dürfen Daten grundsätzlich weder vervielfältigt noch in einem Abrufsystem gespeichert oder übertragen werden; ausgenommen sind genehmigte Internet-Betriebszwecke. Die Policy nennt Fehlerbehebung, Abuse-Meldungen sowie Internet-Recherche und -Analyse. Eine Weitergabe großer Datenmengen braucht Zustimmung; Marketinglisten, demografische Kartierung und andere kommerzielle Anwendungen sind ausgeschlossen. Maßgeblich ist der für den Einzelfall angegebene Zweck.

Der API-Entwurf sagt nicht, dass sich daran etwas ändert. Cachebare Antworten und ein Delta-Verfahren, mit dem ein Client durch Abfragen im Fünf-Minuten-Takt eine aktuelle lokale Kopie halten kann, sind technische Eigenschaften. Sie sind keine allgemeine Erlaubnis zur Speicherung oder Weitergabe. Auch der Ausschluss externer Spiegel aus der Frischemessung und der Notfallentfernung beschreibt die Grenzen des PeeringDB-Dienstes, nicht ein Recht zur Replikation.

Das wird bei Rücknahmen konkret. Der geplante öffentliche Datensatz enthält weiterhin als öffentlich markierte Kontakte, Notizen und genaue Koordinaten. PeeringDB soll eine Aufbewahrungsfrist veröffentlichen und eine Notfallentfernung für die von PeeringDB ausgelieferten Daten anbieten. Kopien, die Dritte bereits besitzen, fallen nicht darunter. Deltas müssen Löschungen und Rücknahmen sichtbar machen; die konkrete OpenAPI-Spezifikation für Anfragen und Antworten fehlt noch.

Zugangs- und Ratenbegrenzungen, der genaue v3-Pfad und mehrere Fragen zu Feldern und Objekttypen sind offen und sollen vor der Umsetzung entschieden werden. PeeringDB bittet um Rückmeldungen zum Übergang, falls die bisherige API später abgelöst wird; ein Starttermin ist nicht veröffentlicht. Für Betreiber und Entwickler zählt daher neben der Antwortzeit auch, welche lokalen Kopien für welchen Zweck zulässig sind.

Quellen