Zusammenfassung

  • RFC 1095 führt CMOT und SNMP mit demselben Status als Draft Standard und Recommended. Die frühere Politik sah SNMP für den kurzfristigen Bedarf und CMIS/CMIP für die langfristige Entwicklung vor, verlangte aber praktische Berichte über beide Wege.
  • Beide Protokollgruppen arbeiteten mit derselben Internet-MIB. Das vereinheitlichte Objektbedeutungen, nicht den Ablauf: CMOT brauchte ein Profil aus CMIS, CMIP, ACSE, ROSE, ASN.1 und leichter Präsentation über TCP oder UDP.
  • Das Profil galt innerhalb einer Managementdomäne, ließ die eigentlichen Anwendungen außerhalb des Standards und machte Zugriffskontrollparameter optional. Eine angenommene Assoziation oder positive Antwort belegte deshalb keine institutionelle Vollmacht und keine unabhängig beobachtete Geräteänderung.

Die Empfehlung hatte damals zwei Spalten

Eine Erfolgsgeschichte lässt Alternativen im Rückblick zwangsläufig wirken. SNMP wurde zum vertrauten Werkzeug; CMOT erscheint als aufwendiger Gegenentwurf. RFC 1095 bewahrt einen früheren Zustand: Das Internet Activities Board hatte zwei verschiedenen Managementprotokollen exakt denselben Standardstatus gegeben.

Netzwerkfähige IP/TCP-Systeme sollten mindestens eines der beiden implementieren. Das IAB erwartete Erfahrungsberichte von Systembauern und Anwendern für beide. „Recommended“ war eine Aufforderung zur Implementierung und Erprobung, keine Aussage über gleiche installierte Basis.

Bereits RFC 1052 hatte die Zeitachsen getrennt. SNMP sollte wegen vorhandener, laufender Software kurzfristig die Grundlage bilden. CMIS/CMIP sollte als langfristige, ISO-basierte Architektur entwickelt, eingesetzt und getestet werden. Das Internet wollte praktische Werkzeuge und zugleich eine Stimme in der internationalen Standardisierung.

Die Doppelstrategie schob die Entscheidung nicht auf. Sie behandelte Betriebsdruck und Architekturentwicklung als unterschiedliche Aufgaben. Das Netz musste sofort verwaltet werden, während die umfassendere Lösung anhand echter Implementierungen lernen sollte.

RFC 1109 zeigte im Sommer 1989 die unterschiedliche Reife. Für SNMP nannte sie Implementierungen in Netzen und Produkten. Auf der Sitzung war keine öffentlich verfügbare CMOT-Implementierung gemeldet, wohl aber geplante Arbeiten. Die in RFC 1095 erwähnten Prototypen von Interop ’88 belegten Machbarkeit und Multivendor-Potenzial, nicht flächendeckenden Einsatz.

Die gemeinsame MIB war Semantik, nicht Bedienoberfläche

RFC 1052 hatte eine eigene MIB-Gruppe eingerichtet und ihr Ergebnis beiden Protokollgruppen zugewiesen. RFC 1109 berichtete später von ungefähr hundert obligatorischen Variablen, auf die sich SNMP- und CMOT-Arbeitsgruppen geeinigt hatten.

Ein IP-Zähler, eine Schnittstelle oder ein Routeneintrag sollte seine Bedeutung behalten, auch wenn das Abfrageprotokoll wechselte. Die gemeinsame MIB war die semantische Voraussetzung für den damals erwarteten Übergang von der kurzfristigen zur langfristigen Familie.

Doch gemeinsame Substantive ergeben noch kein gemeinsames Gespräch. Instanzen, Geltungsbereich, Filter, Ereignisse, Fehler, Sitzungsaufbau und Schutzmechanismen mussten weiterhin definiert werden. Ebenso wenig entstand durch die MIB ein Werkzeug, das ein Operator tatsächlich bedienen konnte.

RFC 1109 stellte deshalb die Anwendungen in den Mittelpunkt. Weder die damalige SNMP- noch die CMIS-Schnittstelle konnte historische Abfragen oder zeitversetzte Befehle direkt ausdrücken. Die MIB legte fest, was benannt werden konnte. Sie legte nicht fest, welche Arbeit ein Managementprodukt daraus machte.

