Zusammenfassung

  • Die Annotation beschreibt systembereitgestellte Konfiguration, die der Client nicht im normalen Schreibpfad ändern darf; sie verhindert keine Änderung durch den Server.
  • Ein Ergebnis kann explizit, vom Elternknoten geerbt oder als oberster Standardwert entstanden sein.
  • Ein lokaler Zeitbeleg sollte Abfrage, Snapshot, Instanzpfad, Vererbungsquelle, Serverautorität und den tatsächlichen Grund eines abgewiesenen Edits verbinden.

Unveränderlich für wen?

In vielen Bereichen bedeutet unveränderlich, dass ein Gegenstand über die Zeit gleich bleibt. draft-ietf-netmod-immutable-flag-14 setzt einen anderen Bezugspunkt. Ein wahr annotierter Systemknoten kann vom Client nicht durch einen anderen Wert in einem schreibbaren Datastore ersetzt und nicht aus der vorgesehenen Konfiguration entfernt werden.

Diese Semantik schließt eine Lücke zwischen Modell und Gerät. Ein systembereitgestellter Listeneintrag muss möglicherweise config true bleiben, damit der Client darunter konfigurieren oder YANG-Bedingungen darauf verweisen kann. Zugleich darf der Client den notwendigen Eintrag nicht beseitigen. Ein Hinweis im Beschreibungstext erklärt das einem Menschen, lässt sich aber vor einem Automatisierungslauf schlecht auswerten.

Der Entwurf nennt die Annotation ausdrücklich beschreibend, nicht vorschreibend. Außerdem kann unveränderliche Systemkonfiguration nur vom Server erstellt, aktualisiert und gelöscht werden. Daraus folgt: Die Annotation begrenzt den Client. Sie friert den Serverwert nicht für alle Zeit ein.

Ein wahrer Wert um zwölf Uhr kann nach einem Hardwarewechsel um fünfzehn Uhr einer anderen systembereitgestellten Konfiguration weichen. Beide Beobachtungen können korrekt sein. Falsch wäre nur, die erste als vollständige Geschichte darzustellen.

Ohne Anfrage keine Annotation

Der Client fordert with-immutability für die schreibgeschützten Datastores system, intended oder operational an. Bei anderen Datastores ist der Parameter nach dem Entwurf ungültig. NETCONF entdeckt die Fähigkeit über das Modul ietf-immutable-annotation in der YANG Library; RESTCONF über einen eigenen Capability-Identifier.

Der Nachweis beginnt deshalb vor dem booleschen Wert. Er muss zeigen, welcher Server die Fähigkeit angekündigt hat, welcher Datastore und Teilbaum abgefragt wurden, welcher Principal lesen durfte und wann die Antwort eintraf. Eine später isolierte Anzeige von wahr liefert diese Bedingungen nicht.

Bei Altversionen hat eine fehlende Annotation mehrere Ursachen. Ein alter Client fragt sie nicht ab. Ein neuer Client kann bei einem alten Server einen Fehler erhalten oder erleben, dass der Parameter ignoriert wird. Ein Server kann geerbte oder standardmäßige Werte zudem unterdrücken. Ohne Capability- und Anfragebeleg darf Abwesenheit nicht als Änderbarkeit interpretiert werden.

Hinter dem Ergebnis steht ein Vererbungsweg

Fehlt beim Kind eine explizite Annotation, erbt es den Zustand des Elternknotens. Auf oberster Ebene gilt bei Abwesenheit falsch. Nachkommen können den geerbten Zustand zurücksetzen und damit die eigene Teilstruktur ändern. Die Zahl solcher Zustandswechsel im Datenbaum ist nicht begrenzt.

Die kompakte Übertragung verlangt eine ausführlichere Auditspur. Neben dem gelösten Wert braucht sie die Information, ob dieser explizit, geerbt oder standardmäßig war, welcher Vorfahr ihn bestimmte und wo ein Reset lag. Sonst sehen zwei wahre Knoten gleich aus, obwohl eine Elternänderung sie unterschiedlich beeinflusst.

Bei Listen bezieht sich Metadatenstatus auf Instanzen. Einzelne Einträge derselben Liste können abweichen. Aufgrund der Regeln von RFC 7952 kann das Verhalten einer gesamten Liste aus dem Elternknoten stammen, während ein Eintrag einen anderen Zustand setzt. Hinzufügen, Entfernen, Ändern und Sortieren werden dadurch nicht pauschal gleich behandelt.

Ein Beobachtungsbeleg benötigt Instanzpfad, Knotenart, YANG-Modulrevision, explizite Annotation, gelösten Zustand und Vererbungsquelle. Der boolesche Wert ist das Ergebnis einer Baumauswertung; ihre Eingaben müssen erhalten bleiben.

