Zusammenfassung

  • RFC 1052 empfahl SNMP als kurzfristige Managementbasis und hielt Craig Partridges Vorschlag fest, HEMS zugunsten einer internetweiten Einigung zurückzuziehen. Zugleich wurde HEMS RFC 1024 ausdrücklich zum Ausgangsmaterial der gemeinsamen MIB-Arbeit.
  • RFC 1076 erschien nach dieser Entscheidung. Sein kleiner Interpreter verarbeitete ASN.1-Objekte im Strom, durchlief einen hierarchischen Datenbaum, filterte veränderliche Tabellen und gab die repräsentierte Struktur nach Lese- oder Änderungsoperationen zurück.
  • Protokollauswahl, Wiederverwendung von Definitionen, Autorisierung, Rückgabewert und beobachtete Gerätewirkung waren getrennte Tatsachen.

Der Rückzug, der eine gemeinsame Betriebsbasis ermöglichte

RFC 1021 beschrieb ein Skalierungsproblem. Solange wenige Hersteller die wichtigen Gateways lieferten, konnte ein erfahrener Administrator deren private Werkzeuge kennen. Mit mehr Netzen, Geräten und Anbietern wurde persönliches Spezialwissen zu einer ungeeigneten Schnittstelle.

Das High-Level Entity Management System teilte die Arbeit. Auf dem verwalteten System sollten ein kleiner Abfrageprozessor und ein Ereignisgenerator laufen. Intelligentere Anwendungen im Managementzentrum stellten Fragen und interpretierten standardisierte wie herstellerspezifische Werte. Kritische Netzknoten mussten dadurch nicht die ganze Komplexität des Managementsystems tragen.

HEMS trennte Überwachung von Steuerung. Überwachung sammelte Daten über Verhalten; Steuerung sollte Verhalten in Echtzeit verändern. RFC 1021 erklärte, dass eine Änderung ohne Beobachtung ihrer Wirkung kaum nützlich sei. Der erste Entwurf setzte deshalb auf Überwachung und räumte ein, dass allgemeine Steuerungen und starke Zugriffsschutzmechanismen noch nicht vollständig bestimmt waren.

Im März 1988 wurde daraus eine Auswahlfrage. RFC 1052 dokumentiert die Prüfung von HEMS, SNMP und CMIP/CMIS. Das IAB empfahl SNMP für den kurzfristigen Einsatz, weil Software vorhanden und bereits in Betrieb war und die Gemeinschaft schnell konvergieren musste.

Der Bericht nennt auch den entscheidenden institutionellen Schritt: Craig Partridge empfahl, HEMS aus der Auswahl zurückzuziehen, um eine Einigung für das gesamte Internet zu ermöglichen. Das war keine Entsorgung sämtlicher HEMS-Arbeit. Derselbe Bericht würdigte den umfassenden, breit diskutierten Satz von Managementelementen und wies die MIB-Arbeitsgruppe an, die Definitionen aus RFC 1024 neben SNMP- und CMIP/CMIS-Material als Eingang zu verwenden.

Ein möglicher Träger schied aus. Ein Teil seiner semantischen Fracht blieb ausdrücklich im Verfahren.

Die ausführliche Spezifikation eines nicht gewählten Weges

RFC 1076 wurde im November 1988 veröffentlicht und ersetzte RFC 1023. Das Dokument eröffnete die April-Entscheidung nicht neu. Es vervollständigte die experimentelle HEMS-Sprache für Überwachung und Steuerung.

Eine Abfrage bestand aus einer Folge von ASN.1-Objekten. Datenobjekte wurden bei Ankunft auf einen begrenzten Stapel gelegt, Operationscodes sofort ausgeführt. Teile der Antwort konnten entstehen, während der Agent noch den Rest der Abfrage empfing.

