Zusammenfassung

  • Eine Folie von APNIC 62 ordnet APNIC 3,0 Prozent der „erfolgreichen Geofeed-Herausgeber“ in einer Zufallsstichprobe von 200.000 über Whois auffindbaren Geolokationszeilen zu. ARIN erhält 21,6 Prozent, RIPE NCC 75,5 Prozent.
  • Gezählt werden unterschiedliche Netnames; AFRINIC und LACNIC fehlen aus technischen Gründen. Veröffentlicht wurden weder die berechtigte Grundgesamtheit noch Stichtag, absolute Netname-Zahlen oder die Regel für einen Erfolg.
  • Die Werte beschreiben damit die Zusammensetzung einer eingeschlossenen Erfolgsmenge. Sie belegen nicht, dass 3,0 Prozent der APNIC-Mitglieder, Ressourceninhaber, Präfixe oder Netze Geofeeds einsetzen.
  • Eine Ein-Klick-Oberfläche kann Bedienungsreibung verringern. Ihre Wirkung braucht jedoch einen versionierten Messbeleg, der Berechtigung, Auffindbarkeit, Validierung, Pflege und nachgelagerte Nutzung verbindet.

Die Fußnote bestimmt die Einheit

Die drei Balken lesen sich zunächst wie ein regionaler Wettbewerb. APNIC steht bei 3,0 Prozent, ARIN bei 21,6 und RIPE NCC bei 75,5 Prozent. Die Überschrift fragt, aus welchen RIRs erfolgreiche Herausgeber stammen. Daraus wird schnell eine Rangliste der Geofeed-Verbreitung.

Doch die Fußnote verändert den Gegenstand der Zählung. Der Datensatz ist eine Zufallsstichprobe von 200.000 Geolokationszeilen bei geolocatemuch.com, deren Quellen über Whois entdeckt werden konnten. Gruppiert wurde „nach Netzwerk-IDs“, also unterschiedlichen Netnames. AFRINIC und LACNIC wurden bewusst aus technischen Gründen weggelassen.

Diese Angaben entwerten die Grafik nicht. Sie legen fest, wofür sie gilt. Eine Geolokationszeile ist kein Herausgeber. Eine Datei kann viele Präfixe enthalten, mehrere Ressourcenobjekte können auf dieselbe Datei verweisen. Ein Netname ist ein Kennzeichen in Registrierungsdaten und nicht zwingend eine beständige Organisationsidentität über fünf Registrys hinweg. Deduplizierung ist nötig, doch ihr Schlüssel entscheidet, welche scheinbaren Herausgeber zusammenfallen und welche getrennt bleiben.

Die drei Anteile ergeben 100,1 Prozent. Das passt zu gewöhnlicher Rundung auf eine Nachkommastelle und trägt keine weitergehende Aussage. Die relevante Lücke liegt anderswo: Es fehlen die absoluten Netname-Zahlen hinter den Balken und die Anzahl berechtigter Netnames, Inhaber, Präfixe oder gerouteter Netze in jedem einbezogenen RIR.

Zusammensetzung ist nicht Verbreitung

Angenommen, eine Erfolgsmenge enthält 1.000 Beobachtungen, von denen 30 APNIC zugeordnet werden. Dann beträgt APNICs Anteil 3,0 Prozent. Bestünde die berechtigte APNIC-Grundgesamtheit aus 60 Einheiten, ergäbe das ein anderes Bild als bei 60.000. Der gleiche Zähler kann beide Fragen nicht beantworten.

Zusammensetzung fragt, wo die Erfolge registriert waren, die Stichprobe, Entdeckung und Klassifizierung überstanden. Adoption fragt, wie viele Einheiten der jeweils berechtigten Grundgesamtheit eine aktuelle, erreichbare, korrekt abgegrenzte und nutzbare Datei veröffentlichen. Für den zweiten Satz braucht jedes Gebiet einen vergleichbaren Nenner.

Der Beitrag im APNIC Blog nennt die Quelle ausdrücklich eine Stichprobe und spricht von regionalen Unterschieden bei der Geofeed-Adoption. Die Richtung des Befunds kann stimmen. Innerhalb der eingeschlossenen Erfolgsmenge sind APNIC-gekennzeichnete Fälle selten. Aus den veröffentlichten Angaben lässt sich aber nicht die Wahrscheinlichkeit ableiten, mit der ein APNIC-Betreiber gegenüber einem RIPE-NCC-Betreiber ein Geofeed einführt.

Die beiden ausgeschlossenen RIRs schärfen die Grenze zusätzlich. Dass ihre Auslassung offengelegt wurde, ist gute Praxis. Es heißt zugleich, dass die Balken drei berücksichtigte Regionen beschreiben und nicht das RIR-System. Über AFRINIC oder LACNIC folgt daraus nichts. Die technischen Hürden können außerdem auf mangelnde Vergleichbarkeit der zugrunde liegenden Registrierungsdaten hinweisen.

„Erfolgreich“ braucht eine Zustandsfolge

Die öffentliche Seite von geolocatemuch.com beschreibt die Entdeckung über Whois und stellt eine zusammengeführte, validierte Datei bereit. Sie zeigt auch, warum die Verknüpfung schwierig ist: Eine Datei kann mehrere Präfixe tragen, mehrere Ressourcenobjekte können dieselbe Datei nennen, und Zeilen außerhalb des vom Registrierungsobjekt umfassten Bereichs müssen verworfen werden.

Die Folie definiert den „erfolgreichen Herausgeber“ nicht. Erfolg könnte bedeuten, dass der Verweis gefunden, die URL abgerufen, das CSV geparst, die Zeile innerhalb des Bereichs erkannt, die Befugnis des Herausgebers geprüft, die Ortsfelder validiert oder die Angabe von einem nachgelagerten Dienst tatsächlich genutzt wurde. Das sind getrennte Zustände.

