Zusammenfassung

  • RFC 10016 ergänzt den nur lesbaren Datastore <system> für Konfiguration, die das Gerät selbst bereitstellt. Sein Inhalt bleibt dennoch von Software, Lizenzen und physischen Ressourcen abhängig.
  • Eine zulässige Client-Konfiguration in <running> gewinnt gegen den entsprechenden Systemwert. Wird sie entfernt, kann der Systemwert in <intended> wieder erscheinen; verschwindet eine Ressource, kann Client-Absicht ohne Anwendung bestehen bleiben.
  • Die Norm legt getrennte Transformation, Zusammenführung und sofortige Validierung fest. Sie garantiert weder erfolgreiche Anwendung noch vollständige Änderungsbenachrichtigung oder eine bestimmte Reparatur ungültiger Client-Bäume.

Die geschützte Quelle und das ungeschützte Ergebnis

Ein Sicherheitsparameter liegt in <system>. Direkte NETCONF- und RESTCONF-Änderungen sind verboten. Ein Team bezeichnet ihn deshalb als unveränderlich. Gleichzeitig darf ein Automatisierungs-Client am korrespondierenden Pfad in <running> einen anderen Wert setzen. In der Zusammenführung gewinnt der Client.

Die Quelle blieb unberührt; ihre Wirkung wurde verdrängt. RFC 10016 beschreibt ausdrücklich, dass Fehlkonfiguration oder ein Angreifer einen sensiblen Systemknoten beschatten und damit Sicherheitsrichtlinien umgehen oder Verfügbarkeit gefährden kann. „Nur lesbar“ ist eine Aussage über den direkten Zugriff, nicht über die Autorität im Endergebnis.

Die Architektur unterscheidet vier Aussagen. <system> enthält vom Gerät bereitgestellte Konfiguration. <running> enthält explizite Client-Eingaben. <intended> ist das transformierte, zusammengeführte und validierte Ziel. <operational> zeigt die tatsächlich verwendete Konfiguration und den Zustand. Keine dieser Ebenen darf stellvertretend für alle anderen attestiert werden.

Der System-Datastore bewegt sich ohne Client-Schreibzugriff

Das Gerät kann dauerhaft vorhandene Knoten sowie bedingte Knoten erzeugen. Karte, Lizenz oder Funktion können deren Existenz bestimmen. Ein Software-Upgrade kann Werte verändern. Der Client darf <system> nicht direkt bearbeiten, aber das System selbst erzeugt und entfernt dessen Inhalt.

Der Datastore persistiert nicht über Neustarts. Er wird aus dem gestarteten System neu gebildet. <factory-default> aus RFC 8808 erfüllt einen anderen Vertrag: sein Inhalt muss Neustarts überdauern und kann bei einem Werksreset schreibbare Datastores initialisieren. Wer beide als Herstellerstandard zusammenfasst, verliert die Unterscheidung zwischen Regeneration und Rücksetzung.

Auch die Leseberechtigung ist sensibel. Hardwarekennungen, Sicherheitsregeln und kritische Ressourcen können sichtbar werden. RFC 10016 verlangt Zugriffskontrolle für schützenswerte Teilbäume und empfiehlt Auditierung. Das NACM aus RFC 8341 liefert das Modell; wirksam wird es erst durch korrekt vergebene lokale Identitäten und Regeln.

Eine gelöschte Überschreibung aktiviert den Untergrund

Solange ein zulässiger Knoten in <running> existiert, hat er Vorrang, selbst wenn der Systemwert später geändert wird. Wird die Client-Überschreibung gelöscht, erscheint der systeminitialisierte Wert wieder in <intended> und kann nach erfolgreicher Anwendung wirksam werden.

Damit ist Löschen keine neutrale Abwesenheit. Es gibt einer anderen Quelle die Priorität zurück. Der Change-Request muss nicht nur den zu entfernenden Wert zeigen, sondern den aktuellen Systemwert darunter. Sonst genehmigt die prüfende Person die Freigabe eines Inhalts, den sie nicht gesehen hat.

Bei einer entfernten Linecard entsteht die zweite Asymmetrie. Der bedingte Knoten verschwindet aus <system>, während vorprovisionierte Client-Werte in <running> und <intended> bleiben können. Ohne Ressource erscheinen sie nicht in <operational>. Kommt die Karte zurück, kann die ruhende Absicht erneut anwendbar werden.

Für beide Fälle braucht es unterschiedliche Tests: Rückkehr des Systemwerts nach Override-Löschung, klare Kennzeichnung nicht angewandter Absicht nach Ressourcenverlust und erneute Prüfung vor Ressourcenwiederkehr.

Erst getrennt transformieren, dann zusammenführen

Templates, inaktive Konfiguration und vergleichbare Transformationen müssen in <system> und <running> jeweils eigenständig verarbeitet werden. Danach erfolgt die Zusammenführung; erlaubte passende Knoten aus <running> gewinnen. Bei jeder Änderung in <system> muss der Server <intended> sofort aktualisieren und validieren.

RFC 10016 sagt zugleich, <running> solle nach Systemänderungen gültig bleiben, lässt den Mechanismus aber offen. Ein Upgrade kann ein Referenzziel entfernen, eine Lizenz kann Constraints verändern. Die Norm bestimmt den Validierungszeitpunkt, nicht die Entscheidung zwischen Stopp, Reparatur, Isolation oder Rollback.

RFC 8342 begrenzt die Aussagekraft von <intended>: Es ist die Konfiguration, deren Anwendung das System versucht. Fehlende Ressourcen und Verzögerungen können verhindern, dass sie in <operational> erscheint. Ein valider Baum ist noch kein Betriebsnachweis.

Benachrichtigung ist kein Vollständigkeitsbeweis

Systemänderungen können über Abonnements nach RFC 8639 und YANG-Push nach RFC 8641 übertragen werden. On-change-Unterstützung kann jedoch je Objekt und Implementierung fehlen. Der Empfänger muss Abdeckung, Sequenz und Resynchronisation kennen. Ein stiller Kanal kann stabil, unvollständig oder defekt sein.

Alte NMDA-Clients funktionieren weiterhin mit den bisherigen Datastores. Um die neue Quelle, die Priorität und die Herkunftsmetadaten vollständig zu nutzen, müssen Client-Anwendungen aktualisiert werden. Kompatibilität beweist also nicht semantische Vollständigkeit.

Heng Lus Prinzip der Primarität laufenden Codes ordnet die Beweise: Die Norm definiert Regeln, der Client formuliert Absicht, das laufende Gerät erzeugt operative Realität. Sein Modell aus minimaler Anfangsspezifikation und lokalisierter Zukunftsentscheidung hält die Merge-Regel gemeinsam, ohne lokalen Betreibern Override-, Rollout- und Rücknahmeverantwortung abzunehmen.