Zusammenfassung

  • OBJECT-GROUP, MODULE-COMPLIANCE und AGENT-CAPABILITIES bezeichneten Objektbestand, Mindestvertrag und behauptete Fähigkeiten einer Produktversion.
  • Diese Angaben wurden konzeptionell bei der Implementierung entfaltet, nicht als dynamische Prüfung des laufenden Agenten.
  • Ein implementiertes Objekt musste einen hinreichend genauen Wert oder eine ehrliche Ausnahme liefern und bei Schreibbarkeit das verwaltete System tatsächlich beeinflussen können.

Drei Bedeutungen von Unterstützung

RFC 1444 zerlegte die pauschale Aussage, ein Produkt unterstütze eine MIB. Eine OBJECT-GROUP fasste zusammengehörige verwaltete Objekte zusammen. MODULE-COMPLIANCE nannte das Minimum für einen Konformitätsanspruch. AGENT-CAPABILITIES beschrieb die genaue Unterstützung und Abweichungen einer Produktversion.

Gruppen konnten unbedingt verpflichtend, nur unter einer beschriebenen Bedingung verpflichtend oder optional sein. Für einzelne Objekte ließen sich Lese- und Schreibsyntax sowie Mindestzugriff verfeinern. Der breite Modulname konnte diese Unterschiede nicht mehr verdecken.

Der RFC-Editor-Eintrag datiert das Proposed Standard auf April 1993 und vermerkt die spätere Ablösung durch RFC 1904. Die historische Leistung war kein stärkeres Etikett, sondern ein Anspruch, der bis zum einzelnen Objekt zerlegt werden konnte.

Der Mindestvertrag maß keinen Puls

Der Text erklärt die Makros als etwas, das konzeptionell bei der Implementierung und nicht zur Laufzeit expandiert. Sie sagten, was gebaut werden musste und was ein Hersteller gebaut zu haben behauptete. Das Lesen der Erklärung befragte keinen lebenden Prozess.

Für MANDATORY-GROUPS galt dennoch Vollständigkeit. Wer Konformität beanspruchte, musste jedes Objekt jeder verpflichtenden Gruppe implementieren. Lieferte ein Pflichtobjekt in jeder MIB view noSuchObject, war der Agent für dieses Modul nicht konform. Eine GROUP-Klausel konnte eine Bedingung festhalten, etwa dass eine Protokollgruppe nur bei implementiertem Protokoll verpflichtend wurde.

Der Vertrag benennt damit den Prüfpunkt. Ob die Bedingung auf diesem Gerät gilt, welche view der aktuelle Principal sieht und ob der zuständige Prozess heute gesund ist, bleibt Beobachtung.

Die Kennung öffnete eine Erklärung

AGENT-CAPABILITIES konnte die genaue Beschreibung an sysObjectID oder eine snmpORID-Instanz binden. Eine Managementstation las die Kennung, schlug sie in ihrer Datenbank nach und optimierte die Kommunikation. Bei dynamisch gelernten Objektressourcen konnte die allgemeine Systemkennung zu grob sein; Operational-Resource-Kennungen ergänzten sie.

Das vermied aussichtslose Aufrufe, respektierte Read-only-Varianten, begrenzte Werte auf angekündigte Syntax und lieferte notwendige Zellen bei der Zeilenerstellung.

Doch die Kennung führte zu einer Herstellerbehauptung. Sie maß nicht, ob die Funktion aktiviert, in der aktuellen view sichtbar, fehlerfrei oder sachlich korrekt war. Das Verzeichnis verkürzte die Prüfung; es bestand sie nicht.

Abweichung wurde zu belastbarer Information

Das Beispiel des RFC nennt ein nicht implementiertes Objekt, eingeschränkte Syntax, ein nur lesbares Objekt, unterschiedliche Wertebereiche beim Lesen und Schreiben sowie eine notwendige Zelle zur Zeilenerstellung. Teilweise Unterstützung ließ sich konkret statt beschönigend beschreiben.

Auch semantische Identität wurde geschützt. Jede nicht redaktionelle Änderung an Gruppe, Konformitätsdefinition oder Fähigkeitsdefinition verlangte einen neuen Deskriptor und OID. Sonst hätte dieselbe Kennung zu verschiedenen Zeiten verschiedene Verträge bezeichnet.

Das laufende Objekt fällte das Urteil

RFC 1444 definierte Implementierung als Verhalten. Bei Abruf musste der Agent einen hinreichend genauen Wert zurückgeben. Bei einem schreibbaren Objekt musste eine Set-Operation die zugrunde liegende verwaltete Einheit hinreichend beeinflussen können. War das Objekt nicht implementierbar, sollte der Agent eine Ausnahme oder einen Fehler wie noSuchObject liefern, niemals einen erfundenen Wert.

Daraus entstehen vier Beweisebenen. Die Erklärung gehört zur Version. Principal, view und Zugriff bestimmen die adressierbare Fläche. Das Protokoll liefert Wert, Ausnahme oder Fehler. Eine unabhängige Beobachtung prüft Richtigkeit, Wirkung und Fortbestand.

Eine zurückgegebene Zahl beweist nicht allein die Richtigkeit des Zählers. Ein erfolgreicher Set beweist nicht allein die beabsichtigte Zustandsänderung oder ihre Persistenz nach einem Neustart. Eine Ausnahme darf auch nicht als Nullwert geglättet werden. Gerade das Fehlen kann der entscheidende Befund sein.

Die Nachfolger hielten die Grenze

Der Eintrag zu RFC 1904 dokumentiert die Ablösung von 1996, der Eintrag zu RFC 2580 die nächste von 1999. RFC 2580 hielt am Kern fest: Eine beanspruchte Gruppe erforderte alle Objekte oder Benachrichtigungen; eine Produktfähigkeitsangabe half über sysORID beim Optimieren, wurde aber keine Laufzeitattestierung.

Sicherheit blieb eine eigene Ebene. RFC 1444 behandelte Sicherheitsfragen ausdrücklich nicht. RFC 3410 erklärte später, dass das frühere SNMPv2-Framework seine Ziele für Authentisierung, Vertraulichkeit, Autorisierung, Zugriffskontrolle und Administration nicht erreicht hatte und SNMPv3 diese Defizite adressierte.

Lu Hengs Running-Code-Primat ordnet Veröffentlichung, Implementierung, Validierung, Einsatz und Nutzung als getrennte Schritte. Seine Realitätsebenen trennen symbolische Geltung von ausführbarer Wirkung.

RFC 1444 entwertete Erklärungen nicht. Es machte sie präzise und begrenzte ihre Reichweite. Das Typenschild gehört zur Maschine. Den Prüfstand ersetzt es nicht.

Quellen