Zusammenfassung

  • RFC 10016 ergänzt NMDA um den schreibgeschützten <system>-Datastore für vom System gelieferte, durch Clients nicht löschbare Konfiguration. Clients dürfen solche Knoten dennoch referenzieren, zulässige Werte in <running> überschreiben oder konfigurierbare Nachfahren unter systemseitig erzeugten Einträgen anlegen.
  • origin=system bezeichnet die Quelle, nicht menschliche Freigabe, Dauerhaftigkeit oder erfolgreiche Anwendung. Wird ein Override entfernt, kann der verdeckte Systemwert in <intended> zurückkehren; auch Hardware-, Lizenz-, Funktions- oder Softwarewechsel verändern möglicherweise den Bestand.

Der Change sah harmlos aus: Ein expliziter Wert sollte aus <running> gelöscht werden. Im Review galt das als Rückkehr zu „nicht konfiguriert“. Auf dem Gerät entstand jedoch keine Lücke. Nach dem Löschen gewann der bereits vorhandene Systemwert den Merge und erschien wieder in <intended>.

Die Benutzeroberfläche hatte den Datenbankvorgang korrekt benannt und seine Wirkung trotzdem verschwiegen. RFC 10016 macht genau diese Wirkung sichtbar, indem er NMDA einen konventionellen Datastore für systemseitig bereitgestellte Konfiguration hinzufügt. Für NETCONF- und RESTCONF-Clients ist <system> nur lesbar. Sein Inhalt bleibt gleichwohl Eingabe für die wirksame Konfiguration.

Der Governance-Fehler liegt darin, eine Zugriffsregel in eine Zeitgarantie umzudeuten. Schreibschutz sagt, wer an dieser Stelle nicht schreiben darf. Er sagt nicht, ob der Server beim nächsten Boot denselben Wert erzeugt, ob ein Override gewinnt, wer die Folge akzeptiert hat oder ob der Wert in <operational> angekommen ist.

Eine eigene Adresse für die Systemquelle

Die NMDA aus RFC 8342 trennt bereits beabsichtigte Konfiguration von tatsächlich verwendeter Konfiguration und tatsächlichem Zustand. Sie kennt konventionelle, dynamische, gelernte, systemseitige und Default-Herkünfte. RFC 10016 präzisiert: Alles, was in <system> vorhanden ist, zählt als Systemkonfiguration, unabhängig davon, ob es gerade referenziert oder angewendet wird.

Clients können diese Konfiguration nicht löschen. Daten, die der Server zwar liefert, die der Client aber entfernen darf, fallen nicht unter die Definition. Ein konformer Server implementiert die Identity ietf-system-datastore auf Basis der in RFC 7950 festgelegten YANG-Modelle. Über die YANG-Library-Informationen aus RFC 8525 kann ein Client die Unterstützung erkennen.

Die Knoten besitzen allerdings unterschiedliche Lebenszyklen. Always-present Systemkonfiguration entsteht beim Einschalten, ohne von einer bestimmten physischen Ressource abzuhängen; als Beispiel nennt der RFC ein Loopback-Interface. Conditionally present Konfiguration hängt von Karte, Ressource, Lizenz oder Feature ab. Fällt die Bedingung weg, kann auch der Systemknoten verschwinden.

<system> selbst ist über einen Neustart hinweg nicht persistent. Der Server rekonstruiert den Inhalt aus den dann geltenden Bedingungen. Ein Abzug vor dem Reboot belegt deshalb nicht die Eingaben danach. Auch ein Backup von <running> enthält nicht alle Faktoren, aus denen das nächste <intended> gebildet wird.

Geschützte Quelle, veränderlicher Sieger

Ein Client darf aus <running> auf Systemknoten verweisen. Wo der Server ein Überschreiben gestattet, verdrängt ein entsprechendes Blatt in <running> den Wert aus <system>. Möglich sind außerdem konfigurierbare Nachfahren unter einem Listeneintrag, dessen Existenz das System bestimmt.

Die Merge-Regel ist eindeutig: Der passende <running>-Knoten hat beim Aufbau von <intended> Vorrang vor <system>. Müssen Vorlagen expandiert oder inaktive Konfigurationen entfernt werden, wird jeder Datastore vor dem Merge für sich transformiert. Zwei Rohansichten nebeneinander beweisen daher nicht den späteren Gewinner.

Das System liefert A, der Operator schreibt B nach <running>, und B setzt sich durch. Löscht er B, löscht er A nicht — dazu hat er in <system> kein Recht. A kehrt nach <intended> zurück und kann angewendet werden. Ein Löschvorgang wählt damit einen Fallback. Er ist nicht automatisch eine Entscheidung für „kein Wert“.

Die Gegenrichtung ist ebenso relevant. Nach dem Ausbau einer Karte oder dem Ende einer Lizenz verschwindet ein bedingter Systemknoten. Abhängige Konfiguration kann in <running> und <intended> verbleiben, in <operational> aber mangels Ressource fehlen. Die Absicht bleibt als Datensatz bestehen, während ihr materielles Ziel nicht mehr vorhanden ist.

Herkunft ist keine Einwilligung

RFC 7952 definiert den Metadatenmechanismus, über den auch Origin-Annotationen transportiert werden. RFC 10016 stellt klar: Konfiguration aus <system> trägt system als Origin, sofern sie nicht in <running> explizit konfiguriert oder überschrieben wurde. Für Inhalte aus <running> gelten die Origin-Regeln der NMDA.