Derselbe Wert in running ändert die Herkunft nicht

Ein Client darf den systembereitgestellten Wert noch einmal in running konfigurieren und diesen Eintrag später entfernen. Der Wert in intended ändert sich dadurch nicht. Nur die Sichtbarkeit im schreibbaren Datastore wechselt; die Autorität bleibt beim Server.

Ein Änderungsprotokoll ausschließlich für running könnte dem Client die Erstellung des Knotens zuschreiben. Als Aussage über die wirksame Herkunft wäre das falsch. Umgekehrt kann der unveränderliche Systemknoten in running fehlen, solange er nicht explizit wiederholt wurde. Ein running-zentriertes Inventar kann somit die tatsächliche Gerätekonfiguration übersehen.

Zeitliche Herkunft braucht das Clientereignis und das Serverereignis getrennt. Hardwareerkennung, Startprofil oder Produktpolitik sind mögliche Quellen, sofern die lokale Plattform sie belegen kann. Die Standardannotation nennt die Quelle nicht. Ist sie unbekannt, muss der Beleg das offenlassen.

Erst Zugriff, dann Unveränderlichkeit

Bei Einsatz von NACM prüft der Server zuerst die Zugriffsrechte. Ein nicht berechtigter Benutzer erhält access denied, auch wenn der Zielknoten später unveränderlich wäre. Diese Reihenfolge schützt Informationen und bestimmt zugleich die korrekte Fehleranalyse.

Nicht jeder abgewiesene Edit belegt die Immutable-Regel. Authentisierte Identität, Operation, Zielpfad, NACM-Entscheidung, eventuelle Immutable-Prüfung und Error-Tag gehören in den Datensatz. Sonst vermischt eine Erfolgsmetrik Zugriffsfehler, Wertvalidierung und Unveränderlichkeit.

Die Annotation kann außerdem verraten, welche Konfigurationsteile starr sind. Laut Entwurf kann das einem Angreifer Hinweise geben. Deshalb ist sie nur für Clients sichtbar, die den annotierten Knoten lesen dürfen, und die Sicherheitsanforderungen von NETCONF beziehungsweise RESTCONF bleiben bestehen. Ein Analytics-Export darf den ursprünglichen Lesebereich nicht verlieren.

Ein zeitlich begrenzter Herkunftsbeleg

Die gemeinsame Annotation soll klein bleiben. Ein lokaler Beleg ergänzt Server oder logisches Element, Softwareversion, Datastore, YANG-Modulrevision, Capability-Erkennung und Protokoll. Er speichert Teilbaum, Pfad, Konfigurationswert, gelösten Immutable-Zustand, explizite oder geerbte Quelle und Antwortzeit. Eine verfügbare Konfigurationsrevision, Snapshot-ID oder Prüfsumme gehört dazu.

Anschließend folgen nur nachweisbare lokale Tatsachen: Quelle der Systemkonfiguration, Entscheidungsautorität, letzte Serveränderung und Grund. Unbekanntes bleibt unbekannt. Bei einem Edit kommen Rolle, Absicht, NACM-Ergebnis, Immutable-Ergebnis und Fehler hinzu.

Ein Wiedervorlagetermin verhindert, dass „als unveränderlich beobachtet“ zu „für immer zertifiziert“ wird. Ändert der Server später den Wert, entsteht ein neuer Beleg; der alte bleibt bestehen. Erst die Folge zeigt Veränderung und frühere Clientgrenze gleichzeitig.

Diese Geschichte gehört nicht in den Standardboolean. Lokale Identitäten und Workflows würden seine Interoperabilität überladen. Der Standard beschreibt die gemeinsame Grenze, die lokale Beweisarchitektur verbindet sie mit tatsächlich beobachteten Ereignissen.

Einführung als Matrix messen

Zum Recherchezeitpunkt war Revision 14 vom IESG gebilligt und in der RFC-Editor-Warteschlange, zugleich weiterhin ein aktiver Internet-Draft. Die YANG-Prüfung meldete null Fehler und Warnungen. Das ist kein Implementierungsnachweis.

Server mit und ohne Capability treffen auf Clients, die sie anfordern oder nicht. Neue Clients begegnen alten Servern, die den Parameter ablehnen oder ignorieren. Geerbte Zustände erscheinen nicht immer explizit. Eine einzelne Kompatibilitätsquote verdeckt diese Kombinationen.

Messbar ist der vollständige Pfad: Capability gefunden, gültige Anfrage gesendet, Antwort erhalten, Zustand gelöst und ein Edit nach der Zugriffskontrolle richtig klassifiziert. Wo der Pfad endet, liegt die konkrete Upgrade-, Richtlinien- oder Beobachtbarkeitsaufgabe.

Quellen