Zusammenfassung

  • active, notInService und notReady sind lesbare Zustände. createAndGo, createAndWait und destroy sind angeforderte Aktionen, die eine Abfrage niemals als gespeicherten Zustand zurückgibt.
  • Der Manager liefert Index, Werte und Absicht; Agent und MIB bestimmen Zulässigkeit und Übergang. Existenz, Vollständigkeit und Verfügbarkeit für das Gerät bleiben getrennte Aussagen.

Die frühe Tabelle war eine Anwendungskonvention

Objektbezeichner, Spalten und Instanzindizes ließen MIBs wie Datenbanktabellen erscheinen. RFC 1212 sprach dennoch bewusst von konzeptionellen Tabellen und Zeilen. Ihre Zusammengehörigkeit wurde von Anwendungen verstanden; SNMP selbst versprach weder eine vollständige Zeile noch relationale Konsistenz.

Ein MIB-Modul konnte für das Löschen einen Statuswert wie invalid festlegen. Ein SetRequest auf noch nicht existierende Instanzen konnte eine Zeile erzeugen, wenn der Agent dies zuließ. DEFVAL lieferte Vorgaben für ausgelassene Spalten. Was fehlte, war ein einheitliches Vokabular für die Zeit zwischen erstem Objekt und nutzbarer Konfiguration.

Bei mehreren Managementstationen wurde die Lücke praktisch. Wer erhielt einen gewählten Index? War eine teilweise angelegte Zeile sichtbar? Durfte das Gerät sie bereits verwenden? Die Oberfläche einer Tabelle beantwortete keine dieser Fragen.

RMON zeigte die Zeile im Bau

Die RMON-MIB in RFC 1271 führte mit EntryStatus einen direkten Vorläufer ein. createRequest, underCreation, valid und invalid unterschieden Anforderung, Aufbau, Gültigkeit und Entfernung. Bei konkurrierenden Managern erhielt nur der erste erfolgreiche Ersteller denselben Index; weitere Versuche scheiterten.

Ein OwnerString half kooperierenden Stationen zu erkennen, wer einen Eintrag angelegt hatte. Das RFC grenzte ihn ausdrücklich von Zugriffskontrolle ab. Ein unkooperativer Manager konnte den Eintrag weiterhin verändern oder löschen. Herkunftsinformation war nützlich, aber kein exklusives Mandat.

Damit lag die spätere Leitfrage offen: Welche Werte sind Befehle des Managers, und welche sind Beobachtungen des Agenten?

Sechs Werte bildeten zwei unterschiedliche Klassen

RFC 1443 standardisierte RowStatus für SNMPv2. Die aktuelle Definition steht in RFC 2579.

Eine bestehende Zeile liefert beim Lesen nur drei Zustände. active(1) bedeutet, dass das verwaltete Gerät sie verwenden kann. notInService(2) bedeutet, dass sie vorhanden, aber nicht verfügbar ist und der Agent genügend Informationen für einen Aktivierungsversuch besitzt. Daraus folgen weder interne Konsistenz noch freie Ressourcen oder späterer Erfolg. notReady(3) meldet fehlende erforderliche Spalteninstanzen.

Die anderen Werte sind Schreibaktionen. createAndGo(4) verlangt Erstellung und sofortige Aktivierung. createAndWait(5) verlangt Erstellung ohne Betrieb. destroy(6) verlangt die Entfernung aller Instanzen der konzeptionellen Zeile.

Eine GET-Operation gibt diese drei Aktionen nie zurück. Ein Manager darf auch notReady nicht setzen; nur der Agent stellt den Informationsmangel fest. Derselbe Statuspunkt transportiert so in einer Richtung einen Wunsch und in der anderen eine eng definierte Tatsache.

createAndGo hinterließ keinen normierten Entwurf

Für die Erstellung in einem Schritt wählt der Manager einen freien Instanzbezeichner und sendet benötigte Spalten gemeinsam mit RowStatus=createAndGo. Agentenspezifische Vorgaben können weitere Werte beisteuern.

Reichen die Informationen aus, erstellt der Agent die Zeile und ihr lesbarer Zustand ist sofort active. Reichen sie nicht aus, schlägt die Operation mit inconsistentValue fehl und die Zeile entsteht nicht. Das Scheitern ist kein gespeicherter Zwischenstand. Der Manager muss die fehlenden Anforderungen ermitteln und erneut senden oder, falls angeboten, den gestuften Weg wählen.

Die Ein-Schritt-Operation besitzt nur deshalb klare Bedeutung, weil Erstellung und Aktivierung zusammen gelingen oder gemeinsam ausbleiben.

