Zusammenfassung

  • prop-167-v002 enthielt zwei Outputs: öffentliche stündliche WHOIS/RDAP-Nutzungsdaten und eine MyAPNIC-Funktion für Abfragen gegen eigene Ressourcen.
  • Resolution 2025-32 billigte die öffentliche Statistik. Kosten, Ressourcenbedarf und mögliche Datenschutzbedenken überwogen nach Auffassung des EC den unmittelbaren Nutzen der MyAPNIC-Funktion; sie galt damals als nicht machbar.
  • Der gebilligte Teil ist nachweislich produktiv. Das Stundenarchiv beginnt am 30. Juni 2026, und das aktuelle JSON trennt RDAP von WHOIS.
  • Ein proposal-weites Implemented kann den gebilligten Umfang korrekt zusammenfassen. Ohne Output-Zeilen bewahrt es aber nicht die unterschiedliche Entscheidung über den zweiten Teil.

Der öffentliche Datenstrom ist kein fehlendes Beweisstück. Im APNIC-Verzeichnis liegen ein aktuelles JSON, eine Prüfsumme und Jahresarchive. Das Juni-Verzeichnis beginnt am 30. Juni 2026 und führt komprimierte Stundendateien von 03:00 bis 23:00. Im aktuellen Objekt haben RDAP und WHOIS eigene Zeitfenster, Summen, Query-Typen und ASN-Verteilungen.

Auch die institutionelle Oberfläche nennt diesen Tag. Die prop-167-Seite führt Implementation Complete am 30. Juni und den heutigen Status Implemented. Der öffentliche Output hat somit einen Beschlussweg und ein prüfbares Ergebnis.

Unvollständig wird die Darstellung erst, wenn der Leser von diesem Status auf den gesamten v002-Text zurückschließt. Dort standen zwei Produkte. Der EC gab ihnen zwei Dispositionen.

Output aus v002 EC-Entscheidung vom 4. Dezember 2025 Öffentlich prüfbarer Stand im August 2026
Stündliche maschinenlesbare WHOIS/RDAP-Statistik Durch Resolution 2025-32 gebilligt Aktuelles JSON und Stundenarchive ab 30. Juni
Ressourcenspezifische Abfrageansicht in MyAPNIC Aus den genannten Gründen damals nicht als machbar angesehen Keine geprüfte Quelle belegt spätere Umsetzung oder neue Entscheidung

Die zweite Zeile ist kein durch Schweigen konstruiertes Defizit. Sie hat eine ausdrückliche, datierte Entscheidung. Genau diese institutionelle Präzision geht verloren, wenn nur der Elternstatus sichtbar bleibt.

Der Vorschlag verband Aggregation und Kontozuordnung

prop-167-v002 erschien am 21. August 2025. Dem Text zufolge hatte APNIC zwischen 1. April und 30. Juni ungefähr 5,5 Milliarden Directory Queries beantwortet. In manchen Stunden kamen bei RDAP Anfragen von mehr als 365.000 unterschiedlichen IP-Adressen. Der Vorschlag verweist dafür auf interne APNIC-Daten.

Diese Herkunft darf nicht verschwinden. Das geprüfte öffentliche Material reproduziert die historische Berechnung nicht. Die Zahlen beweisen weder Missbrauch noch Data Mining durch ein bestimmtes ASN. Der Vorschlag formulierte solche Nutzungen als mögliche Erklärung und als Grund für bessere Sichtbarkeit.

Der aggregierte Output sollte stündlich als JSON oder CSV erscheinen. Vorgesehen waren WHOIS/RDAP-Trennung, mindestens die tausend wichtigsten Source-ASNs, die Anzahl der Source-IP-Adressen je ASN sowie Metadaten zu Query Type und Method.

Die MyAPNIC-Erweiterung hatte eine andere Beziehungsebene. Ein Resource Holder sollte nach Anmeldung sehen, wie oft seine IP-Adressen oder ASNs abgefragt worden waren, nach Typ und möglichst Source-ASN. Damit mussten Konto, Resource Holding und Query-Ereignis in einer authentifizierten Oberfläche verbunden werden.

Auch das Impact Assessment trennte die Arbeiten. Für die öffentliche Statistik beschrieb es Extraktion und Publikation auf best-effort-Basis ohne SLA. Für MyAPNIC erwartete es, sofern möglich, umfangreiche Logging-Arbeiten an den zugrunde liegenden WHOIS-Systemen.

Am 11. September 2025 erreichte v002 bei APNIC 60 Konsens. Die Final Comment Period endete am 14. Oktober. Der Community State umfasste beide Outputs. Nach APNICs eigenem Prozess war er dennoch nicht die letzte Scope-Entscheidung.

Der EC erfüllte eine ausdrücklich vorgesehene Funktion

Der Policy Development Process führt vom gehaltenen Konsens zum Endorsement durch den EC und erst danach zur Implementation durch das Secretariat. Ein Artikel kann deshalb nicht so tun, als hätte die Community beide Funktionen unmittelbar beauftragt und der EC sie unzulässig geteilt.

Resolution 2025-32 billigte prop-167-v002 hinsichtlich der real-time oder near-real-time veröffentlichten Directory-Service-Statistik. Danach zitierte sie den MyAPNIC-Wunsch. Kosten, Resourcing und potenzielle Privacy Concerns überwogen den unmittelbaren Nutzen; der EC hielt die Funktion zu diesem Zeitpunkt für nicht machbar. Der Beschluss fiel einstimmig.

With respect to ist die Scope-Grenze. Die drei Gründe sind die veröffentlichten Gründe; über Motive, Budgets oder technische Alternativen sagen die Quellen nichts Weiteres. At this time fixiert den Stand vom 4. Dezember 2025, ohne spätere Prüfung zu versprechen oder für immer auszuschließen.

