Zusammenfassung

  • RFC 1157 verlangt nach bestandenen Fehlerprüfungen Zuweisungen, die bezogen auf die Nachricht so wirken sollen, als seien sie gleichzeitig erfolgt. Die Antwort belegt weder einen Menschen noch dauerhafte Speicherung oder das Ende einer ausgelösten Aktion.
  • RFC 1905 trennt Validierung und Änderung. Ein Validierungsfehler wendet keine Zuweisung an; commitFailed und undoFailed zeigen dagegen Fehler während Änderung oder Rücknahme. Nicht jede Fehlermeldung bedeutet daher „nichts geändert“.
  • Marshall T. Rose ist kein Autor von RFC 1157. Unterzeichnet haben J. D. Case, M. S. Fedor, M. L. Schoffstall und J. R. Davin. Rose wird als Vorsitzender der IETF SNMP Extensions Working Group gewürdigt und verfasste frühe SMI- und MIB-Dokumente mit.

In einem Wartungsfenster soll ein Manager mit einer Nachricht eine Weiterleitungssteuerung, einen Zeitgeber und einen administrativen Zustand ändern. Der Agent gibt noError samt Variablenbindungen zurück. Ein Betriebsprotokoll könnte daraus „der Bediener hat die Änderung abgeschlossen“ machen. Darin stecken jedoch Protokollverarbeitung, Identität, Freigabe, Persistenz und reale Wirkung – fünf unterschiedliche Behauptungen.

RFC 1157 arbeitet enger. Zuerst prüft der Agent Namen, Werte, Antwortgröße und weitere Fehlerbedingungen. Trifft keine zu, erhält jede Variable ihren zugehörigen Wert. Die Zuweisungen sollen in Bezug auf die Nachricht so wirksam werden, als seien sie gleichzeitig gesetzt. Diese Eigenschaft ordnet das Verhältnis der Schreibvorgänge zueinander; sie ist keine Gesamtaussage über den Betrieb.

noError nennt deshalb keinen Mitarbeiter an der Konsole. Die Antwort belegt keine Genehmigung im Ticketsystem, keine Wiederherstellung nach einem Neustart und keinen bereits eingetretenen Netzeffekt. Der Agent äußert sich zu dem von ihm verwalteten Variablenraum.

Das frühe Modell erklärt diese Bescheidenheit. RFC 1157 bildet Management als Prüfen und Setzen von Variablen ab, nicht als beliebige imperative Befehlsmenge. Eine befehlsähnliche Wirkung kann durch einen Parameter entstehen, der anschließend eine Aktion auslöst; als Beispiel dient sinngemäß eine Zeitspanne bis zum Neustart. Parametersetzung und Geräteaktion sind getrennte Beobachtungen. Die erste kann bestätigt sein, während die zweite noch wartet, scheitert oder nur in einem anderen Subsystem sichtbar wird.

Auch die historische Zuschreibung braucht klare Grenzen. Auf RFC 1157 stehen J. D. Case, M. S. Fedor, M. L. Schoffstall und J. R. Davin. Rose gehört nicht zu den Autoren. In den Danksagungen wird er, damals bei The Wollongong Group, als Vorsitzender der IETF SNMP Extensions Working Group genannt. RFC 1155 über Struktur und Identifikation von Managementinformationen stammt dagegen von Rose und Keith McCloghrie; die MIB-Arbeiten behalten ebenfalls ihre eigenen Urheber. Das IETF-Personenprofil dokumentiert Roses umfangreiche Arbeit an Managementprotokollen, eine Biografie seine Rolle als SNMP-Vorsitzender und späterer IETF-Bereichsdirektor.

Diese korrekte Einordnung würdigt seinen Einfluss, ohne ihm eine fremde Autorenzeile zuzuschreiben.

RFC 1905 macht den späteren SetRequest zu einer deutlicheren Prüfstrecke. Vor einer Änderung werden unter anderem Zugriff, Schreibbarkeit, Typ, Länge, Kodierung, Wert, Konsistenz, Erzeugungsbedingungen und Ressourcen kontrolliert. Scheitert diese Validierung, antwortet der Agent mit dem passenden Fehler und wendet keine Zuweisung der Anfrage an. Hier ist die Aussage „die Anfrage trat nicht in die Änderungsphase ein“ belastbar.

Nach erfolgreicher Validierung versucht der Agent die Zuweisungen wiederum wie gleichzeitig. Doch RFC 1905 benennt Fehler der zweiten Phase. commitFailed bedeutet, dass eine Zuweisung nicht abgeschlossen werden konnte; die übrigen Änderungen sollen zurückgenommen werden. undoFailed meldet, dass die vollständige Wiederherstellung nicht garantiert werden konnte. Ersteres verlangt ein Auslesen des Zustands, Letzteres die Behandlung als potenziell gemischter Zustand bis zur unabhängigen Prüfung. Wer jeden Fehler als folgenlose Ablehnung einstuft, verliert genau diese wichtige Warnung.

Ein weiterer Vorbehalt betrifft dieselbe Variable, die mit unterschiedlichen Werten mehrfach vorkommt: RFC 1905 lässt das Verhalten implementationsabhängig. Die gemeinsame Liste erzeugt keine portable Reihenfolge für einen widersprüchlichen Auftrag.

Identität und Autorisierung liegen auf benachbarten, aber eigenen Beweisflächen. RFC 3411 trennt Nachrichtenverarbeitung, Sicherheit und Zugriffskontrolle und beschreibt sichere SET-Operationen als wesentliches Entwicklungsziel von SNMPv3. Das USM aus RFC 3414 kann ein Protokollsubjekt authentifizieren und Nachrichten schützen. Das VACM aus RFC 3415 bewertet Sicherheitsmodell, -name und -stufe, Kontext, Ansichtsart und Variable. Damit lässt sich ein technisches Subjekt mit einer Protokollregel verbinden. Wer als Mensch handelte und ob ein betrieblicher Auftrag bestand, folgt daraus nicht automatisch.

Eine tragfähige Betriebsspur bewahrt daher verknüpfte, aber getrennte Belege: Anfrage und geordnete Variablen, Antwort, Fehlerstatus und -index, authentifiziertes Subjekt, Zugriffsentscheidung, sofortiges Rücklesen, Persistenzprüfung und das Ergebnis jedes ausgelösten Subsystems. So bleibt die starke SetRequest-Aussage nutzbar, ohne Tatsachen zu behaupten, die der Agent nie beobachtet hat.

Sources