Damit musste ein Gateway die vollständige Anfrage nicht puffern, und mehrere Anweisungen passten in einen Austausch. Der Preis war zeitliche Staffelung: Eine spätere Anweisung konnte scheitern, nachdem frühere Ergebnisse bereits gesendet worden waren. Die Antwort war ein Ausführungsprotokoll, keine atomare Momentaufnahme.

Der Interpreter kannte nur BEGIN, END, GET, GET-ATTRIBUTES, GET-RANGE, SET, CREATE und DELETE. Es gab keine gespeicherten Programme, Unterprogramme oder allgemeine Kontrollstrukturen. Pfade, Schablonen, Werte und Filter verliehen dem kleinen Befehlssatz Ausdruckskraft.

Verwaltete Daten erschienen als Baum. Wörterbücher gruppierten Unterbäume, der Pfad von der Wurzel benannte einen Knoten, Blätter enthielten Werte. Besuchte Teile wurden mit ihrem vollständigen Kontext in die Antwort kopiert. Eine kleine ASN.1-Tagnummer war nur innerhalb ihres Wörterbuchs eindeutig; Kontext gehörte zum Beleg.

Werte identifizierten Tabellenzeilen besser als Plätze

Schnittstellen-, Routing- und TCP-Tabellen ändern ihre Reihenfolge. Das dritte Element vor einem Neustart muss danach nicht wieder das dritte sein. RFC 1076 setzte deshalb Filter auf Inhalte statt einen allgemeinen Positionsindex.

Filter prüften Vorhandensein, Gleichheit sowie obere oder untere Grenzen und kombinierten Bedingungen mit AND, OR und NOT. Eine Anwendung konnte die Schnittstelle mit einer bestimmten IP-Adresse suchen, nur deren Zähler lesen, in ihre ARP-Tabelle absteigen oder alle passenden Einträge ändern.

Die Spezifikation benannte eine Unsicherheit: Fand ein gefiltertes BEGIN mehrere Wörterbücher, durfte irgendeines gewählt werden. Ob Mehrdeutigkeit ein Fehler sein sollte, müsse Erfahrung zeigen. Syntaktische Gültigkeit bewies also keine eindeutige Zielauswahl.

GET-RANGE konnte einen Abschnitt eines OctetString lesen, sogar eine maschinenabhängige Speicherdarstellung. Bei einem GET des gesamten Wörterbuchs wurde Speicher jedoch absichtlich nicht automatisch geliefert. Navigierbarkeit war keine pauschale Ausleseerlaubnis.

Der zurückgegebene Baum war nicht das ganze Gerät

SET und CREATE gaben den betroffenen Baumteil nach der Operation zurück. DELETE lieferte normalerweise nichts; nicht löschbare Treffer konnten erscheinen. Ein SET auf ein schreibgeschütztes Feld musste keinen Fehler erzeugen. Der Agent konnte den unveränderten Istwert zurückgeben, den die Anwendung mit ihrem Wunsch verglich.

Für Steuerungen beschrieb RFC 1076 ein virtuelles Befehls- und Statusregister. Ein geschriebener Code konnte eine implementierungsspezifische Nebenwirkung auslösen, etwa eine Schnittstelle herunterfahren. Ein späteres Lesen konnte einen Status liefern.

Ein gewünschter Rückgabewert belegte die Darstellung der HEMS-Schnittstelle nach der Verarbeitung. Er belegte nicht unabhängig, dass der physische Link verstummte, Routen konvergierten, Nachbarn reagierten, die Änderung einen Neustart überlebte oder Pakete den vorgesehenen Ersatzweg nahmen. Befehlsquittung und Wirkung brauchten verschiedene Beobachtungen.

Diese Trennung gilt auch für heutige APIs. Eine korrekte Annahme kann vor Warteschlange, Teilwirkung, späterem Überschreiben oder einem Ergebnis liegen, das nur andere Telemetrie sichtbar macht. RFC 1076 beschrieb diese Evidenzgrenze bereits im Datenmodell.

Drei Ursachen erhielten denselben leeren Wert

