Zusammenfassung

  • RFC 6643 übersetzt SMIv2-MIB-Module für einen lesenden NETCONF-Zugriff nach YANG. Schreibbare Ausgangsobjekte werden dabei nicht automatisch zu Konfigurationsknoten.
  • Die Bedeutung einer Änderung hängt auch davon ab, wo ihre Beständigkeit festgelegt ist: beim SNMP-Objekt beziehungsweise seiner Zeile oder beim NETCONF-Konfigurationsspeicher.
  • Dokumentierte Abweichungen können ausgewählte, semantisch passende Knoten konfigurierbar machen. Die Zahl lesbarer Objekte belegt deshalb weder eine vollständige Schreibmigration noch die Entbehrlichkeit des alten Zugangs.

Die Stilllegung ist die eigentliche Entscheidung

Ob ein neues Verwaltungssystem Daten anzeigen kann, lässt sich im Projekttermin vorführen. Ob das alte System abgeschaltet werden darf, ist eine andere Frage. Für sie muss bekannt sein, welche Arbeiten noch vom bisherigen Zugang abhängen, unter welchen Bedingungen sie stattfinden und was nach einer Änderung erhalten bleiben soll.

Man stelle sich eine Abnahme vor, bei der sämtliche vereinbarten Objekte über den neuen Controller gelesen werden. Die Daten stimmen mit der bisherigen Ansicht überein. Trotzdem benötigt eine seltene Konfigurationsänderung noch das alte Werkzeug. Die Lesemigration kann in diesem Beispiel erfolgreich sein, während die Stilllegung des alten Schreibwegs noch nicht begründet ist.

Das ist ein hypothetisches Abnahmeproblem, kein Bericht über einen bestimmten Betreiber. Es ergibt sich aus dem ausdrücklich begrenzten Zweck von RFC 6643. Das im Juli 2012 veröffentlichte Dokument beschreibt eine automatische Übersetzung von SMIv2-Modulen nach YANG für einen ausschließlich lesenden Zugriff durch NETCONF.

Die Begrenzung schützt einen sinnvollen Anwendungsfall. Wer vorhandene Informationen in einer gemeinsamen Oberfläche nutzen möchte, muss nicht zugleich jede bisherige Verwaltungsoperation ersetzen. Dafür darf die Oberfläche auch nicht als Nachweis verkauft werden, dass alle Aufgaben bereits umgezogen sind. Der Vertragsgegenstand entscheidet darüber, was als vollständige Lieferung gelten kann.

Ein bewahrtes Zugriffsmerkmal ist noch keine Operation

SMIv2 hält mit MAX-ACCESS fest, welche Zugriffsart ein Objekt beschreibt. Ein Eintrag kann unter anderem als read-write oder read-create definiert sein. In der Übersetzung geht dieses Merkmal nicht einfach verloren: Es erscheint als Erweiterungsangabe smiv2:max-access wieder.

Gleichzeitig verlangt RFC 6643 für den erzeugten obersten Container der verwalteten Objekte config false. Die alte Schreibdeklaration und die neue Einordnung als Zustandsdaten stehen also nebeneinander. Das ist kein Widerspruch, den ein nachgelagertes Werkzeug durch ein pauschales Umschalten beseitigen müsste. Die Angaben beantworten unterschiedliche Fragen.

Eine davon lautet, wie das Ausgangsobjekt definiert war. Die andere betrifft den Konfigurationscharakter des Zielmodells. Ein Metadatum über den Ursprung überschreibt nicht die Regeln der neuen Konfigurationsschnittstelle. Dass ein Mensch im Modell eine Schreibmöglichkeit wiedererkennt, macht diese Möglichkeit noch nicht für den neuen Client ausführbar.

Auch andere Informationen bleiben erhalten. Beschreibungen, Referenzen, Typen und Objektkennungen werden nach festgelegten Regeln abgebildet. Die Übersetzung ist daher weder eine vollständige Auslöschung der alten Bedeutung noch deren lückenlose Umsetzung in neue Operationen. Manche Information bleibt Wissen über einen Gegenstand, statt selbst dessen Steuerung zu übernehmen.

Für die Abnahme folgt daraus eine sprachliche Pflicht. „Zugriffsdeklaration erhalten“ ist ein anderer Befund als „Änderungsaufgabe über den neuen Pfad ausführbar“. Werden beide als „Objekt unterstützt“ verbucht, verliert die Organisation eine Unterscheidung, die sie spätestens beim nächsten Eingriff wieder benötigt.

Die Speicherzusage muss mitwandern

Der entscheidende Einwand gegen eine automatische Schreibmigration steht in Abschnitt 11. Bei SNMP kann die Beständigkeit einer Änderung in der Objektbeschreibung, in Eigenschaften der betreffenden konzeptionellen Zeile oder über StorageType festgelegt sein. Bei NETCONF sind dafür die Eigenschaften des Konfigurationsspeichers maßgeblich.

