Zusammenfassung

  • Revision 11 ordnet einer QUIC-Verbindung eine NETCONF-Sitzung zu, clientinitiierte bidirektionale Streams den Konfigurations-RPCs und jeder Subscription einen serverinitiierten unidirektionalen Stream.
  • Diese Zuordnung macht Transport und Sitzungsgrenzen prüfbar; Identität, NACM-Entscheid, Transaktion, Datastore-Übergang, angewandter Gerätezustand und Netzverhalten brauchen weiterhin eigene Belege.

draft-ietf-netconf-over-quic-11 ist vor allem ein Entwurf über Grenzen. Eine QUIC-Verbindung trägt genau eine NETCONF-Sitzung. Konfigurations-RPCs laufen über bidirektionale Streams, die der Client eröffnet. Notifications laufen über unidirektionale Streams des Servers, jeweils einer pro Subscription. Damit lässt sich ein Befund genauer einer Verbindung, Sitzung, Stream-Zuordnung, Nachricht oder Operation zuweisen.

Gerade diese Klarheit verführt dazu, die Belege zusammenzuschieben. Geordnete Bytes sind ein Transportfakt. Ein akzeptiertes Zertifikat ist ein Identitätsfakt. NACM liefert einen Berechtigungsentscheid. Framing bestimmt eine Nachrichtengrenze. <ok/> gehört zur Protokolltransaktion. running, intended und operational sind unterschiedliche Zustände. Der Effekt auf Routing oder Dienstqualität ist nochmals eine eigene Beobachtung.

Revision 11 wurde am 25. August 2026 eingereicht. Der IETF Datatracker führt sie als aktiven Internet-Draft der NETCONF Working Group mit Ziel Standards Track, WG-Status WG Document und IESG-Status I-D Exists. Die Historie hält das Datum fest. Der Entwurfstext bezeichnet sich als laufende Arbeit und nennt den 26. Februar 2027 als Ablaufdatum. Das ist weder RFC noch Nachweis für Implementierung, Betrieb, Interoperabilität, Leistung oder Verbreitung.

Zuerst den tatsächlich ausgehandelten Dienst belegen

RFC 7301 definiert ALPN. Revision 11 beantragt den Bezeichner noq und UDP-Port 831. Ein Antrag ist keine Zuteilung: Im für diese Analyse gesicherten IANA-Register der ALPN Protocol IDs steht noq nicht.

Ein belastbarer Verbindungsbeleg enthält deshalb den wirklich ausgehandelten ALPN-Wert, Endpunkte, Port, QUIC-Parameter, Zeitpunkt und Softwareidentität. Eine Zeichenfolge in einer Konfiguration beweist keine Aushandlung. Selbst eine erfolgreiche Aushandlung belegt nur die Anwendungsauswahl für diese Verbindung, nicht die vollständige Umsetzung des Entwurfs.

Zertifikat, NETCONF-Name und Berechtigung auseinanderhalten

RFC 8446 beschreibt TLS 1.3, RFC 9001 dessen Einsatz in QUIC. RFC 7589 trennt die Zertifikatsprüfung von der geordneten Abbildung einer Zertifikatsidentität auf einen NETCONF-Benutzernamen; RFC 9144 aktualisiert dieses Profil für TLS 1.3.

Zu sichern sind Kette, Trust Anchor, Sperrstatus, Prüfergebnis, Mapping-Regel, Reihenfolge und Version. Danach beginnt erst die Autorisierung. RFC 8341 lässt NACM über Operationen, Datenknoten und Notifications entscheiden. Wer einen Schlüssel kontrolliert, darf nicht automatisch einen bestimmten Konfigurationsknoten ändern.

Eine neue Verbindung als neue Sitzung behandeln

Die Eins-zu-eins-Zuordnung macht Verbindungs-ID, Sitzungs-ID, Principal, ausgehandelte Werte, Anfang, Ende und Schließgrund zu einer abgeschlossenen Unterhaltung. Bricht sie ab, beginnt die nächste Verbindung eine neue Sitzung. Hat der Controller die Antwort verloren, kann er einen bereits verarbeiteten RPC erneut senden. Der neue Transport kennt die alte Transaktion nicht.

Revision 11 untersagt Early Data. Das ist bedeutsam, weil RFC 9001 für 0-RTT keinen eingebauten Replay-Schutz zusichert und Anwendungsaktionen mehrfach verarbeitet werden können. Das Verbot schließt diese Oberfläche, nicht jedoch Wiederholungen nach unklaren Fehlern. Dafür braucht es eine stabile Intent-ID, die Abstammung der Versuche, serverseitige Transaktionsaufzeichnungen und Idempotenzregeln.

Stream und Subscription gemeinsam buchen

RFC 9000 stellt geordnete Byte-Streams bereit. Ein Konfigurations-RPC läuft auf einem clientinitiierten bidirektionalen Stream. Eine Subscription entsteht zunächst durch einen RPC; nach Annahme öffnet der Server ihren eigenen unidirektionalen Stream.

