Zusammenfassung

  • RFC 1303 beschreibt mit MODULE-CONFORMANCE behauptete MIB-Gruppen und Variationen eines SNMP-Agenten, gebunden an dessen sysObjectID.
  • Name, Syntax, Implementierungsstatus und Zugriff beantworten unterschiedliche Fragen; der Zugriff ist laut RFC von einer administrativen Autorisierungspolitik unabhängig.
  • Ein Kompatibilitätseintrag kann eine Station bei der Wahl einer Anfrage leiten. Er beweist weder umfassenden aktuellen Support noch Berechtigung, erfolgreiche Ausführung, Bestand oder Wirkung einer Änderung.

Analyse

Eine Fähigkeitserklärung ist keine Anweisung

RFC 1303 erschien im Februar 1992 als Informational RFC. Das Dokument ging nicht davon aus, dass jedes Gerät jede MIB-Gruppe gleich implementiert. Ein Modul besteht aus Konformitätsgruppen; ein Agent kann nur einen Teil davon anbieten und einzelne Objekte mit eingeschränkter Syntax oder anderem Zugriff ausführen. Ohne diese Kenntnis würde eine Managementstation nicht mutig, sondern blind optimieren.

Die vorgeschlagene Makroform MODULE-CONFORMANCE erlaubt es dem Implementierer, den beanspruchten Grad der Unterstützung zu beschreiben und ihn an sysObjectID zu binden. Eine Station kann die Kennung lesen, in einer Datenbank nachsehen und ihre Protokollinteraktion anpassen. SUPPORTS, INCLUDES und VARIATION machen Modul, Gruppen und Abweichungen prüfbar.

Die Bindung ist jedoch kein Mandat. sysObjectID benennt keine Person, die für Risiko, Zeitfenster oder Rücknahme verantwortlich ist. Und sie ist nicht zwingend vollständig: Der RFC weist darauf hin, dass ein Agent Objekte dynamisch lernen kann, etwa über SMUX-Peers. Zusätzliche MIB-Objekte müssen die Beschreibung dann erweitern. Ein Eintrag kann somit nützlich sein, ohne eine vollständige Aussage über den laufenden Zustand abzugeben.

Schreibbar ist nicht genehmigt

Ein verwaltetes Objekt hat mindestens Namen, Syntax, Zugriffsebene und Implementierungsstatus. Syntax begrenzt abstrakte Werte, Status trennt verpflichtend, optional, obsolet und veraltet. Zugriff fragt, ob das Lesen oder Schreiben einer Instanz „protokollarisch Sinn ergibt“. Genau dort setzt die entscheidende Einschränkung an: Diese Zugriffsebene ist unabhängig von administrativer Autorisierung.

Ein read-write-Objekt erteilt also kein Recht, es zu ändern. Es sagt nicht, welcher Verantwortliche zustimmt, welche lokale Regel gilt oder ob eine Operation zu diesem Zeitpunkt tragbar ist. Umgekehrt kann ein autorisierter Wunsch an einer fehlenden Implementierung, einer unzulässigen Schreibsyntax oder einer nicht erfüllten Erstellungsvoraussetzung scheitern.

Die getrennten Klauseln SYNTAX und WRITE-SYNTAX zeigen das in der Form selbst. Sind beide vorhanden, betrifft die erste das Lesen und die zweite das Schreiben. Das Beispiel enthält nicht verfügbare und nur lesbare Objekte sowie Fälle, in denen lesbare und schreibbare Wertebereiche verschieden sind. Ein sichtbarer Zustand ist keine Ermächtigung zur Ersetzung. Eine formgerechte Nachricht ist kein Einverständnis. Eine Antwort ist kein Nachweis des beobachteten Netzeffekts.

Eine vollständige Zeile ist nur ein vollständiger Kandidat

CREATION-REQUIRES benennt die Spalten, die per SNMP-Set gesetzt werden müssen, bevor der Agent eine neue Zeileninstanz anlegt. Fehlt die Klausel, unterstützt der Agent diese Erstellung über SNMP nicht. Die Regel sagt, wann eine Anfrage für die Schnittstelle vollständig ist.

Sie sagt nicht, dass die verantwortliche Organisation die Änderung freigegeben hat, dass Abhängigkeiten bereit sind, dass ein Rollback existiert oder dass ein Dienst später den erwarteten Zustand zeigt. Auch die Makroexpansion geschieht laut RFC konzeptionell während der Implementierung, nicht zur Laufzeit; Sicherheitsfragen behandelt das Dokument nicht. Die Beschreibung darf deshalb nicht zur Echtzeitbescheinigung von Macht oder Erfolg werden.

Quellen

RFC 1303 ist Beleg für eine Konvention zur Beschreibung von SNMP-Agenten im Jahr 1992, nicht für einen realen Agenten, eine Berechtigung, ein erfolgreiches Set, dauerhafte Konfiguration oder ein Betriebsergebnis.