createAndWait gab dem Unfertigen einen begrenzten Platz

Nach einem erfolgreichen createAndWait existiert die Zeile, bleibt dem Gerät jedoch entzogen. Fehlen Pflichtinformationen, liest der Manager notReady. Sind sie vorhanden, wird notInService sichtbar: ausreichend für einen Aktivierungsversuch, noch nicht im Betrieb.

Erst danach setzt der Manager active. Der Agent kann zustimmen oder wegen Werten, Ressourcen oder Gerätezustand inconsistentValue melden. Vollständigkeit ist keine Zusage der Aktivierung.

Ein Agent darf createAndWait mit wrongValue ablehnen und vollständige Erstellung in einem SetRequest verlangen. Ebenso kann er eine aktuell benutzte Zeile nicht außer Dienst nehmen oder löschen wollen.

Solche Zwischenzeilen belegen Ressourcen. RFC 2579 verlangt deshalb die Erkennung und Entfernung von Zeilen, die ungewöhnlich lange notReady oder notInService bleiben. Die DESCRIPTION soll den Zeitraum nennen; ohne Angabe werden ungefähr fünf Minuten einschließlich menschlicher Bedenkzeit vorgeschlagen. Das ist kein Nachweis für konkrete Produktwerte.

Das MIB-Modul behielt die Sachentscheidung

RowStatus legt nicht allgemein fest, welche Spalten im aktiven Zustand geändert werden dürfen. Die DESCRIPTION der Statusspalte muss die Aktivierungsvoraussetzungen und die Änderungsregeln nennen. Je nach Tabelle kann eine Änderung online möglich sein oder zuvor notInService verlangen.

RFC 4181 schärfte diese Pflichten. Dynamisch von Anwendungen erzeugte Zeilen sollen normalerweise eine read-create-RowStatus-Spalte besitzen. Neustartverhalten oder StorageType, vom Agenten selbst erzeugte oder entfernte Zeilen und Einschränkungen im aktiven Zustand müssen dokumentiert werden.

Standardisiert wurde damit die Grammatik der Übergänge, nicht jede lokale Betriebspolitik. Erst die konkrete MIB-Beschreibung macht die gemeinsamen Verben interoperabel.

Atomar war eine Anfrage, nicht das Netz

Bei der Zeilenerstellung reisen mehrere Spalten und der Statuswechsel oft in demselben SetRequest. RFC 3416 beschreibt zwei konzeptionelle Phasen: Zuerst werden alle Variablenbindungen geprüft; nur nach vollständigem Erfolg werden Werte geändert. Die Zuweisungen erfolgen so, als geschähen sie im Verhältnis zu den übrigen Zuweisungen derselben Anfrage gleichzeitig.

Scheitert eine Änderung, versucht die Entität die anderen rückgängig zu machen und meldet commitFailed. Ist vollständiges Rückgängigmachen unmöglich, lautet das Ergebnis undoFailed. Schon dieser Fehlercode markiert die Grenze der Abstraktion.

Die Semantik gilt für eine Anfrage an eine SNMP-Entität. Sie ist keine Transaktion über mehrere Router, kein verteilter Sperrmechanismus und kein Beweis für dauerhafte Speicherung oder Datenpfadwirkung. Managementerfolg und Betriebserfolg benötigen getrennte Nachweise.

Der Fortschritt bestand in einer ehrlichen Zwischenlage

RowStatus verteilt die Rollen. Der Manager formuliert die gewünschte Änderung. Das MIB-Modul veröffentlicht den Vertrag. Der Agent prüft Zugriff, Werte und Übergang. Das laufende Gerät liefert die letzte operative Wahrheit.

Eine sichtbare Zeile kann unvollständig sein. Eine vollständige Zeile kann außer Dienst bleiben. Ein Aktivierungswunsch kann scheitern. Selbst active sagt nichts Allgemeines über Neustartfestigkeit, Sicherheit oder tatsächlichen Verkehr. Gerade diese Begrenzung macht den Zustand belastbar.

Quellen und Grenzen

RFC 1212 und RFC 1271 belegen die frühen Konventionen und den RMON-Vorläufer. RFC 1443 und RFC 2579 definieren RowStatus. RFC 3416 begrenzt SetRequest, RFC 4181 beschreibt die spätere MIB-Disziplin. Die Quellen messen keine heutige Verbreitung, Herstellerkonformität, Sicherheit, universelle Bereinigungszeit oder Datenpfadwirkung. Die Trennung von Absicht, Bereitschaft und Betrieb ist eine Analyse des Mechanismus.