Zusammenfassung

  • Prop-173 in Fassung 1 würde eigene Bedingungen für gewöhnliche Abfragen schaffen und sie über WHOIS, RDAP und Weboberflächen anzeigen. Der Text steht auf der Policy-SIG-Mailingliste zur Diskussion und ist keine beschlossene Richtlinie.
  • Das zentrale Dokument soll Versionsnummer, Inkrafttreten, Änderungshistorie und Archiv tragen. Die einzelne Antwort müsste aber nur auf die aktuelle Adresse verweisen; ihr fehlen Fassung, Geltungsbeginn und Dokumentenprüfsumme für den konkreten Abruf.

Eine normale Abfrage ist kein Datenbankspiegel

Der überzeugendste Teil des Vorschlags ist die Trennung. Ein Netzbetreiber, der einen Kontakt prüft, ein Sicherheitsteam mit einer einzelnen Incident-Abfrage oder ein Forscher mit geringem Volumen beantragen keinen Datenbankspiegel. APNIC hat bereits eine Vereinbarung für Whois-Massenzugriff. Sie beantwortet aber nicht ohne Weiteres, wann Speichern, Zusammenführen oder Weitergabe eines normalen Ergebnisses in einen geregelten Großabruf übergeht.

Die offizielle Seite zu Prop-173 vermerkt Fassung 1 am 17. August 2026 auf der Mailingliste der Policy SIG. Der Status lautet „Published to Mailing List“. Im geprüften Vorgang fehlen eine Auswirkungsanalyse des Sekretariats, ein Konsensbefund, ein Annahmebeschluss und eine Umsetzungsmitteilung. Es geht daher um Regeln, die der Entwurf schaffen würde, nicht um bereits geltendes APNIC-Recht.

Der Text der ersten Fassung erfasst Personen und Systeme, die APNIC-autoritative Verzeichnisdaten über WHOIS, RDAP, Websuche oder gleichwertige APIs abrufen. Spiegel- oder Verweisdaten eines anderen Registers sollen dessen Bedingungen unterliegen. Hohes Volumen, erhebliche Auszüge, Spiegel und Ersatzdatenbanken bleiben im getrennten Massenverfahren.

Die zulässigen Zwecke umfassen unter anderem Routing-Analyse, Fehlersuche, Ressourcenidentifikation, Reverse DNS, Missbrauchsabwehr und technische Forschung. Untersagt würden etwa Marketinglisten, systematisches Harvesting, Umgehung von Ratenbegrenzungen und ein nicht genehmigtes Datenprodukt. Für irrtümlich beschränkte Nutzer soll es eine Überprüfung geben.

Das ist eine vernünftige Governance-Leistung. Die erlaubte betriebliche Nutzung wird nicht aus Versehen mit kommerzieller Sammlung gleichgesetzt, während APNIC Grenzen sichtbar machen kann. Die hier untersuchte Lücke beginnt erst, wenn sich der gut sichtbare Text ändert und ein altes Ergebnis weiterlebt.

Ein fester Ort ist noch keine feste Ausgabe

Der Entwurf bringt den Hinweis in jede Schnittstelle. WHOIS soll erklären, dass die Verzeichnisdaten der Richtlinie unterliegen und Abfrage oder Nutzung als Zustimmung gelten. RDAP soll einen Hinweis auf die Richtlinie, einen Link mit terms-of-service, einen Hinweis auf geistiges Eigentum und die URL der aktuellen Richtlinie enthalten. Die Weboberfläche soll die Bindung bei der Abfrage ebenfalls zeigen.

Für diese URL verlangt Prop-173 HTTPS, Stabilität, Pflege und den Verzicht auf Weiterleitungen. Das zentrale Richtliniendokument soll außerdem eine Versionsnummer, ein Datum des Inkrafttretens, eine Änderungshistorie und ein Archiv früherer Fassungen haben. Änderungen sollen angemessen vorab angekündigt werden; bestimmte materielle Abschwächungen sollen zurück in die Konsultation.

Das ist mehr als Formalität. Ein zentraler Text lässt sich über mehrere Protokolle konsistent pflegen. Eine stabile Adresse vermindert Linkbruch, das Archiv macht Veränderungen sichtbar, und Vorankündigung schützt vor Überraschungen. Kurze Antworten bleiben für einfache Werkzeuge handhabbar. Ein Fassungsbeleg sollte diese Vorteile ergänzen.

