Zusammenfassung

  • draft-ietf-netconf-yp-transport-capabilities-07 macht Transportwege, Kodierungen und Sicherheitsprotokolle für YANG-Benachrichtigungen aus Implementierungsdaten oder einem laufenden Server ermittelbar.
  • Der Datensatz ist eine Fähigkeitsliste. Er wählt kein exaktes Tupel, erteilt keine lokale Genehmigung, richtet keinen Empfänger ein, akzeptiert kein establish-subscription und beweist keine Zustellung.
  • Implementierungs- und Laufzeitinformationen haben unterschiedliche Herkunft und Frische. Automatisierung darf beide nicht in einem pauschalen „unterstützt“ zusammenziehen.
  • Ein Entscheidungsbeleg von der Fähigkeit bis zum Abonnement sollte Beobachtung, Auswahl, Richtlinie, Empfänger, Antrag, Ergebnis und Ausweichweg verbinden. Das ist ein redaktioneller Vorschlag, keine IETF-Vorgabe.

Ein zutreffender Eintrag kann eine falsche Gewissheit erzeugen

Revision 07 von YANG Notification Transport Capabilities bearbeitet ein sinnvolles Problem. Bevor ein Managementsystem Benachrichtigungen bestellt, kann es ermitteln, welche Mechanismen ein Server angibt. Das Modell ergänzt das Systemfähigkeitsgerüst um Einträge je Transportprotokoll und um Listen der Kodierungs- und Sicherheitsverfahren.

Im Beispiel steht HTTPS zusammen mit XML und JSON sowie TLS 1.2 und TLS 1.3. Ein zweiter Eintrag verbindet UDP-notif mit JSON und CBOR sowie DTLS 1.2 und DTLS 1.3. Der Orchestrator muss damit keine Variante anfragen, die das Gerät gar nicht nennt.

Problematisch wird die Verdichtung zu einem grünen Feld namens „Benachrichtigungen unterstützt“. Darin verschwinden fünf verschiedene Zustände: entdeckt, ausgewählt, durch die Richtlinie genehmigt, vom Publisher akzeptiert und beim Empfänger in Zustellung. Jeder Zustand hat eine eigene Instanz und einen eigenen Beleg.

Revision 07 erschien am 17. August 2026. Datatracker wurde am 8. September aktualisiert; an diesem Tag endete auch die in der IETF-Last-Call-Ankündigung vom 25. August genannte Kommentierungsfrist. Am Recherchestichtag 9. September blieb das Dokument ein aktiver Internet-Draft mit Ziel Proposed Standard, beim IESG eingereicht und im Zustand „Waiting for AD Go-Ahead“. Eine abgelaufene Frist ist weder ein RFC noch eine endgültige Genehmigung.

Hinter „unterstützt“ laufen zwei Uhren

Die Grundlage RFC 9196 sieht zwei Quellen für Fähigkeitsinformationen vor. Ein Implementierer kann schon vor einem laufenden Knoten YANG-Instanzdaten bereitstellen. Ein aktiver Server kann seinen Stand über NETCONF oder RESTCONF melden.

Implementierungsdaten helfen NMS-Entwicklern, Integratoren und Beschaffern. Sie beschreiben, was eine Produktfamilie oder Implementierung vorsieht. Laufzeitdaten helfen modellgetriebenen Anwendungen und können Lizenzierung, Hardwaregrenzen oder Betriebsänderungen widerspiegeln. RFC 9196 nennt die Laufzeitabfrage ausdrücklich als Mittel, um zu prüfen, ob ein Publisher das zuvor Beschriebene tatsächlich implementiert.

Zwei ehrliche Angaben können deshalb voneinander abweichen. Eine Produktdatei kennt nicht zwingend die eingebaute Karte. Eine um zehn Uhr richtige Antwort kann fünf Minuten später veraltet sein. Ändern sich Fähigkeiten im Betrieb, empfiehlt RFC 9196 On-Change-Benachrichtigungen für den Systemfähigkeitscontainer. Der Verbraucher muss sie jedoch empfangen und mit seiner früheren Auswahl verknüpfen.

Ein Automatisierungsnachweis braucht Quellenart und -ort, Abrufverfahren, Modulrevision, Gerät, Softwarestand, Beobachtungszeit und Verfallsregel. Ohne diese Koordinaten ist „unterstützt“ nicht unbedingt falsch, aber zu unbestimmt, um Handlungsbefugnis zu tragen.

Die Liste begrenzt die Auswahl, sie protokolliert sie nicht

Die Liste transport-capability ist nach dem Transportprotokoll geschlüsselt. Darunter stehen getrennte Leaf-Listen für security-protocol und encoding-format. Das ist ein Entdeckungsmodell, kein Protokoll einer vollzogenen Kombination.

Aus den getrennten Listen darf man umgekehrt keinen erfundenen Fehler ableiten. Die Quellen beweisen nicht, dass der Server fälschlich jede kartesische Kombination zusagt. Die belastbare Aussage ist enger: Die einzelne Mitgliedschaft von Transport, Kodierung und Sicherheit belegt nicht, dass genau das gewünschte Tupel auf dieser Instanz jetzt funktioniert. Es muss ausgewählt, versucht und samt Ergebnis aufgezeichnet werden.

