Zusammenfassung

  • Admin-Tabellen in RFC 2051 zeigten erwartete Werte nur lesend, Oper-Tabellen den aktuellen oder ausgehandelten Zustand. Ein Admin-Mode-Eintrag durfte verschwinden, obwohl aktive Sitzung und Oper-Eintrag erhalten blieben.
  • Sitzung, Konversation, optionale Zähler und ungewöhnliche Historie folgten eigenen Lebenszyklen. Keines davon bewies allein Konfiguration, Zustimmung der Gegenstelle, Anwendungserfolg, Vollständigkeit oder Sicherheit.

Der wichtigste Datensatz in RFC 2051 ist ein gelöschter. Eine appcModeAdminEntry darf entfernt werden, während eine aktive Sitzung ihren Mode noch nutzt; die appcModeOperEntry bleibt bestehen. Oben fehlt die Vorlage, unten läuft der Zustand weiter – beides kann korrekt sein.

Admin stellte Vorgaben oder erwartete Werte dar. Die MIB erstellte und änderte diese Konfiguration nicht; ihre Objekte waren lesend. Oper stellte gegenwärtige oder ausgehandelte Werte dar. Ein dynamisches Objekt konnte aus einer Admin-Vorlage entstehen und danach einen eigenständigen Lebenszyklus besitzen.

Damit sind konfiguriert, angefordert, vom Agenten angenommen, ausgehandelt und aktiv fünf verschiedene Aussagen. Das Löschen der Vorlage setzt eine bestehende Sitzung nicht zurück. Ein fortbestehender Oper-Eintrag genehmigt die alte Vorlage auch nicht für künftige Sitzungen.

RFC 2051 gliederte globale, LU-, Transaktionsprogramm-, Sitzungs-, Konversations- und CPI-C-Gruppen. Trotzdem war die MIB keine umfassende Fernsteuerung. Sie erzeugte oder löschte im Allgemeinen keine Partner-LUs, Modes oder Programme, aktivierte keine LUs, startete keine Konversationen und aktivierte keine Sitzungen.

Einige Kontrollen waren gezielt vorhanden: Statistik und Tracing wählen, CNOS-Befehle auslösen, eine Deaktivierung anfordern. Ein Schreibvorgang belegte die Anforderung an der Kontrollfläche, nicht deren Ergebnis.

Bei CNOS lagen gewünschte Werte in Admin und ausgehandelte Istwerte in Oper. IBMs heutige Beschreibung zum Starten von Sitzungen löst CNOS als Change Number Of Sessions auf. Das erklärt den Begriff, beweist aber weder eine konkrete RFC-Implementierung noch eine erfolgreiche Aushandlung.

Die aktive Sitzungstabelle kannte unbound, pendingBind, bound und pendingUnbind. Der Agent erzeugte und entfernte Zeilen entlang dieses Ablaufs. unbound in eine gebundene Sitzung zu schreiben konnte die Deaktivierung einleiten. Erst der spätere Zustand zeigte, was wirklich geschah.

Auch bound bezeichnete nur einen Sitzungszustand. Daraus folgte nicht, dass eine Konversation zugeteilt, ein Programm beendet, die Gegenstelle korrekt geantwortet oder ein Geschäftsvorgang gelungen war.

Konversationen waren kürzer. Der Agent erzeugte ihre Zeile beim Start und entfernte sie am Ende. Mehrere Konversationen konnten nacheinander über dieselbe weiterlaufende Sitzung gehen.

Statistik war eine optionale Schicht. Bei aktiver Erfassung gab es pro aktiver Sitzung eine Zeile. Die Zähler nutzten Counter32 aus RFC 1902 und wurden durch eine Laufzeit ergänzt. Ohne Zeitfenster, Überlaufannahmen und Erfassungszustand war ein Wert keine vollständige Geschichte.

Wurde die administrative Statistik auf inactive gesetzt, verschwanden alle Statistikzeilen. Die Sitzungen mussten dabei nicht enden. Eine leere Tabelle konnte abgeschaltete Messung statt fehlender Aktivität bedeuten.

Auch die Historie war selektiv: ungewöhnlich beendete Sitzungen und fehlerhaft beendete Konversationen. Anzahl und Dauer der Aufbewahrung waren implementierungsabhängig. Leere Historie bewies weder Untätigkeit noch lückenlose Bewahrung vergangener Fehler.

RFC 1666 ordnet die MIB in das SNA-Management ein. Eine solche Abstammung ist kein Nachweis für Betrieb. Ein Standard definiert Objekte, ohne Installation, Aktivierung, Schutz oder korrekte Auslegung zu belegen.

Der formale Status verlangt dieselbe Genauigkeit. IETF Datatracker und RFC-Editor-Info führen RFC 2051 als Proposed Standard auf dem Standards Track vom Oktober 1996. Im eingefrorenen Statusänderungsindex steht er nicht; ein aktualisierender oder ablösender RFC ist nicht angegeben. Der Text ist alt und behandelt Legacy-Technik, doch offiziell ist Historic nicht belegt.

Die Errata-Abfrage ergab keinen Treffer. Das verringert eine dokumentarische Unsicherheit, zertifiziert aber keine Implementierung, Interoperabilität oder heutige Eignung.

Sicherheitsfragen werden laut RFC nicht behandelt. Standards Track belegt daher weder Zugriffskontrolle noch sichere Schreibzugriffe oder verlässliche Zähler. Eine operative Sitzung kann unsicher sein.

Jeder Zeuge hat eine begrenzte Zuständigkeit: Admin für dargestellte Konfiguration, Control für die Anforderung, Agent für den Übergang, CNOS Oper für das Aushandlungsergebnis, Sitzung für die aktive Beziehung, Konversation für eine Interaktion, Statistik für ein Messfenster und Historie für ausgewählte Fehlerenden. Gegenstelle und Anwendung müssen den Rest belegen.

Quellen