Zusammenfassung

  • In RFC 9675 formuliert der entfernte Manager Richtlinien, während der Agent am Gerät lokale Daten prüft, Controls autorisiert und ausführt.
  • Ein Control besitzt keinen synchronen RPC-Rückgabecode; Berichte können warten, verfallen, ersetzt, zusammengefasst oder außerhalb ihrer Ereignisreihenfolge zugestellt werden.
  • Belastbares Management hält Ziel, Kodierung, Verwahrung, Empfang, Autorisierung, frische Vorbedingungen, Ausführung, Wiederherstellung, Berichtserzeugung, Warteschlange, Abgleich und spätere Beobachtung auseinander.

Drei Zeitpunkte, drei verschiedene Aussagen

Ein Sensorwert liegt innerhalb des erlaubten Bereichs, als eine lokale Regel ihn prüft. Der Agent startet daraufhin ein Control. Wenig später erzeugt er einen Bericht über die Entscheidung. Erst Stunden danach öffnet sich ein Übertragungsfenster, und der Bericht erreicht den Manager. Zu diesem Zeitpunkt hat sich die Umgebung bereits verändert.

Der Wert war frisch genug für die damalige Regel. Der Bericht beschreibt die damalige Entscheidung korrekt. Seine Zustellung ist ebenfalls echt. Keine dieser Aussagen macht den Wert bei Ankunft wieder frisch.

Das Beispiel ist hypothetisch und behauptet keinen Vorfall in einem realen System. Es zeigt eine besondere Gefahr asynchroner Verwaltung: Integrität und Aktualität sind verschiedene Eigenschaften. Wer sie in einer grünen Statusanzeige zusammenführt, verwandelt eine historische Beobachtung in eine gegenwärtige Behauptung.

RFC 9675 schafft die Architektur, damit der Agent trotz der Verzögerung handeln kann. Die Beweiskette muss sichtbar machen, auf welchen Zeitpunkt sich jede Aussage bezieht.

Was der RFC tatsächlich festlegt

RFC 9675, „Delay-Tolerant Networking Management Architecture“, erschien im November 2024. Er gehört zum IETF Stream, wurde vom IESG gebilligt und steht für Konsens der IETF-Gemeinschaft. Sein Status ist Informational, nicht Internet Standards Track.

Das Dokument beschreibt eine logische und informationelle Architektur. Es benennt Komponenten, ermöglichtes Verhalten und Anwendungsfälle, liefert aber keine vollständige funktionale Konstruktion und keine erschöpfenden Schnittstellen. BPv7 ist nicht vorgeschrieben. Auch Auswahl von Transport, Benennung, Adressierung, Routing und Kommunikationssicherheit liegt außerhalb des DTNMA-Umfangs.

Diese Eingrenzung verhindert zu große Behauptungen. Der RFC ist kein Nachweis, dass ein benanntes Produkt DTNMA implementiert, eine Nachricht empfangen, ein Control autorisiert oder einen Zielzustand erreicht hat. Beobachtbare Einführung zeigt sich erst in betriebenen Managern und Agents, Modellen, Regeln, Control-Definitionen, Berichtsschemata, Queue-Richtlinien und Ausführungsprotokollen.

Die Ausgangslage ist dennoch konkret. Herausfordernde Netze können tagelang ohne rechtzeitigen Ende-zu-Ende-Austausch bleiben. Geräte schlafen, Links sind einseitig oder asymmetrisch, und Infrastruktur wie DNS oder Zertifizierungsstellen ist nicht ständig erreichbar. Ein Kontakt kann enden, bevor eine einzige Hin- und Rückübertragung abgeschlossen ist.

Der Manager konfiguriert den örtlichen Operator

Der DTNMA Manager übernimmt die Rolle des entfernten Operators. Er empfängt Ziele von Managementanwendungen, kodiert sie als Richtlinie, bündelt Nachrichten und adressiert sie an Agents. Der DTNMA Agent ist der örtliche Operator am verwalteten Gerät. Er sammelt und fusioniert Daten, validiert Informationen, autorisiert Aktionen, führt Controls aus und behandelt Fehler.

Daraus entstehen zwei Ebenen: Verwaltung der Konfiguration des lokalen Operators und Betrieb des Geräts durch diesen Operator. Ein entferntes Ziel wird nicht direkt zum Anwendungs- oder Gerätezustand. Es erreicht eine lokale Entscheidungsfläche mit eigenen Regeln, Ressourcen, Messungen und konkurrierenden Änderungen.