RFC 1022 definierte HEMP als Hülle für Anfragen, Antworten, Ereignisse und Fehler und reservierte Abschnitte für Authentisierung und Verschlüsselung. Eine vorgesehene Hülle beweist jedoch keinen Schutz einer konkreten Nachricht; 1987 waren noch keine Verschlüsselungstypen zugewiesen.

RFC 1076 legte das Autorisierungssystem nicht fest. Eine Anfrage erhielt aus ihrer Umgebung eine Stufe oder Fähigkeiten, und jedes Datenelement prüfte den Zugriff. GET, SET, CREATE und DELETE konnten eingeschränkt werden. Ein Wörterbuch durfte für BEGIN nicht vollständig verborgen werden, weil sonst ein verweigerter Zweig die ganze zusammengesetzte Abfrage beendete.

Ein unbekanntes Tag, ein nicht implementiertes optionales Feld und ein unzulässiger Zugriff ergaben denselben Null-Längen-Wert. Generische Abfragen konnten dadurch unterschiedliche Geräte durchlaufen. Aus der Antwort allein ließ sich aber die Ursache des Schweigens nicht ermitteln.

Ein terminierender Verarbeitungsfehler enthielt Code, interne Instanz, Byteposition, Operation und Beschreibung. Waren verschachtelte ASN.1-Ausgabeobjekte geöffnet, wurde der Fehler in jede offene Ebene und am Schluss erneut eingesetzt. So blieb eine teilweise gesendete Antwort decodierbar; frühere Nebenwirkungen wurden dadurch nicht zurückgerollt.

Die spätere Einfachheit beweist keine vollständige Abstammung

Im August 1989 meldete RFC 1109 SNMP in mehreren Netzen und nannte Hersteller- und Referenzimplementierungen. Gleichzeitig blieben Skalierung, Konfigurationsmanagement, Benutzerzugriff und Befehlsauthentisierung offen. Die Wahl schuf zügig gemeinsame Praxis, nicht das Ende aller Managementfragen.

RFC 1155 beschrieb später die standardisierte SMI mit hierarchischen OBJECT IDENTIFIERn, eingeschränkten ASN.1-Typen und einem virtuellen Informationsspeicher. RFC 1157 definierte SNMP mit der kleineren Oberfläche Get, GetNext, Set und Trap und dokumentierte den empfohlenen Betriebsrahmen.

Ähnliche Hierarchien und ASN.1 reichen nicht für eine direkte Linie von jedem HEMS-Objekt zu jedem späteren OID. RFC 1052 belegt eine engere Verbindung: RFC 1024 wurde ausdrücklich als Eingang zur MIB-Arbeit bestimmt. Es belegt keine Feld-für-Feld-Kopie und keine Drahtkompatibilität von RFC 1076 und SNMP.

Gerade diese schmale Aussage zeigt reife Standardisierung. Die Gemeinschaft konnte einen Protokollwettbewerb beenden, nützliche Definitionen mit Herkunft weitergeben und die alternative Konstruktion dokumentieren, ohne sie nachträglich zur heimlichen Siegerin zu erklären.

Quellen und Grenzen

RFC 1021 liefert den Systemrahmen, RFC 1022 die Hülle, RFC 1024 die Informationsdefinitionen, RFC 1052 die Auswahl, RFC 1076 die Sprache, RFC 1109 den Betriebsbericht, RFC 1155 die spätere SMI und RFC 1157 das spätere SNMP. Sie liefern keine HEMS-Einsatzstatistik, Produktionsmitschnitte, vollständige Objektgenealogie oder Wirkung eines konkreten Befehls.

Die belastbare Geschichte trennt drei Sätze: HEMS wurde nicht das gemeinsame Managementprotokoll. Seine Informationsarbeit verschwand nicht vollständig. Seine Antwort stellte einen Datenbaum dar, nicht alle Folgen in der verwalteten Welt.