Zusammenfassung

  • Revision 21 bestimmt den Publisher Parent als Instanz, die eine Network Node Subscription in überlappungsfreie Component Subscriptions zerlegt, und verlangt mindestens eine Message Publisher ID im Subscription-Zustand.
  • Die Agent-Liste des Parent ist eine zeitgebundene Erklärung seiner Aufteilung. Sie beweist weder vollständige Auswahl noch lückenlose Lieferung jedes Prozesses.
  • Belastbare Kontinuität verbindet Knotenkontext, aktuell erwartete Publisher, Prozessidentität, Sequenzepoche, gegebenenfalls Message ID, Beobachtungszeit und die Historie des Subscription-Zustands.

Eine Zuständigkeit wird im Last Call berichtigt

draft-ietf-netconf-distributed-notif-21 erschien am 6. September 2026, während das NETCONF-Arbeitsgruppendokument bis zum 8. September im IETF Last Call stand. Es ist als Proposed Standard vorgesehen und beim IESG eingereicht, bleibt aber ein Internet-Draft. Weder RFC-Veröffentlichung noch Einsatz sind belegt.

Revision 20 hatte von IANA die Bewertung IANA - Not OK erhalten. Beanstandet wurden ein ungültiges XML-Beispiel und unklare künftige Registrierungen. Revision 21 repariert die Anführungszeichen, überarbeitet den Registrierungstext und berichtigt sicherheitsrelevante YANG-Pfade. Der Status lautet nun Version Changed - Review Needed: erneute Prüfung, nicht abgeschlossene Registrierung.

Die wichtigste Änderung betrifft das Subjekt. Der Subscriber hält die Knoten-Subscription beim Parent; anschließend zerlegt der Publisher Parent sie in Komponenten. Der Subscriber kennt seinen Informationsbedarf. Der Parent kennt Agents und Fähigkeiten des Knotens. Deshalb liegt die Entscheidung über die Abdeckung im Knoten – samt Verantwortung für ihre Begründung.

min-elements 1 für die Zustandsliste message-publisher-id verhindert zudem eine leere Publisher-Menge. Das ist ein prüfbarer Beleg, aber keine Garantie, dass die Menge vollständig ist.

Die gemeinsame ID bezeichnet einen Vertrag

Der Collector kann Subscriber und mehrere Receiver trennen. Nur der Parent erhält Anfragen. Er veröffentlicht Fähigkeiten, erstellt nicht überlappende Component Subscriptions, übergibt Eigenschaften an Agents und hält den Gesamtzustand. Agents erben ID und Lebenszyklus, sammeln ihren Teil und senden direkt an Receiver.

Die Subscription ID bündelt somit mehrere Emissionen zu einem logischen Vertrag; sie identifiziert keinen einzelnen Prozess. Ein aggregiertes Diagramm kann ruhig bleiben, während ein Agent schweigt. Weniger Nachrichten können reale Ruhe, eine neue Aufteilung, einen Neustart oder Transportverlust bedeuten.

Die Parent-Agent-Koordination ist ausdrücklich nicht spezifiziert; die Zuordnung von YANG-Teilbäumen bleibt implementierungsspezifisch. Überlappungsfreiheit verhindert Doppelzählung unter deklarierten Komponenten. Sie beweist keine vollständige Abdeckung des laufenden Knotens.

Deklariert, beobachtet und tatsächlich laufend

Alle Lebenszyklusmeldungen stammen vom Parent. subscription-started und subscription-modified enthalten die aktuelle Publisher-Liste; ändert sich die Zerlegung, folgt eine neue Liste. Diese Meldungen sind als datierte Erklärungen aufzubewahren.

Drei Mengen dürfen nicht verschmelzen: die vom Parent deklarierte, die vom Receiver beobachtete und die im Gerät laufende, die laut Inventar und Konfiguration beitragen müsste. Stimmen die ersten beiden überein, wurden nur alle deklarierten Agents gehört. Eine ausgelassene Linecard oder ein falsch zugeteilter Teilbaum kann unsichtbar bleiben.