RFC 8805 legt das Format fest und belässt dem Verbraucher Entscheidungsspielraum. Er darf die Daten als Hinweis behandeln, andere Quellen bevorzugen und Widersprüche selbst auflösen. RFC 9632 standardisiert Entdeckung und optionale Authentifizierung. Damit lässt sich besser belegen, dass ein Ressourceninhaber eine Datei autorisiert hat; aus einer Behauptung wird jedoch keine gemessene Geografie.

RFC 9877 bringt die Entdeckung mit der Link-Relation geofeed1 und einem registrierten Medientyp in RDAP. Abruf und Verwendung liegen ausdrücklich außerhalb seines Umfangs. Das RFC schreibt keinen Schalter im Registry-Portal vor, definiert keinen Adoptionsnenner und garantiert keine Übernahme durch Datenanbieter.

Ein Klick beseitigt genau eine Art von Reibung

Sid Mathur fordert in seiner fünfseitigen Präsentation, RIRs sollten die Veröffentlichung einer Geofeed-URL „mit einem Klick“ im Portal ermöglichen. Der Vorschlag verdient einen Versuch. Registrys authentifizieren bereits Konten und verwalten die Ressourcenobjekte, an denen die Entdeckung beginnt. Eine geführte Maske könnte Tippfehler verhindern, Geltungsbereiche prüfen, Datenschutzhinweise zeigen und einen heute schwer sichtbaren Mechanismus auffindbar machen.

Das stärkste Argument dafür sollte nicht kleingeredet werden: Betreiber sollten keine zufällig gewachsene Befehlssprache lernen müssen, nur um eine standardisierte URL zu veröffentlichen. Ein gutes Formular senkt Supportaufwand und macht den richtigen Weg zum einfachen Weg.

Ein Klick hostet oder pflegt jedoch keine CSV-Datei. Er bestimmt nicht, was Ortsangaben bedeuten, beweist keine Richtigkeit und zwingt keine kommerzielle Datenbank zur Übernahme. Auf Registry-Seite kann ein Übergang abgeschlossen sein, während sämtliche nachgelagerten Zustände unbekannt bleiben.

Die Präsentation erwähnt zudem eine informelle Umfrage in einer APNIC-WhatsApp-Gruppe. „Unsicher, wie die Registry helfen kann“ sei dort das zweithäufigste Hindernis gewesen. Das ist ein sinnvoller Forschungsauftrag, aber keine gemessene regionale Priorität. Es fehlen Zahl und Auswahl der Befragten, Wortlaut und Optionen, Zeitpunkt und Dublettenregel. Auch der Abstand zum erstplatzierten Hindernis und die Repräsentativität für Nicht-Herausgeber bleiben offen.

Ein Messbeleg für jede Adoptionsbehauptung

Ein versionierter Beleg beginnt vor dem Balkendiagramm. Er erfasst Stichtag, Versionen von Quelldateien und Code, Auswahlregel für die 200.000 Zeilen, Roh- und Eindeutigkeitszahlen, Whois/RDAP-Entdeckungsmethode, RIR-Zuordnung und jede technische Auslassung. Der Erfolgszustand wird benannt; die Mengen für entdeckt, abgerufen, geparst, im Bereich, befugt, aktuell und genutzt werden getrennt ausgewiesen.

Für jedes RIR erscheinen Zähler und berechtigte Grundgesamtheit in derselben Einheit. Bleibt der Netname die Einheit, müssen Normalisierung und registryübergreifende Grenzen erklärt werden. Wechselt die Einheit zu Ressourceninhabern, Dateien, Präfixen oder Routing-Ursprüngen, muss der Wechsel sichtbar sein und darf nicht in einer Beschriftung verschwinden.

Auch das Produkt braucht eine eigene Verbindung: Portalversion, berechtigte Konten, Versuche, erfolgreiche Veröffentlichungen, Validierungsfehler, Pflege nach 30 oder 90 Tagen und der Nachweis, dass mindestens ein Verbraucher den Link entdeckt hat. Datenschutzverträgliche Aggregate genügen. Genaue Standorte oder Kontoverläufe einzelner Mitglieder müssen nicht öffentlich werden.

Der Bericht zu APNIC 62 belegt, dass „The case for RIRs“ als Beitrag im Cooperation SIG gehalten wurde. Er macht aus dem Vorschlag des Redners keine APNIC-Politik. Auch der Blog weist darauf hin, dass die Ansichten der Autoren APNIC nicht zwingend repräsentieren. Diese Trennung schafft Platz für Versuche und wahrt zugleich Verantwortungsgrenzen.

Der 3,0-Prozent-Balken sollte daher bleiben. Er ist ein Anlass nachzuforschen. Seine Fußnote ist die Anleitung, nicht zu überziehen. Zuerst müssen Eingänge, Ausfälle, Ausschlüsse und die teilnahmefähige Bevölkerung sichtbar werden. Dann kann eine spätere Grafik zeigen, ob eine einfachere Registry-Oberfläche die Adoption verändert hat oder nur die Erzählung darüber.

Quellen

  1. APNIC Blog — IP-Geolokation bei APNIC 62
  2. Sid Mathur — Self-published Geofeeds; the role of RIRs
  3. Konferenzbericht zu APNIC 62
  4. Geolocate much?
  5. RFC 8805 — Format für selbst veröffentlichte IP-Geolokationsfeeds
  6. RFC 9632 — Auffinden und Verwenden von Geofeed-Daten
  7. RFC 9877 — RDAP-Erweiterung für Geofeed-Daten