Zusammenfassung

  • Am 8. September 2026 vermerkte der RFC Editor die Zustimmung des Autors und kennzeichnete den künftigen RFC 10040 als bereit für die Veröffentlichungsvorbereitung. Am 9. September befand er sich weiterhin in Final Review und war noch kein veröffentlichter RFC.
  • Das neue LISP-Geo-Location-Format überträgt Punkte, gröbere Geo-Prefixes und eine Unsicherheitsangabe. Zugriffspolitik, Verschlüsselung und LISP-SEC-Signaturen sichern unterschiedliche Teile der Verteilung.
  • Eine gültige Signatur ordnet die Map-Reply ihrem Unterzeichner zu. Sie belegt nicht unabhängig, wie und wann die Koordinate gemessen wurde. Wer auf die physische Lage vertraut, braucht zusätzlich einen Herkunftsbeleg für die Positionierung.

Der letzte redaktionelle Schritt ist keine Vermessung

Der Nachrichtenanlass ist eng umrissen. Final Review für draft-ietf-lisp-geo begann am 31. August. Die Warteschlange des RFC Editors verzeichnet am 4. September die Zustimmung des Area Director und die Aktualisierung des IANA-Registers. Am 8. September stimmte Dino Farinacci zu; seither lautet der Arbeitsvermerk „Ready to prepare document for publication“. Der Status blieb am 9. September dennoch „In Final Review“. Gemeint ist also der künftige RFC 10040 mit vorgesehenem Experimental-Status, nicht ein bereits veröffentlichter RFC oder Proposed Standard.

In dieser Phase wird der Veröffentlichungstext abgeschlossen. Redaktionelle Punkte klären Autoren und RFC Production Center; Änderungen technischer Substanz benötigen die Zustimmung des zuständigen Stream Managers. Die sichtbaren Fragen zu Begriffen, WGS 84, dem IANA-Verweis und der Beschreibung des Signierens passen zu einem Dokument am Ende seines institutionellen Wegs.

Gerade die fertige Form kann eine falsche Gewissheit erzeugen. Nummerierter Typ, binäres Layout und kryptografische Signatur sehen aus wie ein einheitlicher Beweis. Tatsächlich stammen die Eigenschaften aus verschiedenen Vertrauensbeziehungen. Eine Map-Reply kann authentisch und unverändert sein, während die enthaltene Breite und Länge eine Behauptung ohne im Protokoll dokumentierte Feldmessung bleibt.

Typ 17 stellt einen Ort dar, erzeugt aber keine Beobachtung

Das Dokument definiert Geo-Location-Typ 17 im LISP Canonical Address Format und ersetzt den älteren Geo-Coordinates-Entwurf aus RFC 8060. Ein Datensatz kann einen Geo-Point oder ein Geo-Prefix ausdrücken. Der Punkt bleibt präzise; das Prefix erweitert ihn absichtlich zu einer Fläche. Location Uncertainty wird in Zentimetern angegeben und kann Unsicherheit bei Radius und Höhe abbilden.

Damit wird die Aussage reicher, nicht ihre Herkunft. Koordinaten können aus Vermessungsgeräten, GNSS-Empfängern, einer konfigurierten Inventarliste, einem Datenanbieter oder manueller Eingabe stammen. Auch die Unsicherheit kann statistisch berechnet, als vorsichtiger Schutzbereich festgelegt oder lediglich geschätzt worden sein. Dass all dies in dasselbe Feld passt, macht die Verfahren nicht gleichwertig.

Das ist weniger ein Fehler des Formats als seine Grenze. Das Positionierungssystem erzeugt eine Beobachtung. Ein Mapper bindet sie an EID oder RLOC. Der Map-Replier signiert die daraus gebaute Antwort. Wer die Kette nur „signierter Ort“ nennt, verwischt die Entscheidungen und lässt ein Objekt sich scheinbar selbst beweisen.