Die Annotation beantwortet „Welche Quelle stellte diesen Knoten bereit?“. Sie benennt nicht den Menschen, der die Wirkung billigte. Plattform-Image, Lizenzdienst, Ressourcenverwaltung oder lokaler Prozess können Werte ohne aktuelle menschliche Entscheidung erzeugen. Umgekehrt kann hinter einem Wert in <running> ein autonomer Controller statt eines einzelnen Operators stehen.

Wer systemseitige Herkunft mit Vertrauen gleichsetzt, macht eine Produktwahl zur lokalen Richtlinie. Wer die Herkunft aus <running> als menschliche Absicht liest, macht Automation zur Zustimmung. Provenienz ist für Verantwortlichkeit nötig, muss aber mit Änderungsbefugnis, Policy-Prüfung und Risikoeigentümer verbunden werden.

Validierte Absicht ist noch keine Anwendung

Ändert sich <system>, muss der Server nach RFC 10016 <intended> sofort aktualisieren und validieren. Außerdem soll <running> nach Systemänderungen ein gültiger Konfigurationsbaum bleiben; wie das erreicht wird, lässt das Dokument offen. Beides sind Zusagen über Datenverarbeitung, nicht über die erfolgreiche Programmierung von Hardware.

<operational> wird durch RFC 10016 bewusst nicht verändert. Unter RFC 8342 können fehlende Ressourcen, Verzögerung, Fehler und Restzustände Absicht und Realität auseinanderhalten. Die vollständige Kette transformiert <system> und <running> getrennt, führt sie in <intended> zusammen und überträgt das Ergebnis nur unter passenden Bedingungen nach <operational>. Jede Kante braucht ihren eigenen Nachweis.

Systemänderungen lassen sich über YANG-Subscriptions und Datastore-Update-Mechanismen aus RFC 8639 und RFC 8641 melden. Ein versandtes Ereignis belegt die Publikation im abgedeckten Bereich. Es belegt nicht, dass jeder Empfänger es verarbeitet, seine Policy neu berechnet und den Betriebsbaum geprüft hat.

Ebenso ist <system> nicht mit <factory-default> gleichzusetzen. RFC 8808 definiert einen Datastore für Werkseinstellungen und eine Factory-Reset-Operation. <system> beschreibt, was das aktuelle System unter aktuellen Bedingungen liefert. Einzelne gleiche Werte ändern die unterschiedlichen Rollen nicht.

Der Herkunfts- und Vorrangbeleg

Ein Herkunfts- und Vorrangbeleg würde wirksame Einstellungen revisionsfähig machen. Er erfasst für jeden wesentlichen Knoten Pfad, Fingerprint des Werts, Origin und Anwesenheitsbedingung. Zur Bedingung gehören Hardware-, Lizenz-, Feature-, Boot- und Software-Epoche, damit ein Systemwert nie als zeitlose Konstante erscheint.

Danach folgen Veränderbarkeit und Merge: Darf überschrieben werden? Welcher <running>-Knoten referenziert oder verdeckt die Quelle? Welche Nachfahren hat ein Client ergänzt? Welche Transformationen liefen je Datastore, und welcher Wert gewann in <intended>? Vor dem Löschen eines Overrides zeigt der Beleg den Wert, der wieder hervortreten wird.

Der Aktivierungsteil vergleicht <intended> mit <operational>. Er hält Zeitpunkt, Ressourcenanwesenheit, Verzögerung, Fehler, Restzustand und die konkrete Beobachtung fest, auf die sich „wirksam“ stützt. Eine formal gültige Referenz kann auf eine inaktive Ressource zeigen; ein gültiger Absichtsbaum kann nicht vorhandene Hardware beschreiben.

Im Autoritätsteil stehen Systemlieferant, Konfigurationsclient, betrieblicher Freigeber und Risikoeigentümer getrennt. Softwareupgrade, Lizenzwechsel, Karteneinbau oder Policy-Commit werden mit der Entscheidung verbunden, die das Ergebnis akzeptierte. Vertrauliche Einzelheiten können geschützt bleiben; Hashes und begrenzte Referenzen erhalten die Beweiskette.

Dieser Beleg ist ein redaktioneller Governance-Vorschlag von Daniel Kade, keine neue Vorgabe aus RFC 10016. Er hält sichtbare Quelle, Merge-Sieger, genehmigte Entscheidung und angewendetes Ergebnis als vier unterschiedliche Tatsachen fest.

Sicherheit beginnt beim Leserecht

Schreibschutz macht Daten nicht harmlos. RFC 10016 warnt, dass <system> Hardwarekennungen, Sicherheitsrichtlinien und kritische Ressourcen enthalten kann. Der Zugriff auf sensible Knoten und Teilbäume muss beschränkt, Leseversuche sollten protokolliert werden. RFC 8341 liefert mit NACM das Zugriffskontrollmodell für NETCONF- und RESTCONF-Benutzer.

Overrides bilden eine eigene Angriffsfläche. Ein Angreifer oder fehlerhafter Client kann in <running> ein Blatt schreiben, das einen sicherheitsrelevanten Systemwert verdeckt. Policy-Umgehung oder Ausfall entstehen, obwohl <system> unverändert bleibt. Eine Überwachung nur seiner Schreibzugriffe bewacht also gerade den Weg, der Clients ohnehin versperrt ist.

RFC 10016 macht Systemkonfiguration auf standardisierte Weise sichtbar und auswertbar. Er macht die Auswahl der Maschine weder zur Operatorabsicht noch dauerhaft und bescheinigt keine Anwendung. Sichtbarkeit beginnt Kontrolle; erst Vorrang und Betriebszustand schließen den Nachweis.

Quellen