Zusammenfassung

  • RFC 3055 schuf eine serverseitige MIB für vier PINT-Dienste, vier Zeitfenster und globale, client-, nutzer- sowie gatewaybezogene Sichten.
  • „Erfolgreich“ blieb die Klassifikation eines Agenten; sie bewies weder Abheben noch hörbaren Inhalt oder ein lesbares Fax.

Internet bestellt, Telefonnetz führt aus

PINT verband zwei Welten, ohne sie gleichzusetzen. Eine Internetanfrage konnte zwei Parteien anrufen, ein Fax senden, ein Dokument aus dem Telefonnetz zurückfaxen oder Inhalte am Telefon vorlesen lassen. Wesentliche Ausführungsdetails blieben jedoch im PSTN.

Ein Server konnte eine Anfrage annehmen, die das Gateway später ablehnte. Das Gateway konnte übernehmen, ohne die Telefonaktion zu vollenden. Eine aufgebaute Verbindung bewies kein menschliches Hören, und ein beendeter Faxvorgang kein lesbares Blatt.

RFC 3055 erschien im Februar 2001 als Proposed Standard. Die SMIv2-MIB erhielt bei IANA die Modulnummer 93 unter mib-2. Ihr Umfang war bewusst schmal: PINT-spezifische Leistung, nicht Verwaltung der Netzelemente oder allgemeine Host- und Netzleistung. Damit blieb der Standort des Beobachters sichtbar.

Vier Dienste, vier Schnitte

Die Dienste hießen Request-to-Call, Request-to-Fax, Request-to-Fax-Back und Request-to-Hear-Content. Zeiträume waren 30 Sekunden, 15 Minuten, 24 Stunden und die Zeit seit dem Neustart.

Die globale Tabelle zählte Empfang, Erfolg und Abbruch und ordnete Fehler Autorisierung, Server oder Gateway zu. Die Clienttabelle nutzte eine textuelle Adresse, die Nutzertabelle UserIdName, die Gatewaytabelle einen registrierten Namen.

Das waren keine vier unabhängigen Zeugen. Der Agent lief am PINT-Server, auch wenn er Gatewayverbindungen beobachtete. Mehrere Sichten konnten ein Problem eingrenzen, erzeugten aber keine unabhängige Spur im PSTN oder Endgerät.

Wer durfte „Erfolg“ sagen?

Objekte mit SuccessfulCalls klingen endgültig. Die MIB standardisierte aber nur, wie eine Implementierung ihre Klassifikation meldete. Sie stellte keinen Beobachter neben jedes Telefon oder Faxgerät.

Serverannahme, Übergabe ans Gateway, Telefonausführung, physische Ausgabe und nützliches Ergebnis sind getrennte Belege. Ohne dokumentierte Inkrementregel und nachgelagerte Evidenz reicht der Zähler nicht über seine Schicht hinaus. Gerade diese Begrenzung macht ihn belastbar.

Counter32 braucht Kontinuität

Die Werte waren Counter32. SMIv2 beschreibt den Anstieg bis 2^32−1 und den Sprung auf null. Ein einzelner Zählerstand besitzt im Allgemeinen keinen Informationsgehalt.

Eine Summe ist keine Rate. Man braucht Vorher- und Nachherprobe, Zeitstempel und eine glaubwürdige Kontinuität. RFC 3055 übergab dem Verbraucher ausdrücklich die Behandlung des Überlaufs für „seit Neustart“. Neustart, fehlende Abfrage oder nicht ausgerichtete Fenster verändern ein Delta.

Spätere Application-MIB-Arbeit machte Diskontinuitäten deutlicher, beweist sie aber nicht für historische PINT-Agenten.

Fehlende Zeile heißt nicht null

Client- und Nutzertabellen konnten ressourcenintensiv sein. Alterung blieb lokal; eine Top-N-Sicht wurde nur als Möglichkeit genannt. Eine fehlende Zeile konnte Inaktivität, Ablauf, nicht implementierte Details, Ressourcenbegrenzung oder andere Identitätsbildung bedeuten.

UserIdName sollte über relevante Server und Gateways eindeutig sein. Clientkennung und Zeitstempel waren ein möglicher Baustein. Der Schlüssel enthielt somit Identitätspolitik, nicht nur Verkehr.

Schweigen der Alarme

RFC 3055 definierte keine eigenen Notifications. Für wiederholte Authentisierungsfehler oder störende Anrufe verwies es auf RMON-Schwellen. Eine solche Alarmierung hängt von Variable, Intervall, Stichprobentyp, Schwellen und Ereignis ab.

Kein Alarm kann bedeuten, dass nichts die Schwelle überschritt. Es kann ebenso bedeuten, dass nichts konfiguriert war, Daten fehlten oder das Ereignis nicht ankam. Schweigen ist kein Gesundheitsbeleg.

Auch Lesen war sensibel

Nur der Administrationskontakt war schreibbar; read-create gab es nicht. Dennoch konnten Nutzerkennungen, Gatewaybeziehungen, Volumen und Fehler Geschäftsdaten offenlegen. RFC 3055 warnte vor SNMPv1 allein und empfahl USM und VACM. Netzverschlüsselung entscheidet nicht, welcher Principal welches Objekt lesen darf.

RFC 3414 und RFC 3415 ersetzten später die genannten Sicherheitsdokumente. Das ist Kontext, kein Einsatznachweis.

Quellen

Lu Heng hat RFC 3055 weder verfasst noch gebilligt. Seine Texte dienen nur als offengelegte Analyseperspektive. H. Lu aus RFC 2458 wird ohne unabhängigen Identitätsnachweis nicht gleichgesetzt.