Selbst bei schneller Verbindung bleibt das Control lokal. Der Empfang ist ein Reiz für die Autonomie des Agents; die Sitzung, die ihn transportiert hat, muss nicht bestehen bleiben. Der Manager definiert Ziel und zulässigen Rahmen, der Agent entscheidet anhand der aktuellen lokalen Bedingungen.

Für die Prüfung sind deshalb zwei Protokolle erforderlich: Was sollte mit welcher Autorität geschehen, und was durfte unter welchen lokalen Tatsachen tatsächlich geschehen?

Ein Control ist kein RPC mit langem Timeout

Ein Control ist eine parametrisierte, vordefinierte Prozedur, die der Agent aufgrund einer Manager-Anweisung oder einer lokalen Regel ausführt. Ein Makro ordnet mehrere Controls.

RFC 9675 unterscheidet Controls ausdrücklich von RPCs: Sie kennen keinen Rückgabecode. Ein solcher Code würde eine synchrone Beziehung zwischen Aufrufer und Prozedur voraussetzen, die in der beschriebenen Umgebung fehlen kann.

Ein sehr langer Timeout repariert dieses Modell nicht. Bei Beginn der Ausführung kann das Ziel abgelaufen, ein Eingangswert veraltet oder eine konkurrierende Änderung aktiv sein. Ein Makro kann nach dem ersten verändernden Schritt scheitern. Der Fehler wird zum Zustand des Agents und kann Rollback, Safing oder eine weitere lokale Regel auslösen, lange bevor die Gegenstelle davon erfährt.

Ein nützlicher Beleg enthält Richtlinienversion, Empfangszeit, Autorisierung, Eingänge samt Frische, Vorbedingungen, jeden Schritt, Konflikte, Rücknahme und spätere Beobachtung. „Abgeschlossen“ ist nur eine verdichtete Ablaufmarke. Es beweist weder das Ziel noch dessen Fortbestand.

Offene Schleifen lösen die Paarbildung auf

Eine Anwendung kann auf eine Antwort warten oder weitere Richtlinien in einer offenen Schleife senden. Eine geschlossene Schleife kann in DTNMA Millisekunden, Stunden, Tage oder Jahre dauern.

Zwischen Controls und Berichten gibt es keine zwingende Eins-zu-eins-Beziehung. Ein Bericht kann den Endzustand nach mehreren Controls abbilden. Ein Control kann mehrere Berichte beeinflussen. Die Zuordnung kann fehlen, und ein erzeugter Bericht kann vor Übertragung aus der Warteschlange verschwinden.

Eine Nachrichten-ID zeigt, welches Objekt verwahrt wurde, nicht welchen Zustand es bewirkte. Eine Richtlinien-ID benennt Absicht, nicht Gültigkeit zum Empfangszeitpunkt. Eine Control-ID benennt die Prozedur, nicht ihre real verwendeten Eingänge oder spätere Korrekturen.

Ein belastbares Journal verbindet Ziel, Kodierung, Verwahrung, Agent-Autorisierung, Ausführung, Beobachtungen, Bericht und späteren Zustand, ohne sie zu verschmelzen. Wenn ein Bericht drei Controls zusammenfasst, muss diese Viele-zu-eins-Beziehung erhalten bleiben. Die Oberfläche darf ihn nicht nachträglich zur Antwort auf den zuletzt sichtbaren Befehl erklären.

Empfangsreihenfolge ist keine Ereignisreihenfolge

Berichte entstehen abhängig vom lokalen Zustand und unabhängig von einer Verbindung zum Manager. Sie können gespeichert, über verschiedene Wege transportiert und erneut gesendet werden. RFC 9675 warnt den Manager davor, Bedeutung aus ihrer Empfangsreihenfolge abzuleiten.

Jeder Bericht braucht Erzeugungszeit, Agent-Identität, Schema, Richtlinien- und Regelkontext. Der API-Empfangszeitpunkt ist für den Transportbetrieb nützlich, ersetzt aber nicht den Beobachtungszeitpunkt. Sind Uhren unsicher, gehört die Unsicherheit in den Datensatz; eine erfundene Totalordnung verbessert nur die Grafik.

Begrenzter Speicher erzeugt eine weitere Lücke. Ein Bericht kann ablaufen, durch einen neueren ersetzt oder ungesendet entfernt werden. Schweigen kann heißen: kein Ereignis, unterdrückte Meldung, wartender Bericht, Verfall, fehlende Berechtigung, geändertes Ziel, fehlender Transport oder nicht verfügbarer Agent. Schweigen allein wählt keine dieser Erklärungen aus.