RFC 6280 trennt den Lebenszyklus von Ortsdaten deshalb in Positionierung, Verteilung und Nutzung. Ein Mechanismus kann die getreue Übermittlung vom Ersteller zum Empfänger beweisen, ohne die physische Wahrheit der ursprünglichen Aussage zu prüfen. Sobald die Koordinate in Routing, Automatisierung oder Verwaltung wirkt, wird diese architektonische Trennung praktisch.

LISP-SEC authentifiziert den Antwortenden, nicht den Vermesser

Beim künftigen RFC 10040 liegt die Zugriffsentscheidung gewöhnlich in der lokalen Politik des xTR. Antwortet ein Mapping Service Provider stellvertretend, muss er die Politik des xTR anwenden. Ein berechtigter Anfragender kann eine nach LISP-SEC signierte und gegebenenfalls verschlüsselte Map-Reply erhalten. Das schützt Herkunft, Integrität, Vertraulichkeit und den Kreis der Empfänger.

Die Signatur zeigt jedoch nicht, ob vor Sekunden oder Monaten gemessen wurde, ob der Sensor kalibriert war, ob sich das Objekt bewegt hat, ob ein Übertragungsfehler vorliegt oder ob der Unsicherheitsradius aus Messdaten stammt. Zugriffsgenehmigung beantwortet, wer die Behauptung empfangen darf. Sie entscheidet nicht, ob die Behauptung noch zur Außenwelt passt.

Der Text selbst benennt mehrere Vertrauensbeziehungen und warnt davor, dass Koordinaten Hosts verfolgbar machen können, wenn EIDs Hosts zugewiesen sind. Geo-Prefix kann die Genauigkeit verringern, ein kurzer TTL die Lebensdauer begrenzen, Authentifizierung und Richtlinie können Anfragen beschränken. Die typische Anwendung nennt öffentliche Bauwerke und Landmarken statt Menschen, Fahrzeuge oder Geräte. Das reduziert Exposition, ersetzt aber weder Provenienz noch Nutzungsregeln. RFC 6973 fordert zusätzlich Datenminimierung, begrenzte Aufbewahrung und Kontrolle von Sekundärnutzung.

Ein Beleg für den Augenblick, in dem Lage zur Entscheidungsgrundlage wird

Die fehlende Verbindung sollte nicht in die Bedeutung der Signatur hineingelesen werden. Sie kann als portabler Beleg neben der Map-Reply stehen. Handelt ein Netzbetreiber, Versicherer, Notfalldienst, Regulierer oder automatischer Controller wegen eines angegebenen Orts, muss der Nutzer die Beweiskette der Ortsbehauptung prüfen können.

Der Beleg sollte Subjekt oder Anlage, Positionierungsverfahren, Sensor oder Vorquelle, Beobachtungszeit, Koordinatenreferenzsystem, Verfahren der Unsicherheitsberechnung, Mapper, Signierer, Version oder Epoche der Zugriffsrichtlinie, Ablaufbedingung und spätere Prüfergebnisse nennen. Vertrauliche Rohspuren müssen nicht jedem offengelegt werden. Assurance-Klassen, kryptografische Bindungen oder Audit-Verweise können genügen. Entscheidend ist, dass die Entstehungsbedingungen bei der Entscheidung nicht verloren gehen.

Das ist mein Governance-Vorschlag, keine IETF-Vorgabe. Ein Darstellungs- und Verteilungsprotokoll sollte nicht jeden Sensor zertifizieren müssen. Ein Nutzer mit folgenreicher Entscheidung sollte aus einer gültigen Signatur aber auch keine physische Wahrheit ableiten dürfen.

Heng Lus Policy Mirror lenkt den Blick auf Wahl und Folge. Der Mapper wählt Quelle und Präzision; der xTR oder sein Proxy kontrolliert die Offenlegung; der Map-Replier signiert; der Betreiber trägt die Folgen einer veralteten oder schwach belegten Koordinate. Ein Beleg macht diese Übertragung sichtbar. Er folgt zugleich der Running-Code-Disziplin: das interoperable Format eng halten und dort zusätzliche Evidenz verlangen, wo Software institutionelle Macht ausübt.

Quellen