Der Prüfbeleg kann Verbindung, Sitzung, Stream-ID, Initiator, Richtung, message-id oder Subscription-ID und Lebenszyklus verbinden. Beide Enden müssen die Zuordnung Subscription–Stream verfolgen; der Entwurf lässt ihre Umsetzung außerhalb seines Umfangs. Wer Stream 19 speichert und Subscription 604 verliert, kennt den Kanal, aber nicht mehr die Herkunft der Nachricht.

Stream-interne Ordnung nicht zur Gesamtordnung erklären

QUIC ordnet Bytes innerhalb eines Streams. Zwischen verschiedenen Streams besteht keine solche Ordnung. Ein RPC und eine Notification können unabhängig vorankommen; ihre Ankunftsfolge ist kein zugesichertes Kausalverhältnis.

Auch QUIC-STREAM-Frame-Grenzen bleiben für die Anwendung nicht erhalten. Ein NETCONF-Chunk ist daher nicht ein QUIC-Frame. RFC 6241 definiert NETCONF: hello nutzt den End-of-Message-Delimiter. Nach der Aushandlung von base:1.1 verwendet Revision 11 das Chunked Framing aus RFC 6242, das die Einschleusung des alten Delimiters verhindert. Der Beleg trennt rekonstruierte Bytes, Chunk-Längen und vollständige Nachricht. Erfolgreiches Parsen beweist weder Sinn noch Erlaubnis oder Wirkung.

<ok/> als Protokollquittung lesen

Die message-id ordnet RPC und rpc-reply einander zu. rpc-error meldet einen Fehler; <ok/> besagt, dass für die Protokolloperation weder Daten noch Fehler zurückzugeben sind. Das verhindert Verwechslungen paralleler Anfragen, beobachtet aber nicht das Gerät.

Für Edit oder Commit gehören Ziel-Datastore, Operationsoptionen, Transaktions-ID, Vorher-/Nachher-Hash und spätere Fehler oder Rollbacks in dieselbe Akte. Für NACM sind Principal, Zielpfade, wirksames Regelwerk, getroffene Regel, Entscheid und Version nötig. Fehlt das, wird Identität fälschlich zu Berechtigung.

Den angewandten Zustand separat feststellen

RFC 8342 unterscheidet konventionelle Konfiguration, intended und operational. Ein System kann eine Absicht zu verwirklichen versuchen, ohne sie wegen einer fehlenden Ressource tatsächlich anzuwenden. Die positive RPC-Antwort belegt die Datastore-Entscheidung; ein zeitgebundener Readback des Operational State ist ein anderer Beleg.

Danach folgt das Netz: RIB/FIB, Nachbarschaften, Zähler, aktive Verkehrsproben oder Diensttests, passend zur Änderung. Zeitliche Nähe allein schafft ohne Mechanismus, Baseline und Beobachtungsfenster keine Kausalität.

Auch Notifications benötigen ihren Vertragskontext. RFC 8639 definiert Subscription-ID, Empfänger, Filter und Lebenszyklus. RFC 8641 ergänzt periodisches und On-change-YANG-Push, Dampening und Synchronisierung. Ein unversehrter Stream kann eine gefilterte oder verzögerte Sicht enthalten. Darum müssen Datastore, Filter, Trigger, Empfänger, Policy-Version und Beendigungsereignis an die Stream-Zuordnung gebunden bleiben.

Zehn schmale Belege statt geborgter Gewissheit

Eine verteidigbare Kette umfasst ausgehandeltes ALPN, TLS-Identität, NETCONF-Namen, Sitzung, Stream-Zuordnung, Byte-Reassembly und Framing, RPC samt Retry-Linie, NACM, Datastore-Übergang und unabhängig beobachteten Effekt. Der typische Fehler verleiht Gewissheit: Das Zertifikat soll Berechtigung beweisen, <ok/> die Anwendung und operational gleich den Geschäftserfolg.

Heng Lus Vorrang für laufenden Code hält die letzte Grenze offen: Dokumente und Aufzeichnungen beschreiben, Ausführung und Beobachtung stellen fest. Seine minimale Anfangsspezifikation lässt den gemeinsamen interoperablen Kern deterministisch, ohne lokale Vertrauens- und Risikourteile zu zentralisieren. Die Analyse der Realitätsebenen erklärt, wie ein sauberer symbolischer Beleg institutionell mehr Macht erhält als die Wirklichkeit, die er nur beschreibt.

Revision 11 zeichnet bessere Spuren. Verlässlich werden sie erst, wenn das Evidenzsystem sie nicht vorzeitig zu einer einzigen grünen Anzeige verschmilzt. Das offizielle Revisionsarchiv bewahrt die hier verwendete Versionsgrenze.