Fusion spart Übertragung und verändert die Evidenz

Ein Agent kann Messungen und Zähler zu Minima, Maxima, Mittelwerten, Alarmen oder Endzuständen verdichten. Das ist bei kurzen Kontakten notwendig. Das Fusionsprodukt ist jedoch ein neues Objekt, erzeugt durch eine bestimmte Regel und Version; es ist kein verlustfreies Archiv der Eingaben.

Nach einer Regeländerung können ähnlich aussehende Berichte unvergleichbar sein. Eine korrekte Endlage kann den Zwischenfehler auslassen, der einen späteren Sicherheitszustand erklärt. RFC 9675 verbietet Rohdatenaufbewahrung nicht und weist auf ihren Wert für die Analyse komplexer Wechselwirkungen hin. Welche Beobachtungen unersetzlich sind, muss vor dem Speicherdruck entschieden werden.

Auch Frische ist zeitgebunden. Ein Wert ist für eine Entscheidung nur innerhalb eines relevanten Horizonts frisch. Authentizität schützt Herkunft und Unversehrtheit; sie erneuert den Inhalt nicht. „Signiert“ und „aktuell“ gehören daher in getrennte Felder.

Mehrere Manager erzeugen eine Autoritätsgeschichte

RFC 9675 unterstützt Viele-zu-viele-Zuordnungen. Von wem ein Agent Control annimmt und wem er berichtet, kann getrennt festgelegt werden. In verschiedenen Partitionen können unterschiedliche Manager erreichbar sein.

Die Flexibilität erfordert expliziten Umfang, Vorrang, Ablauf und Konfliktregeln. Nach der Wiederverbindung muss nachvollziehbar bleiben, welche Manager-Zuordnung galt, welche Richtlinien konkurrierten, wie der Agent autorisierte und welche lokale Regel gewann. Der zuerst zugestellte Bericht verleiht seinem Manager keine rückwirkende Oberhoheit.

Sicherheit hebt die Ebenen nicht auf. Authentifizierte Verwahrung beweist keine Control-Berechtigung. Berechtigung beweist keine frischen Vorbedingungen. Ausführung beweist keine Zielerreichung. Ein signierter, vertraulicher Bericht kann authentisch und dennoch veraltet, unvollständig oder fehlgeordnet sein.

Die Belegleiter asynchroner Steuerung

Am Anfang stehen Zielzustand, Umfang, Autorität, Version, Entscheidungszeit und Ablauf. Danach folgen exakte Manager-Kodierung, adressierte Agents, Aggregationskontext und Store-and-forward-Verwahrung. Beim Agent werden empfangene Bytes, Autorisierung, frische Eingaben, Ressourcenlimits und Konkurrenzprüfungen erfasst.

Für die Ausführung bleiben jedes Control und jeder Makroschritt, Zustandsänderungen, Fehler, Rollback und Safing erhalten. Rohe und fusionierte Beobachtungen tragen Quelle und Frische. Berichte dokumentieren Schema, Erzeugung, beitragende Controls, Queue-Einfügung, Ersetzung, Ablauf, Entfernung und Versand. Der Manager gleicht nach Ereigniskontext statt Ankunft ab.

Erst die letzte Stufe ist eine neue, unabhängige und zeitlich begrenzte Beobachtung für eine Entscheidung, die wirklich Gegenwartswissen braucht. Sendung, Empfang oder Berichtserzeugung dürfen nicht an ihre Stelle rücken.

Von gemeinsamer Sprache zu sichtbarer Einführung

Der Informational-Status und die logische Abstraktion sind die korrekte Reichweite des RFC. Das gemeinsame Dokument koordiniert Rollen; Implementierungen treffen lokale Entscheidungen zu Transport, Sicherheit und Wiederherstellung; laufender Code und Belege zeigen die tatsächlich wirksame Ordnung.

Heng Lus Perspektiven auf minimale Anfangsspezifikation, Realitätsebenen und running code helfen, diese Flächen nicht zu verwechseln. Geschriebene Richtlinie, ausführbare Regel, angezeigter Bericht und physische Folge sind verbunden, aber nicht identisch.

Eine schwer beobachtbare Umgebung senkt den Evidenzstandard nicht. Sie macht Zeit, Autorität, Kausalität und dokumentierte Lücken wichtiger.

Quellen