RFC 1095 brauchte ein umfangreiches Profil, gerade weil die Objekte gemeinsam waren. Ihre Bedeutung musste durch einen ausgewählten Satz von CMIS/CMIP-Optionen transportiert werden, ohne dass unabhängige Implementierungen an unterschiedlichen Varianten vorbeiredeten.

Ein Profil ist die Summe der festgelegten Nähte

CMOT bestand nicht aus einem CMIP-Header über TCP. ASN.1 beschrieb Daten, ACSE die Anwendungsassoziation, ROSE entfernte Operationen, CMIS und CMIP die Managementdienste und Nachrichten. Internet-SMI und -MIB lieferten die Objekte. RFC 1085 lieferte eine leichte Präsentationsschicht.

RFC 1095 bestimmte Funktionsgruppen und Anwendungskontext, Klassen und Instanzen, Scope, Filter, Synchronisation und PDU. Danach legte es fest, wie ACSE, ROSE und CMIP über die Präsentation serialisiert wurden. Interoperabilität entstand nicht aus einem Markennamen, sondern aus diesen übereinstimmenden Entscheidungen.

Die leichte Präsentation vermied einen vollständigen ISO-Stapel aus Präsentations-, Sitzungs- und Transportschicht. ISO-Anwendungselemente konnten direkt auf Internet-Transporte abgebildet werden. Das verringerte Code und Aufwand, nicht die Zahl der zu prüfenden Vereinbarungen.

Die Aussage „unterstützt CMIP“ verrät weder Kontext noch Funktionsumfang, Kodierung, MIB-Version oder Transport. Das Profil reduziert einen großen Optionsraum auf eine testbare Begegnung. Jenseits davon bleiben Qualität der Anwendung, Korrektheit des Geräts und Befugnis des Betreibers offen.

Die Präsentation machte UDP nicht zu TCP

RFC 1085 nannte den TCP-basierten Dienst „high-quality“ und den UDP-basierten „low-quality“. Die ausdrückliche Warnung, niedrige Qualität bedeute tatsächlich niedrige Qualität, schützte vor einer falschen Abstraktion. UDP erbte nicht Verbindung, Reihenfolge oder Wiederherstellung von TCP.

RFC 1095 ließ beide Abbildungen zu. Manager nutzten Port 163, Agenten Port 164, jeweils über TCP oder UDP. Für UDP galt eine PDU-Grenze von 484 Oktetten, um unter den damaligen Annahmen IP-Fragmentierung zu vermeiden. Die Entdeckung eines Partners konnte aus einem Verzeichnis, einer lokalen Tabelle oder einem Assoziationsversuch stammen.

Eine Adresse beschrieb deshalb noch keinen vollständigen CMOT-Endpunkt. Transport, Rolle, Profil und Herkunft der Zuordnung gehörten dazu. Eine TCP-Verbindung und ein empfangenes UDP-Datagramm belegten unterschiedliche Eigenschaften des Wegs. Keine Beobachtung belegte die institutionelle Vollmacht hinter dem Manager.

Auch Fehler mussten an der richtigen Naht bleiben. Verlust, Präsentationskonflikt, abgelehnte Assoziation, fehlende CMIS-Funktion, Zugriffspolitik und ein Fehler des Managed Object konnten nach außen ähnlich aussehen. Ein Sammelstatus „CMOT gestört“ vernichtete Ursachenwissen.

Eine Managementdomäne ist eine Verwaltungsgrenze

RFC 1095 beschrieb Manager, Agenten, Managed Objects und eine Grundlage für die fünf OSI-Funktionsbereiche. Die konkreten Managementanwendungen ließ es ausdrücklich offen. Standardisiert wurde die minimale multivendorfähige Architektur, nicht die gesamte Arbeit des Operators.

Auch Beziehungen zwischen Managementdomänen lagen außerhalb des Geltungsbereichs. Die Architektur behandelte eine einzige Domäne. Das war mehr als eine Netzgrenze.