Die Antwortanforderungen und die Dokumentanforderungen sind aber nicht miteinander verschränkt. In der Antwort stehen weder die anwendbare Versionsnummer noch deren Geltungsbeginn oder eine Prüfsumme. Eine am Montag gespeicherte Antwort kann am Freitag dieselbe URL öffnen, obwohl dort inzwischen Freitagsbedingungen stehen.

Mit einer verlässlichen externen Abrufzeit und sauber begrenzten Archivfassungen lässt sich der damalige Text womöglich rekonstruieren. Clientprotokolle, erhaltene Header oder ein Mitschnitt können helfen. Diese Beweise liegen jedoch außerhalb der Antwort. Ihr fehlt der Join-Schlüssel zwischen dem gelieferten Registerdatensatz und dem damals aufgerufenen Regelwerk.

Der aktuelle RDAP-Befund ist nur ein Prüfpunkt

Die für diese Analyse gesicherte APNIC-RDAP-Antwort zu 1.1.1.1 enthält bereits einen Hinweis „Terms and Conditions“ mit einem terms-of-service-Link. Weitere Hinweise nennen die Quelle und einen Meldeweg für Fehler. Eine Richtlinienfassung, deren Geltungsbeginn oder die Prüfsumme des Textes fehlen.

Das beweist keine Umsetzung von Prop-173. Eine Antwort steht weder für WHOIS und Web noch für sämtliche RDAP-Instanzen. Sie zeigt nur, dass eine reale Antwort den Ort der Bedingungen transportieren kann, ohne die damals gemeinte Ausgabe dieses Ortes zu identifizieren.

RFC 9083 definiert RDAP-Hinweise als Angaben zum Dienst oder zur ganzen Antwort. Eine Beschreibung ist Pflicht, Links können hinzukommen. Damit gibt es Platz für den heutigen Verweis und für einen knappen Fassungsbeleg. Der Standard schreibt keine APNIC-spezifische Richtlinienversion vor. Protokollkonformität ersetzt deshalb keine institutionelle Zeitspur.

Nutzungsbedingungen sind kein Rechtekataster

Die APNIC-Vereinbarung für Whois-Massenzugriff beschränkt Vervielfältigung, Speicherung, Übertragung und Weitergabe in großen Mengen außerhalb zugelassener Zwecke. Sie zeigt, warum Bedingungen nach dem Abruf weiterwirken können. Gerade deshalb ist es sinnvoll, gewöhnliche Abfragen in einem eigenen Dokument zu regeln.

Ein Fassungsbeleg beantwortet nicht, wem jedes Feld gehört. Von Mitgliedern gelieferte Inhalte, APNIC-Struktur, gespiegelt übernommene Werte und Registrierungsfakten können unterschiedliche Grundlagen haben. Dafür wäre eine feinere Herkunfts- oder Rechteaufzeichnung nötig. Der Beleg sagt nur, welchen Text der Dienst für diese Antwort in Bezug nahm.

APNICs Datenschutzerklärung ordnet Whois und RDAP in die Verarbeitung von Registrierungs- und Kontaktinformationen ein. Eine benannte Fassung erlaubt nicht automatisch jede Nutzung und macht keine Klausel wirksam. Sie verhindert lediglich, dass eine spätere Prüfung unbemerkt von einem anderen Dokument ausgeht.

Der Entwurf kann die Verbindung noch ergänzen

APNICs Policy Development Process beruht auf offener Erörterung und Konsens. Eine erste Mailinglistenfassung ist Prüfmaterial, kein Abschluss. Ein gemeinsamer Versionsbezeichner in WHOIS-Kommentar und RDAP-Hinweis lässt sich hinzufügen, ohne Trennung, Schutzregeln oder Überprüfungsweg aufzugeben.

Die Belege tragen keine weitergehende Anklage. Es gibt hier keinen Nutzer, der nach der falschen Fassung beschränkt wurde, keine heimliche Änderung, keine ausgefallene Abfrage, keinen Betriebsschaden und keine gerichtliche Wertung. APNIC kann intern lückenlose Release-Protokolle führen. Öffentlich feststellbar ist nur, dass v001 ihren Nachweis nicht als Bestandteil der Antwort verlangt.

Quellen

Grundlage sind APNICs Statusseite zu Prop-173, der Text von Fassung 1, die Vereinbarung für Whois-Massenzugriff, die gesicherte RDAP-Antwort, die Datenschutzerklärung, der Policy Development Process und RFC 9083. Sie belegen Entwurf und Antwortform, nicht einen Streit unter umgesetzter Prop-173.