Zusammenfassung

  • Revision 18 des NETCONF-Entwurfs lässt einen Publisher das YANG-Push-Intervall anhand gegenseitig ausschließender XPath-Kriterien wählen; Auswertungs- und Sendeintervall sind dabei getrennte Takte.
  • XPath 1.0 verwendet IEEE-754-Zahlen mit doppelter Genauigkeit. Bestimmte int64-, uint64- und decimal64-Werte sind nicht exakt darstellbar, obwohl sie im YANG-Datenspeicher exakt wirken.
  • Ein adaptive-period-update darf für betroffene Online-Empfänger weder verworfen noch ausgefiltert werden, wird aber ausdrücklich nicht in Replay-Puffern gespeichert.
  • Nach einer Wiederverbindung kann der Inhalt vorhanden sein, während die numerische Entscheidung und die Live-Meldung hinter dem Intervallwechsel fehlen.
  • Der Entwurf befindet sich als Experimental-Dokument in der RFC-Editor-Queue. Er ist noch kein RFC, und der gemeldete Prototyp ist keine unabhängig geprüfte Interoperabilitätsstudie.

Eine Schwelle zwischen zwei Zahlensystemen

Ein Betreiber schreibt eine Regel, die bei einem großen Zählerwert von zehn Minuten auf zehn Sekunden umschaltet. In YANG ist der Zähler ein uint64. In XPath 1.0 gelangt der Vergleich jedoch in ein Zahlensystem, das nicht jede 64-Bit-Ganzzahl einzeln unterscheiden kann. Zwei benachbarte Werte können jenseits der exakten Reichweite auf dieselbe Gleitkommazahl fallen.

Das ist kein exotischer Parserfehler, sondern eine dokumentierte Eigenschaft der verwendeten Sprache. Revision 18 warnt ausdrücklich vor Genauigkeitsproblemen bei int64, uint64 und decimal64. Sie empfiehlt kleine Knotenmengen, passende Datentypen und konstante numerische Schwellen. Die Warnung verschiebt die Verantwortung nicht vollständig zum Nutzer; sie zeigt vielmehr, welche Aussage ein akzeptierter Ausdruck nicht leisten kann.

Wenn ein Server eval-expression annimmt, bestätigt er, dass er diese Syntax in seinem Funktionsumfang verarbeiten kann. Er bestätigt nicht, dass der Grenzwert dieselbe mathematische Bedeutung besitzt wie im Überwachungsplan des Betreibers. Dafür braucht es Testvektoren unmittelbar unter, auf und über der Schwelle sowie einen Nachweis des tatsächlich ausgewerteten Werts.

Nichtboolesche XPath-Ergebnisse werden über boolean() umgewandelt. Wird der Zielknoten gelöscht, gilt die Bedingung als falsch. Auch das sind semantische Entscheidungen, keine bloße Verkabelung. Ein fehlender Knoten, eine leere Knotenmenge und eine Null im Wertebereich dürfen in einer Untersuchung nicht stillschweigend gleichgesetzt werden.

Der Ausdruck steuert nicht den Inhalt

Die adaptive Bedingung bestimmt, welches konfigurierte Intervall gilt. Sie verändert nicht den Inhaltsfilter und erzeugt selbst keine Datenmeldung. Damit bleiben zwei Verträge getrennt: Der Filter sagt, welche Knoten übertragen werden; die Bedingung sagt, mit welcher Periode der Publisher sie sendet.

Das verhindert eine bequeme, aber falsche Rückrechnung. Aus einem plötzlich dichten Datenstrom lässt sich nicht ableiten, welche einzelne Inhaltsmeldung die Umschaltung ausgelöst hat. Der beobachtete Wert kann aus einem anderen Auswertungszeitpunkt stammen als die erste Meldung im neuen Takt.

eval-interval legt fest, wie oft der Server die Bedingung prüft. Fehlt der Wert, wählt der Server das kleinste unterstützte Intervall. Diese Wahl ist implementierungsspezifisch und kann sich laut Entwurf bei veränderter CPU- oder Speicherauslastung dynamisch verschieben. Die vermeintlich konstante Schwellenüberwachung trägt also einen zweiten variablen Takt in sich.

Mehrere Kriterien derselben adaptiven Konfiguration müssen sich gegenseitig ausschließen. Der Publisher kann Überschneidungen als multi-xpath-criteria-conflict zurückweisen. Er kann auch ein nicht tragbares Auswertungsintervall oder eine nicht unterstützte XPath-Auswertung ablehnen. Diese Fehlernamen sind wertvolle Belege darüber, was der Server nicht versprochen hat. Eine erfolgreiche Einrichtung bleibt dagegen nur ein Zulassungsbeleg, kein Ergebnisbeleg.

