Zusammenfassung

  • ICANN nimmt Open Data Platform und API nach dem 31. August außer Betrieb und leitet die alte Adresse um. Die auf der neuen Seite verfügbaren CSV-Dateien sind ohne Konto zugänglich; abhängige Prozesse müssen angepasst werden.
  • Ein Download beweist Verfügbarkeit, aber noch keine dauerhafte Release-Identität. Eine Übergabematrix und ein Beleg je Veröffentlichung könnten alte Kennungen, heutige Ziele, Definitionen, exakte Dateien und Korrekturen miteinander verbinden.

Die Umstellung lässt sich weder als bloßer Rückschritt noch als vollständige Vereinfachung bilanzieren. Sie verbessert den Zugang für Menschen, die eine Datei laden wollen, und verändert die Arbeitsgrundlage für Programme, die auf die bisherige API zugeschnitten sind.

ICANN kündigte die neue Datenseite am 15. Juni an. Die alte Plattform blieb bis Ende August parallel erreichbar, damit Nutzer den Ersatz prüfen und ihre Abläufe ändern konnten. Am 27. August folgte die Erinnerung: Nach dem 31. August steht die Plattform nicht mehr zur Verfügung, am 1. September endet auch die API, und die bisherige URL verweist künftig auf die Open Data Initiative.

Als Gründe nennt ICANN einfacheren öffentlichen Zugang sowie geringeren Aufwand für Wartung, Datenspeicherung und Backups. Es gab somit eine öffentliche Ankündigung und eine Übergangsphase. Die geprüften Quellen tragen keine Darstellung eines heimlichen Abschaltens.

Eine Ankündigung ist jedoch keine vollständige Übergabeakte. Sie nennt Zeitpunkt und neue Einstiegsseite. Sie weist nicht jede frühere Katalogbezeichnung, API-Abhängigkeit und Funktion einem nachvollziehbaren heutigen Zustand zu.

Der Zugang ohne Konto ist ein wirklicher Gewinn

Auf der gegenwärtigen Open-Data-Seite stehen zwei Familien: Domain Name Marketplace Indicators (DNMI) und Security Response Waiver Requests (SRW). Die Dateien lassen sich direkt abrufen.

DNMI Version 1.1 umfasst 16 aktive Indikatoren in den Bereichen Robust Competition, Marketplace Stability und Consumer Trust. Die Unterseiten trennen jährlich aktualisierte Dateien von archivierten Indikatoren der älteren Struktur. SRW veröffentlicht eine jährliche CSV mit fünf Messgrößen zu Anträgen, Reichweite, Zeitpunkt und Entscheidung.

Ein vollständiger CSV-Abzug hat praktische Vorzüge. Er kann mit verbreiteten Werkzeugen geöffnet, lokal aufbewahrt und ohne Schlüssel oder Abrufkontingent verarbeitet werden. Wer nur eine öffentliche Datei benötigt, gewinnt nichts durch ein zusätzliches Benutzerkonto.

Die beiden für diesen Beitrag stichprobenartig geprüften Dateien waren erreichbar. Ihre HTTP-Antworten enthielten übliche Lieferinformationen wie Last-Modified und ETag. Diese Werte unterstützen Caches und Änderungsprüfungen. Die geprüften Seiten erklären sie aber nicht zum institutionellen Kennzeichen einer Ausgabe und nicht zur öffentlichen Begründung einer Korrektur.

Verfügbarkeit beantwortet: Ist die Datei jetzt abrufbar? Reproduzierbarkeit verlangt mehr: Welche konkrete Ausgabe wurde geladen, welchen Zeitraum und welche Definition bildet sie ab, und durch welche spätere Veröffentlichung wurde sie berichtigt oder ersetzt?

Die frühere Plattform hielt mehr als Dateien zusammen

In der Beschaffungsankündigung von 2018 beschrieb ICANN ein System mit offenen Lizenzen, offenem API-Zugang und zuverlässigen, maschinenlesbaren Daten zum Herunterladen und Verarbeiten. Es sollte als Quellsystem für Analysen innerhalb der Organisation und der Community dienen.

Die frühere About-Seite nannte weitere Ziele: zugängliche und nutzbare, zeitnahe und umfassende, vergleichbare und interoperable Daten für Governance und Beteiligung. Registrierte Nutzer konnten Analysen speichern, Änderungsbenachrichtigungen erhalten, API-Schlüssel erzeugen und Kontingente sehen.

Keine dieser Funktionen verpflichtet ICANN, ein bestimmtes Produkt oder einen Anbieter auf Dauer zu betreiben. Eine separat gehostete Plattform kostet. Für einen vollständigen Datenstand kann eine schlichte Datei sogar dauerhafter sein als eine Abfrage, deren Parameter und Serververhalten später rekonstruiert werden müssen.

Mit der Schnittstelle verschwinden dennoch Beziehungen, wenn sie nicht gesondert dokumentiert werden. Ein Programm kann sich auf eine Datensatzkennung, Feldauswahl, Filter, Seitennavigation oder Benachrichtigung stützen. Nach dem Ende der API braucht jede solche Abhängigkeit ein bekanntes Gegenstück oder die ehrliche Feststellung, dass es keines gibt. Bei Dateien muss erkennbar sein, ob derselbe Pfad unverändert blieb, eine neue Ausgabe trägt oder eine Korrektur erhielt.

Ein Produkt darf enden. Das institutionelle Gedächtnis darf davon unabhängig bleiben.

