Zusammenfassung

  • RFC 1316 modelliert physische und virtuelle Zeichenports sowie die eine oder mehreren Sitzungen, die ein Port tragen kann, als verschiedene verwaltete Objekte.
  • Administrative Portvorgabe und operativer Portzustand beantworten unterschiedliche Fragen; Portgesamtzähler und Sitzungszähler haben ebenfalls unterschiedliche Reichweite.
  • Ein execute bei reset oder kill ist eine definierte Steueranforderung, nicht der Nachweis von Identität, Inhalt, Empfang, Fernwirkung oder Anwendungsergebnis.

Der Anschluss war nicht die ganze Beziehung

Der Character MIB erfasste Hardware-Terminalports mit RS-232 ebenso wie virtuelle Konsolenports ohne physischen Stecker. Ein physischer Port entsprach einem Hardwareport eins zu eins; ein virtueller Port war ein vergleichbares Softwareobjekt ohne solchen Anschluss. Damit war klar, auf welche verwaltete Oberfläche sich eine Beobachtung bezog. Der Name und der Index eines Ports blieben jedoch lokale Koordinaten des Agenten, keine globale Identität.

Daneben definierte RFC 1316 die Sitzung. Jeder Port kann eine oder mehrere Sessions tragen. Eine Session ist eine virtuelle Verbindung, die Zeichen zwischen dem Port und einem Partner überträgt, oft auf einem Protokollstapel wie Telnet über TCP. Port und Session sind also verbunden, aber nicht austauschbar. Ein Port mit Aktivität sagt noch nicht, welche Session beteiligt war, welche Zeichen Bedeutung hatten oder was ein Gegenüber daraus machte.

Gewollt war nicht gleich beobachtet

charPortAdminStatus beschreibt den gewünschten Zustand unabhängig von der Flusssteuerung. Enabled erlaubt Zeichen und neue Sessions; disabled erlaubt Zeichen, aber keine neuen Sessions; off erlaubt beides nicht; maintenance kennzeichnet einen vom Normalbetrieb ausgeschlossenen Zustand, etwa für einen Test. Das ist eine lokale Verwaltungsregel.

charPortOperStatus beschreibt den tatsächlichen Betriebszustand: up, down, maintenance, absent oder active. Active bedeutet nach RFC 1316 up mit anwesendem Benutzer, etwa eingeloggt. Auch das ist keine bestätigte Person, keine Authentisierung, keine Berechtigung und kein Protokoll dessen, was geschrieben, angezeigt oder verarbeitet wurde. Es ist eine Zustandsaussage des Agenten über den Port.

Die beiden Werte müssen gemeinsam, aber getrennt gelesen werden. Eine administrative Absicht kann vom Betriebszustand abweichen. Disabled löscht keine frühere Kommunikation. Maintenance dokumentiert keinen erfolgreichen Test. Active ist keine Zusage, dass eine Arbeit abgeschlossen wurde. Wer die Unterschiede speichert, kann später prüfen, ob sich Regel, Portzustand oder eine benachbarte Ebene verändert hat.

Der Portzähler war kein Gesprächsprotokoll

Die Portzähler umfassen ausdrücklich mehr als die Daten einer einzelnen Session. Eingänge enthalten unter anderem Framing, Flusssteuerzeichen wie XON/XOFF, BREAK-Bedingungen, lokal verarbeitete Eingabe und an alle Sessions gesandte Eingabe. Entsprechendes gilt für Ausgänge, einschließlich lokal erzeugter Ausgabe. Ein Zuwachs ist damit eine präzise technische Beobachtung mit weitem Umfang, aber keine Transkription.

Die Zähler einer Session sind als Teilmengen der passenden Portzähler definiert. Das hilft, eine bekannte Session im lokalen Modell einem Gesamtwert zuzuordnen. Es beweist nicht, dass ein Partner die Daten erhielt, verstand oder handelte. Auch der Sessionindex braucht seinen Kontext: Er gilt innerhalb des Ports und kann bei einem anderen Port denselben Wert haben. Ohne Port, Agent und Zeitpunkt kann eine Kennziffer eine erfundene Kontinuität erzeugen.

Connected war keine Erfolgsmeldung

Die Zahl offener Sessions umfasst connecting, connected und disconnecting. charSessState sagt bei connected nur, dass Zeichendaten auf der Netzseite der Session fließen konnten. Das ist weder ein Beleg für ein bestimmtes übermitteltes Zeichen noch für einen erreichbaren Dienst, eine Anzeige beim Menschen oder eine angenommene Anwendungshandlung.

Protokoll, Ursprung der Einrichtung und ein Verweis auf weitere lokale MIB-Informationen können die Korrelation verbessern. Der Ursprung ist lediglich unknown, network oder local. Fehlen weiterführende Daten, darf die connection ID ein Nullobjekt sein. Solche Angaben schließen Lücken nicht mit erfundenen Endpunktidentitäten oder Wirkungen.

Execute schrieb keinen Abschlussbericht

Beim Lesen liefert charPortReset stets ready. Das Schreiben von execute löst einen Reset aus, der Port-Hardware und -Software in einen sauberen Anfangszustand bringen und bestehende Sessions trennen soll. charSessKill arbeitet gleichartig für eine einzelne Session: Lesen ergibt ready, Schreiben von execute verursacht die Terminierung.

Die Definition benennt damit eine echte Steuerfläche. Ein späteres ready ist aber kein Auditbeleg dafür, wer execute schrieb, welche Berechtigung vorlag, welche Sessions damals bestanden, was der Partner sah oder ob Datenverlust, Wiederverbindung oder Wiederherstellung eintrat. Steueranfrage, Akteur, Autorisierungsbeleg, Vorher/Nachher-Zustände und externe Wirkung gehören in getrennte Nachweise.

Ein Vokabular gegen die Überdehnung

RFC 1316 sollte sehr verschiedene Terminals, serielle Anschlüsse und virtuelle Konsolen verwaltbar machen. Sein bleibender Wert liegt auch in dieser Zurückhaltung: Portpolitik, Portzustand, Gesamtmenge, Teilmenge, Sessionzustand und Steuerung sind verschiedene Tatsachen. Ein modernes Dashboard darf sie übersichtlich zeigen, aber nicht zu einem unbelegten Ergebnis verschmelzen.

Quellen und Evidenzgrenzen

Dieser Artikel stützt sich auf RFC 1316, Definitions of Managed Objects for Character Stream Devices (April 1992). Er belegt die Unterscheidung physischer/virtueller Ports, Port/Session, administrativer/operativer Zustände, Gesamt-/Teilmengenzähler, Sessionphasen und reset/kill-Steuerungen. Er belegt keinen realen Port, keine benannte Person, keine Berechtigung, keinen exakten Partner, keinen Inhalt, keine Zustellung, keine Anzeige, kein Anwendungsergebnis und keine konkrete Ausführung eines Befehls.