Ein Konverter kann eine Syntax erkennen und einen Typ zuordnen. Daraus folgt noch nicht, welcher Speichervertrag am Ziel dem bisherigen Verhalten entspricht. Für diese Entscheidung reicht es insbesondere nicht, dass ein gelesener Wert vor und nach der Umstellung gleich aussieht.

RFC 2579 zeigt mit StorageType, wie unterschiedlich diese Verträge sein können. Eine flüchtige Zeile geht beim Neustart verloren. Andere Klassen sind durch beständigen Speicher abgesichert. Dennoch darf eine als permanent bezeichnete Zeile verändert, aber nicht gelöscht werden; eine readOnly-Zeile darf weder verändert noch gelöscht werden. Auch die Änderung des Speichermerkmals selbst unterliegt Grenzen.

„Permanent“ bedeutet hier also nicht, dass jede Spalte unveränderlich wäre. Ebenso wenig verleiht beständiger Speicher einem Benutzer die Berechtigung zum Schreiben. Wer diese Eigenschaften zu einem einzigen Haltbarkeitsmerkmal zusammenzieht, vereinfacht nicht nur die Darstellung. Er ändert den Gegenstand, über den später entschieden wird.

Auf der Zielseite liefert RFC 6241 eine andere Gliederung. Im Basismodell ist die laufende Konfiguration, running, vorhanden. Weitere Konfigurationsspeicher hängen von angekündigten Fähigkeiten ab. Die Unterstützung direkter Änderungen an running wird durch eine eigene Fähigkeit beschrieben.

Bei einem Gerät mit gesondertem Startkonfigurationsspeicher werden Änderungen an der laufenden Konfiguration nicht automatisch dorthin übertragen. Eine ausdrückliche Kopie von running nach startup aktualisiert die Konfiguration für den Start. Schon deshalb wäre auch die umgekehrte Pauschalbehauptung falsch, NETCONF mache alle Änderungen automatisch dauerhaft.

Diese Regeln sind keine Anleitung, im Produktivbetrieb einen Neustart oder eine Änderung auszulösen. Sie bestimmen, welche Informationen eine verantwortbare Migrationsentscheidung braucht. Ein Projekt muss den Zielbestand, die unterstützte Operation und die daraus folgende Speicherzusage benennen können. Ein Protokollname übernimmt diese Arbeit nicht.

Hinzu kommt eine kategoriale Grenze: Die Konfigurationsoperationen aus RFC 6241 sind keine allgemeine Schreibschnittstelle für beliebige Betriebszustände. Ein beobachteter Wert muss nicht die Art von Eingabe sein, die sich als Konfiguration wieder einspielen lässt. Bevor ein Projekt sein Schreiben überträgt, muss es den Charakter dieses Schreibens verstehen.

Die Ausnahme bleibt eine Auswahl

RFC 6643 versperrt nicht jeden Weg zur Konfiguration. Stimmen die einschlägigen Persistenzsemantiken überein, können Implementierungen ausgewählte erzeugte Knoten als Konfigurationsdaten anbieten. Ein gesondertes YANG-Modul soll die entsprechenden Abweichungen von der generierten Basis dokumentieren.

Für den Wechsel von config false zu true ohne weitere semantische Änderungen sieht die Übersetzungsspezifikation eine begrenzte Vereinbarkeitsregel vor. Sie liefert aber keinen Beweis dafür, dass sämtliche Ausgangsobjekte diese Voraussetzung erfüllen. Die Auswahl ist Teil der Implementierungsarbeit, nicht ein unvermeidliches Nebenprodukt der Konvertierung.

Das Beispiel einer RMON2-Kontrolltabelle benennt relevante Ebenen und einzelne Knoten und zeigt die Ankündigung von Modulen, Revisionen und Abweichungen. Es weist ausdrücklich darauf hin, dass eine Abweichung den Zielknoten betrifft und nicht als pauschale Änderung nach unten wirkt. Für den Client zählt die genaue wirksame Struktur.

Davon zu unterscheiden ist die gewöhnliche Vererbung des config-Werts bei einer fehlenden Angabe. Die spätere YANG-1.1-Spezifikation RFC 7950 beschreibt diese Vorgaben, verbietet Konfigurationsknoten unter einem Zustandsknoten und verlangt ein weiterhin gültiges Modell nach Anwendung der angekündigten Abweichungen. Eine einzelne gefundene Zeile ersetzt daher keine Betrachtung des wirksamen Schemas.

Gerade die begrenzte Ausnahme ermöglicht einen ehrlichen Teilerfolg. Ein Betreiber kann bestimmte Aufgaben mit nachvollziehbarer Semantik übertragen und andere bewusst auf dem bisherigen Weg belassen. Dazu muss er weder das gesamte Modell für beschreibbar erklären noch einen nützlichen lesenden Zugang als gescheitert verwerfen.