Aus vier alten Rubriken werden nicht automatisch zwei verschwundene Familien

Die frühere Startseite zeigte vier Themen: DNMI, Identifier Technology Health Indicators (ITHI), Registry Activity Reports und Registrar Transaction Reports. Die neue Hauptseite nennt DNMI und SRW und kündigt weitere Datensätze an, sobald sie verfügbar sind.

Die Zahlen vier und zwei belegen keinen Datenverlust. Monthly Registry Reports sind auf einer eigenen aktuellen ICANN-Seite nach Top-Level-Domain erreichbar. Auch das ITHI-Dashboard liefert aktuelle und historische Messungen.

Die belastbare Feststellung lautet daher enger: Die Übergangsseiten enthalten keine sichtbare Zeile für jede frühere Familie, die deren heutiges Ziel und den Funktionsunterschied erklärt.

Gerade die Registry Reports zeigen, warum eine solche Zuordnung nötig ist. 2021 wies ICANN Betreiber automatischer Downloads an, ihre Skripte auf die Open Data API umzustellen. Wer diese Anweisung umgesetzt hat, muss denselben Ablauf nun erneut verändern. Das beweist keinen eingetretenen Ausfall, wohl aber eine öffentlich geschaffene und anerkannte Abhängigkeit.

Eine Zuordnung kann unterschiedliche, legitime Ergebnisse ausweisen: in CSV überführt, auf einer Fachseite fortgeführt, in das Berichtsarchiv der Hauptseite zurückgeführt, zusammengelegt, archiviert oder ohne Funktionsersatz eingestellt. Schwach ist nicht zwingend das Ergebnis, sondern die Notwendigkeit, es zu erraten.

Eine Weiterleitung ist noch keine Versionsaussage

Ein Redirect bringt einen Besucher von der alten Startseite zu einer neuen. Er kann weder die Bedeutung einer früheren API-Abfrage noch die genaue Bytefolge einer anerkannten Veröffentlichung abbilden.

Wer RC 2.1 zitiert, benötigt neben der aktuellen Adresse einen Berichtszeitraum, die geltende Messdefinition, den Veröffentlichungszeitpunkt, einen erwarteten Digest, die Zeilenzahl und einen Link zu möglichen Korrekturen. Ein Nutzer kann einen eigenen Hash berechnen und damit seine gespeicherte Kopie nachweisen. Nur ICANN kann diese Bytes institutionell als eine bestimmte Ausgabe für einen bestimmten Zeitraum ausweisen.

Dafür ist kein neues Portal nötig. Eine kleine Übergabematrix und ein Release-Verzeichnis genügen.

Öffentliches Feld Geklärte Frage
Frühere Familie, Kennung und API-Pfad Welche Abhängigkeit wird übergeben?
Heutiger kanonischer Ort und Verantwortlicher Wo liegt sie, wer pflegt sie?
Disposition und Funktionsdifferenz Migriert, separat erhalten, verbunden, archiviert oder beendet?
Zeitraum, Rhythmus und Definitionsversion Was bedeuten die Werte?
Zeitpunkt, erwarteter Digest und Zeilenzahl Welches genaue Objekt ist die Ausgabe?
Korrektur und Nachfolge Was änderte sich, ohne den alten Stand zu löschen?
Lizenz, Grenzen und Kontakt Wie darf sie genutzt und beanstandet werden?

Die Matrix erklärt den Weg. Der Release-Beleg erklärt die Identität. Der Korrekturverweis erklärt die Geschichte. Eine URL ersetzt diese drei Aussagen nicht.

Öffentliche Daten brauchen ein portables Gedächtnis

Die faire Bewertung stellt API und CSV nicht moralisch gegeneinander. Anmeldungsfreie Dateien sind ein Fortschritt. Kostensenkung kann vernünftig sein. Die geprüften Quellen belegen weder das Verschwinden einer Datenfamilie noch die Fehlerhaftigkeit der heutigen Dateien.

Die Governance-Frage lautet, ob die öffentliche Identität der Daten den Wechsel des Produkts überlebt.

Mit einer dünnen, anbieterunabhängigen Schicht könnte ICANN später Host, Speicher oder Schnittstelle wechseln, ohne die Herkunftskette abzuschneiden. Software würde gegen eine erklärte Disposition umgebaut. Forschung könnte eine benannte Ausgabe zitieren. Korrekturen könnten den früheren Stand erhalten und zugleich den neuen begründen.

Datum, Einstieg und allgemeiner Grund sind bereits veröffentlicht. Ein Übergabebeleg würde den Plattformwechsel zu einem überprüfbaren Kontinuitätsereignis machen.

Quellen

  1. ICANN Public Data Webpage Update, 27. August 2026
  2. Ankündigung der neuen Datenseite, 15. Juni 2026
  3. ICANN Open Data Initiative
  4. Domain Name Marketplace Indicators
  5. DNMI: Robust Competition
  6. DNMI: Marketplace Stability
  7. DNMI: Consumer Trust
  8. Security Response Waiver Requests
  9. Frühere Startseite der Plattform
  10. Frühere About-Seite der Plattform
  11. Beschaffungsankündigung von 2018
  12. Ankündigung der Registry-Report-Migration von 2021
  13. Aktuelle Monthly Registry Reports
  14. Aktuelles ITHI-Dashboard
  15. DNMI-RC-2.1-Beispieldatei
  16. SRW-M1-M5-Beispieldatei