Symbolische Klarheit ersetzt keine Betriebsrealität. Die Erklärung wird erst durch Abgleich mit Inventar, Fähigkeiten und Konfiguration stark. Abweichungen brauchen einen Verantwortlichen und einen Zeitraum, nicht nur eine geglättete Ampel.

Kontinuität ist pro Prozess zu führen

Jedes push-update oder push-change-update kann die lokale Message Publisher ID des Ursprungprozesses tragen. Der Envelope-Entwurf ergänzt optional Hostname und prozessbezogene Sequenz: 32 Bit, Start bei 1, sichtbarer Umlauf über 0 nach 4.294.967.295. Die Beobachtungszeit bezeichnet die Messung, nicht zwingend Ereignis-, Kodier- oder Lieferzeit.

Identität beantwortet wer, Sequenz zeigt Lücken einer Epoche, Message ID hilft bei Duplikaten, Zeit verortet die Beobachtung und Zustandshistorie sagt, wer erwartet wurde. Neustarts eröffnen neue Epochen; alte Nachrichten können verspätet eintreffen; lokale IDs können zwischen Knoten kollidieren. Der Kontinuitätsschlüssel benötigt deshalb Knoten, Prozess, Epoche und das gültige Parent-Intervall.

Eine Adresse kann mehrere Autoritäten verdecken

Alle Agents erscheinen mit derselben Quell-IP. Bei UDP können sie sogar den Quellport teilen; bei HTTPS verlangt die Architektur einen eigenen Port pro Softwareprozess. Fünf-Tupel, TLS-Endpunkt und Subscription ID sind Routingkontext, kein vollständiger Herkunftsnachweis.

Der UDP-Entwurf kombiniert Publisher ID und Message ID und kann bei wiederverwendeten lokalen IDs zusätzlich die Quell-IP benötigen. Für große Benachrichtigungen soll er nicht von IP-Fragmentierung abhängen. Ein System, das den fehlenden Agent erkennt, dessen größte Nachricht aber nicht sicher transportiert, erzeugt erneut stillen Verlust.

Direktes Publizieren verteilt die Sicherheitsgrenze

Linecards oder Netzwerkprozessoren können direkt senden und damit den zentralen Route Processor aus dem Datenpfad nehmen. Zugleich verteilen sich Authentisierung, Autorisierung, Schlüssel, Raten- und Ressourcenlimits. Sichere NETCONF- oder RESTCONF-Transporte und NACM bleiben wichtig; ihre wirksamen Identitäten und Durchsetzungspunkte sind jedoch lokale Deployment-Fakten. Eine Regel am Parent beweist keine gleichwertige Durchsetzung an jedem Agent.

Publisher IDs legen interne Prozessanordnung offen. Änderungen können Neustarts, Ausbau oder Umverteilung zeigen. Dieselbe Sichtbarkeit unterstützt Audits und feindliche Kartierung oder Spoofing. Der Zugang zur Roh-Topologie sollte begrenzt werden, ohne die Identität aus der Beweiskette zu entfernen.

Die offene Frage des Last Call

Der Text verlangt Publisher-Identität in Update-Benachrichtigungen, während der aktuelle YANG-Baum die message-publisher-id pro Nachricht als optional darstellt. Das neue Minimum betrifft die Zustandsliste, nicht automatisch jedes Update. Das ist kein vorweggenommenes Fehlerurteil, sondern eine Prüfungsfrage: Unter welchen Bedingungen soll ein Receiver eine nicht zuordenbare Nachricht ablehnen oder isolieren?

Getrennt zu testen sind eine nicht leere Liste, die Identität in jedem Update, ihre Zugehörigkeit zur damals gültigen Menge und die Reaktion auf Abweichungen.

Grenzen

Die Quellen belegen Text, Versionsgeschichte und Prüfstatus. Sie belegen weder Herstellerübernahme noch Konformität, reale Topologie, Verlust, Latenzgewinn, Vorfall oder Ausnutzung. Auch Envelope-, UDP- und HTTPS-Dokumente sind Entwürfe.

Beständig ist die engere Aussage: Zerlegen, deklarieren, senden, beobachten und abgleichen sind verschiedene Handlungen. Eine einzige ID kann sie nicht ohne Verantwortungsverlust zusammenfassen.

Quellen