RFC 8639 zieht die nächste Grenze. Ein dynamisches Abonnement existiert beim Publisher nicht schon deshalb, weil ein Subscriber es beantragt. Erst die Annahme von establish-subscription erzeugt es. Der Publisher darf aus mehreren Gründen ablehnen und strukturierte Hinweise liefern, welche Parameter einen neuen Versuch aussichtsreicher machen.

Auch die Annahme beweist keine dauerhafte Zustellung. Sie dokumentiert den Zustand beim Publisher. Der Empfänger kann unerreichbar bleiben, der Datenstrom kann ausgesetzt werden, und eine erste Benachrichtigung kann fehlen. Eine ehrliche Betriebsansicht trennt entdeckt, gewählt, genehmigt, akzeptiert und liefernd.

Ein Managementpfad richtet keinen Benachrichtigungspfad ein

Der Entwurf setzt ein vorhandenes Managementnetz zwischen Orchestrator und Gerät voraus. Managementverbindung und Geräteendpunkt sollen bereits konfiguriert sein. Dadurch lässt sich die Fähigkeitsstruktur abrufen.

Diese Voraussetzung richtet den Benachrichtigungsempfänger nicht ein. Sie ermächtigt auch nicht jede über NETCONF oder RESTCONF authentisierte Identität, einen Strom zu jedem Ziel zu erzeugen. Authentisierung bestimmt den Akteur. NACM und lokale Regeln begrenzen die Handlung. Ein Sicherheitsteam kann das zulässige Profil bestimmen, eine Telemetriegruppe den Empfänger und ein Netzteam die Erreichbarkeit.

Bei verteilter Verantwortung unterstellt leicht jede Seite die Zustimmung einer anderen. Der Netzbetrieb sieht die Fähigkeit, die Sicherheit erwartet nur die bevorzugte Option, und die Plattform nimmt an, das Gerät prüfe sein Ziel. Ohne gemeinsamen Beleg ergeben lokal vernünftige Annahmen eine Handlung ohne klaren Eigentümer.

Der Entwurf bezeichnet die neuen Knoten als schreibgeschützt und nicht sicherheitssensitiv. Er setzt sichere, gegenseitig authentisierte NETCONF- oder RESTCONF-Verbindungen und NACM voraus. Die Liste muss nicht zum Geheimnis erklärt werden. Die Governance-Folge ist eine andere: Auch ein nicht geheimes Faktum kann als nicht autorisierte Anweisung dienen. Lesbare Unterstützung für TLS 1.2 ist keine Genehmigung für einen bestimmten Empfänger.

Prozessbelege bleiben Prozessbelege

Datatracker meldete am 8. September null Fehler und null Warnungen für die YANG-Validierung. Die aktuelle Sicherheitsprüfung stand auf „Ready“, die Transportprüfung auf „Almost ready“; für IANA waren Maßnahmen nötig, die Expertenprüfungen waren in Ordnung. Das sind präzise Reifehinweise, aber keine Produktionsmessungen.

Der Implementierungsabschnitt sagt, Huawei habe das Dokument für einen YANG-Push-Publisher in VRP umgesetzt und Cisco in IOS XR. Derselbe Abschnitt soll vor der Veröffentlichung durch den RFC Editor entfernt werden. Die Angaben zeigen erklärten laufenden Code, keine öffentliche Interoperabilitätsmatrix für Revision 07, keinen Marktanteil, keine Zertifizierung und keine Prüfung aller Tupel.

Die Identität dtls12 setzt noch eine sprachliche Grenze. Ihre Beschreibung nennt DTLS 1.2 veraltet und rät vom Aktivieren ab. Daraus folgt kein Verbot von TLS 1.2, das im HTTPS-Beispiel aufgeführt ist. Richtlinien müssen Protokollidentität und einschlägige Norm lesen, nicht lediglich die Zeichenfolge „1.2“.

Ein Beleg verbindet Möglichkeit und Wirkung

Der vorgeschlagene Entscheidungsbeleg von der Fähigkeit bis zum Abonnement kann im Betriebssystem entstehen, ohne YANG zu verändern. Er identifiziert Gerät, Produktfamilie, Modulrevision und Softwarestand. Er sagt, ob die Beobachtung aus einer Implementierungsdatei oder einer Live-Abfrage kam, wo und wann sie erfolgte und wann sie als veraltet gilt.

Danach hält er den gemeldeten Transporteintrag und das wirklich gewählte Tupel aus Transport, Kodierung und Sicherheit fest. Er ergänzt handelnde Identität, Empfänger und Endpunkt, Richtlinienversion, Parameter und Zeitpunkt des Antrags. Er unterscheidet Annahme, Ablehnung, Zeitüberschreitung, spätere Beendigung und Annahme ohne erste Lieferung.

Fehlerhinweise, Wiederholungen, Ausweichwege und die Instanz, die eine schwächere Option genehmigte, bleiben angehängt. So kann eine Automatisierung ihre Erfolgsquote nicht unbemerkt durch einen Sicherheitsrückschritt erhöhen.

The Policy Mirror fragt nach dem Feld mit tatsächlicher Wirkung: Der Fähigkeitsbaum schreibt Möglichkeit, die Richtlinie Erlaubnis, der Publisher Existenz und der Empfänger Nutzen. Running-Code Primacy verlangt, diese Ausführungsspuren zusammenzuführen. Reality, Not Advocacy begrenzt die Behauptung: Der Entwurf liefert eine bessere Liste, keine automatische Zustellung. Für die Bestellung braucht der Betreiber einen eigenen Beleg.

Quellen