Wartung braucht mehr als die letzte Datei

Die Herkunft des Modells ist selbst eine betriebliche Abhängigkeit. RFC 6643 empfiehlt, notwendige Änderungen am ursprünglichen SMIv2 vorzunehmen, dessen Revisionsangaben anzupassen und die Übersetzung erneut auszuführen. Direktes Bearbeiten des erzeugten YANG soll vermieden werden; getrennte Erweiterungen und Abweichungen bleiben möglich.

Damit lassen sich Basis und Ausnahme auseinanderhalten. Wird stattdessen die generierte Datei stillschweigend zur einzigen gepflegten Wahrheit, kann die nächste Erzeugung eine lokale Annahme überschreiben. Bleibt nur die Quelle erhalten, ohne die tatsächlich ausgelieferten Abweichungen, fehlt wiederum ein Teil des wirksamen Vertrags.

Das Problem kann lange unsichtbar bleiben. Solange dieselben Menschen dieselben Werkzeuge bedienen, ergänzt ihr Gedächtnis die fehlenden Unterlagen. Beim Wechsel der Zuständigkeit wird daraus eine private Wissensabhängigkeit: Die Dateien sind übergeben, ihre entscheidenden Gründe aber nicht.

Eine eng begrenzte Korrektur in der öffentlichen Dokumentation verdeutlicht, wie genau Änderungsgründe festgehalten werden sollten. Das im August 2016 bestätigte technische Erratum 4786 korrigiert eine Regel für Benachrichtigungen. Für ein aktuelles Objekt, das bereits Indexobjekt ist, soll nicht zusätzlich ein zweiter entsprechender Blattknoten entstehen.

Die Korrektur betrifft somit die erzeugte Struktur. Sie schafft weder Schreibrechte noch neue Speicherzusagen. Wer sie übernimmt, sollte den einschlägigen Erzeugungsfall prüfen, statt daraus eine umfassende Betriebsfreigabe abzuleiten. Der Dokumenteintrag beim RFC Editor belegt die Veröffentlichungsgeschichte, aber keine bestimmte Geräteimplementierung.

Der Restbetrieb gehört in die Rechnung

Für einen Betreiber kann ein lesender Übergang der wirtschaftlich passende Endzustand sein. Nicht jede seltene Änderung muss über dieselbe Plattform laufen wie die tägliche Beobachtung. Ein bewusster Zweibetrieb ist etwas anderes als eine unbemerkte Restabhängigkeit.

Kosten entstehen dort, wo diese Unterscheidung verloren geht. Die alte Schreibmöglichkeit benötigt weiterhin einen erreichbaren Zugang, gepflegte Berechtigungen, anwendbares Wissen und eine verantwortliche Stelle. Diese Aufgaben werden nicht kleiner, nur weil sie in einem Bericht über Abfragen nicht vorkommen.

Ein Projekt kann deshalb eine echte Verbesserung liefern und trotzdem keine vollständige Ablösung rechtfertigen. Der Fehler läge nicht im begrenzten Nutzen, sondern darin, mit diesem Nutzen die Finanzierung einer weiterhin benötigten Aufgabe zu beenden. Das ist eine organisatorische Schlussfolgerung aus der Schnittstellengrenze, kein gemessener Schaden bei einem genannten Unternehmen.

Auch die neue Beobachtung hat einen eigenen Schutzbedarf. RFC 6643 verweist auf die Sicherheitsbetrachtungen der ursprünglichen MIBs und auf Zugriffskontrollen. Nur lesen zu können, macht Managementinformationen nicht automatisch unbedenklich. Der Schutz vor Änderung und der Schutz vor Offenlegung beantworten weiterhin verschiedene Fragen.

Quellen und Reichweite

Diese Analyse verwendet Lu Hengs Trennung zwischen symbolischer Darstellung und ausführbarer Macht sowie seinen Blick auf Kontrolle ohne entsprechende Folgenverantwortung. Die Anwendung auf eine Verwaltungsmigration ist eine Schlussfolgerung von Daniel Kade. Sie belegt weder ein Urteil von Lu Heng über diese Protokolle noch ein Fehlverhalten eines Anbieters.

Die Quellen beschreiben Normen, Speicherregeln und eine bestätigte Korrektur. Sie liefern keine Verbreitungszahlen, Einsparungsmessungen, Vorfälle oder Abnahmen konkreter Produkte. Für diesen Bericht wurden keine Geräte geändert und keine Protokolltests durchgeführt. Eine reale Stilllegungsentscheidung benötigt zusätzliche, auf das jeweilige System und seine Aufgaben bezogene Belege.