Das ist keine schwache Entscheidung. Sie verhindert, dass zwei technisch verschiedene Produkte aufgrund eines gemeinsamen proposal identifiers zwangsläufig dasselbe Ergebnis erhalten. Die spätere Statusprojektion sollte diese Differenz fortführen.

Produktionsevidence schließt den ersten Pfad

Bei APNIC 61 stand prop-167 noch auf In Implementation, mit erwarteter Fertigstellung bis Ende Q2. Die Beschreibung nannte die maschinenlesbare Veröffentlichung. Aktuelle Roadmap-Daten sprechen vom Implementieren der endorsed requirements.

Das FTP liefert die entscheidende Verbindung. Die Archive des 30. Juni entsprechen dem Completion Date; das aktuelle JSON zeigt einen laufenden Output. Ein externer Prüfer kann Bytes und Struktur untersuchen, statt Projektwörter auszulegen.

Diese Prüfung hat Grenzen. Ein aktueller Abruf beweist keine lückenlose Stunde seit Beginn, keine dauerhafte Schema-Stabilität und keine vollständige Erfüllung jeder möglichen Lesart. Best-effort ist kein SLA. Der 2026-Feed reproduziert auch nicht automatisch die 2025-Zahl von 5,5 Milliarden.

Er beweist jedoch, dass die öffentliche Statistik implementiert wurde. Die Analyse darf diesen Erfolg nicht in eine erfundene Abwesenheitsgeschichte verwandeln.

Ein Gesamtstatus braucht seine Unterzeilen

Die proposal page zeigt v002, das Impact Assessment einschließlich MyAPNIC, das EC-Endorsement und den Abschluss. In der History-Zeile steht nicht, dass Resolution 2025-32 die Outputs unterschiedlich behandelte. Der Leser muss das Sitzungsprotokoll und das FTP selbst an den Vorschlag anfügen.

Implemented ist vertretbar, wenn es den vom EC gebilligten Scope bezeichnet. Es ist missverständlich, wenn es als Umsetzung des gesamten Konsenstextes gelesen wird. Die Oberfläche veröffentlicht keine Derivationsregel, die zwischen diesen Bedeutungen entscheidet.

Ein Proposal ist eine Dokumenteinheit. Ein Output ist eine Entscheidungseinheit. Sobald ein Gremium einzelne Outputs getrennt billigt, verschiebt oder ablehnt, kann der Elternstatus nur noch Zusammenfassung sein. Er darf die Kinderzustände nicht ersetzen.

Für MyAPNIC wäre Failed falsch, weil kein gebilligter Lieferauftrag nachgewiesen ist. Permanent verworfen wäre ebenso falsch. Quellengetreu lautet der Zustand: am 4. Dezember nicht gebilligt und damals aus den genannten Gründen nicht machbar; spätere Reconsideration öffentlich nicht belegt.

Der Nachweis betrifft Scope, nicht private Logs

Eine Output-Projektion fordert weder die heutige Implementierung von MyAPNIC noch die Offenlegung einzelner Queries. Die Schutzgrenze kann bestehen bleiben. Öffentlich werden müsste nur, wie die Entscheidung aus dem Text entstand.

Pro Output genügen Version und Fingerprint, Quellpassage, Community State, EC Resolution und Disposition. Beim gebilligten Teil kommen Artifact URL, Format und erster verifizierter Produktionszeitpunkt hinzu. Beim anderen Teil bleiben Grundklasse, Datum und spätere Entscheidungsrelationen sichtbar.

Feld Kontrollwirkung
Version und Fingerprint Bindet alle Stufen an denselben Text
Output-ID und Passage Trennt Dokument- von Entscheidungseinheit
Konsens und Final Comment Bewahrt Community State ohne Kompetenzinflation
Resolution und Disposition Belegt den gebilligten Scope
Artefakt und Produktionsbeginn Verknüpft Entscheidung und Betrieb
Zustand des nicht gebilligten Outputs Trennt damalige Machbarkeit von Dauerentscheidungen
Korrektur und Supersession Ermöglicht Änderung ohne stille Umschreibung
Regel für den Elternstatus Erklärt, was Implemented zusammenfasst

Dieser dünne Nachweis ist kein neuer PDP. Er projiziert dessen bestehende Ergebnisse. Detaillierte Tests, Kosten und geschützte Logs müssen dafür nicht öffentlich werden.

Die offenen Punkte bleiben offen

Ob APNIC später eine billigere oder datenschutzfreundlichere MyAPNIC-Lösung geprüft hat, ist nicht belegt. Ebenso wenig ist belegt, dass intern nie daran gearbeitet wurde. Ein allgemeines Portal-Release wäre keine Evidence für genau die ressourcenspezifische Query-Ansicht.

Es gibt keinen nachgewiesenen Schaden eines Resource Holders, kein Leak, keinen SLA-Verstoß und keinen Security Incident. Auch die Privacy Concerns dürfen nicht als Vorwand bezeichnet werden. Das Thema ist Scope Identity, nicht die technische Bewertung einer unveröffentlichten Lösung.

Die Quellen definieren außerdem nicht APNICs allgemeine Statuskonvention bei scoped endorsements. Selbst wenn Implemented regelmäßig den endorsed scope meint, kann die Zeilenprojektion den Status beibehalten und seine Grundlage sichtbar machen.

Der Feed ist umgesetzt. MyAPNIC erhielt eine andere, zeitgebundene Entscheidung. Eine genaue proposal history sollte beides ohne Dramatisierung ausweisen.

Quellen