Eine Managementdomäne ordnet Systeme, Befugnisse, Richtlinien und Verantwortung. Routing kann ein Paket über eine Organisationsgrenze tragen. Es überträgt aber keine Delegation, das fremde Gerät zu verändern.

CMOT konnte die Form einer Operation und ihrer Antwort bestimmen. Es konnte nicht entscheiden, ob der Manager einer anderen Institution handeln durfte oder wer die Folgen trug. Föderation brauchte Vereinbarungen oberhalb des Protokollprofils.

Technische Rollen können spiegelbildlich implementiert sein; institutionelle Macht bleibt gerichtet, begrenzt und widerrufbar.

Die Assoziation war Kompatibilität, keine Vollmacht

ACSE handelte vor den Managementoperationen den Anwendungskontext und die Funktionsgruppen aus. Die Annahme einer Assoziation war ein belastbarer Kompatibilitätsnachweis zwischen zwei Stacks.

Sie war kein Identitäts- oder Mandatsnachweis. Zugriffskontrollparameter auf Assoziations- und Anfrageebene waren optional. RFC 1095 empfahl die Behandlung beim Aufbau und erwartete spätere TCP/IP-Authentisierung; das Anfragefeld durfte ein Empfänger ignorieren. Eine einfache Übergangslösung konnte aus einem unverschlüsselten Passwort bestehen.

Das belegt Problembewusstsein, nicht eine gelöste Sicherheitsarchitektur. RFC 1109 zählte Benutzerzugriff und die Authentisierung von Befehlen und Antworten weiterhin zu den offenen Bereichen beider Protokolle.

Erreichbarkeit erlaubt den Versuch. Profilkompatibilität erlaubt das Gespräch. Authentisierung ordnet eine Nachricht einem Principal zu. Autorisierung erlaubt eine Operation. Jede Stufe verlangt einen eigenen Befund.

Eine positive Antwort endete vor der Gerätewirkung

CMIS konnte lesen, Attribute ändern und Ereignisse melden. RFC 1095 verlangte dabei Best-effort-Synchronisation; atomare Synchronisation war optional. Daraus entstand keine universelle Transaktion über reale Hardware.

Eine erfolgreiche Antwort zeigt, dass der profilierte Stack eine Anfrage verarbeitet und der Agent ein protokollgemäßes Ergebnis gemeldet hat. Sie zeigt nicht allein, dass eine Karte umgeschaltet wurde, der Verkehr einen neuen Weg nahm, die Konfiguration einen Neustart überstand oder ein Dienst besser funktionierte.

Dafür braucht es Rücklesen, Ereignisse, unabhängige Zähler, Persistenzprüfung oder externe Messung. Stammen Befehlsstatus und Bestätigung vom selben Agenten, muss diese gemeinsame Quelle sichtbar bleiben.

Das ist keine Abwertung des Protokolls, sondern saubere Zuständigkeit. CMOT normiert Nachricht und Semantik. Instrumentierung übersetzt in Gerätehandlungen. Hardware und Netz erzeugen Wirkung. Jede Grenze kann den Erfolg der vorherigen Stufe aufnehmen oder brechen.

RFC 1189 zeigte die Versionsgrenze des Profils

RFC 1189 ersetzte RFC 1095 im Oktober 1990 nach Abschluss der ISO-Standards für CMIS/CMIP. Es entfernte die Einführung, lagerte MIB-Semantik aus, übernahm aktualisierte Implementierungsvereinbarungen und änderte die Aushandlung, erkannte aber den älteren Anwendungskontext weiter.

Ein Protokollname enthält also nicht seine gesamte Betriebsidentität. Ändert sich der Basisstandard, muss das Profil Versionen, Optionen und kompatible Kontexte erneut festlegen.

Die doppelte Empfehlung von 1989 war vergänglich. Die Trennung bleibt: dasselbe Objekt benennen, seine Bedeutung übertragen, zum Ändern befugt sein und die Änderung beobachten sind vier verschiedene Leistungen. RFC 1095 verband die ersten beiden und gab nicht vor, damit auch die letzten beiden zu besitzen.

Quellen