Vier Zeitpunkte statt eines Alarms

Der Messwert ändert sich zu einem Zeitpunkt. Die nächste XPath-Auswertung sieht ihn zu einem zweiten. Der Publisher schaltet die Periode zu einem dritten. Das nächste Inhaltsupdate erscheint an einer nach period und anchor-time berechneten Grenze zu einem vierten.

Diese Reihenfolge muss nicht lange dauern, aber sie ist logisch real. period-update-time kann den Umschaltzeitpunkt angeben; es sagt nicht, wann der physische Zustand entstand. Ein Incident-Bericht, der alle vier Ereignisse als „Schwelle um 10:02 überschritten“ zusammenfasst, behauptet mehr, als der Vertrag belegt.

Ein kürzeres Intervall schafft danach mehr Beobachtungspunkte. Es holt das unbeobachtete Stück vor der Auswertung nicht zurück. Ebenso wenig beweist es, dass jeder erzeugte Datensatz den Client erreicht oder dessen Puffer überlebt hat.

Eine unübersehbare Live-Meldung ohne Replay-Spur

adaptive-period-update nennt die Abonnement-ID und die neue Periode. Optional trägt die Meldung Umschaltzeit, erfüllende Daten und den Inhaltsfilter. Für betroffene, verbundene Empfänger gilt ein starkes Zustellgebot: Die Meldung darf nicht verworfen oder ausgefiltert werden.

Gleichzeitig darf sie nicht in Replay-Puffern gespeichert werden. Diese Grenze ist architektonisch nachvollziehbar. Eine Zustandsänderung des Abonnements ist Live-Steuerkontext und nicht gewöhnlicher abonnierter Inhalt. Für die spätere Beweisführung entsteht dennoch ein Loch.

Ein Ersatz-Collector kann nach dem Wiederanschluss Daten aus der Zeit vor und nach dem Wechsel abrufen, ohne die dazwischenliegende Umschaltmeldung zu erhalten. Er erkennt vielleicht eine höhere Dichte. Er erfährt daraus weder den exakten Ausdruck noch dessen Namespace-Kontext, Policy-Generation, Eingabewert oder ursprünglichen Empfänger.

Wer diese Kette nach Ende der Sitzung erklären muss, braucht ein separates, manipulationsresistentes Entscheidungsjournal. Es sollte kompakt bleiben: Hash des kanonischen Ausdrucks, Datentyp, Auswertungsrhythmus, Schwellen-Testvektor, Umschaltmeldung und Empfangsbestätigung. Das ist eine betriebliche Evidenzanforderung von BTW, keine nachträgliche Forderung an den Entwurf.

Was das Experiment erst noch zeigen muss

Der Entwurf fordert Erfahrungen zu Client-Puffern, Rechenaufwand, plötzlichen Datenstößen, Ressourcenverbrauch, Skalierbarkeit und eingespartem Telemetrievolumen. Er nennt viele Periodenwechsel in kurzer Zeit als wichtiges Zeichen für Oszillation oder instabile Ausdrücke.

Eine solche Folge ist diagnostisch offen. Der Eingangswert kann rauschen. Der Ausdruck kann ohne Hysterese gebaut sein. Die numerische Darstellung kann eine Grenzsituation verschärfen. Der Server kann seine Auswertungsfrequenz unter Last ändern. Oder das beobachtete System ist tatsächlich instabil. Die Umschaltmeldungen machen das Muster sichtbar; sie entscheiden nicht zwischen den Ursachen.

Der Implementation-Status berichtet einen von einem Mitwirkenden gelieferten Prototyp für Campus-WLAN-Telemetrie. Der Abschnitt erklärt selbst, dass solche Angaben keine IETF-Billigung darstellen und nicht unabhängig verifiziert wurden. Das ist ein Hinweis auf gemeldeten laufenden Code, nicht auf vollständige XPath-Abdeckung, Herstellerkompatibilität oder belastbare Wiederherstellung.

Datatracker führt Revision 18 in der RFC-Editor-Queue mit dem Zielstatus Experimental. Das Archivdokument vom 22. April 2026 bleibt ein Internet-Draft ohne RFC-Nummer. Der Verfahrensfortschritt ist überprüfbar; ein erfolgreiches Betriebsergebnis wäre eine andere Art von Beleg.