Zusammenfassung

  • Eine SNMPv2-Party verband Identität, Transportdomäne und Adresse mit Authentisierung, Privacy, Größenlimit und einem administrativ begrenzten Operationsraum.
  • Neue Requests nutzten den lokalen Zieleintrag; Responses gingen dagegen an Domäne und Adresse des zugehörigen eingegangenen Requests, selbst bei Widerspruch zum Eintrag.
  • Der beobachtete Rückweg änderte weder automatisch das Inventar noch Identität, Kontext, ACL oder den Nachweis einer ausgeführten Wirkung.

Konfiguration setzte den ersten Koordinatenpunkt

RFC 1445 verstand eine Party als virtuelle Ausführungsumgebung. partyTDomain und partyTAddress beschrieben ihren logischen Ort. Einzigartige Identität, Authentisierungs- und Privacy-Protokoll sowie maximale Nachrichtengröße blieben eigene Merkmale.

Eine Entity hielt lokale Datenbanken für Parties, Ressourcen und Zugriffspolitik. Beim Erzeugen eines Requests benannte sie Ursprung, Empfänger, Kontext und Operation, las die Parameter beider Seiten und sandte an den gespeicherten Empfängerort.

Der Eintrag war eine notwendige Anfangshypothese. Er bewies keine gegenwärtige Erreichbarkeit oder Berechtigung. Der RFC-Editor-Eintrag führt das Modell heute als Historic; seine Evidenzgrenze bleibt dennoch präzise.

Die Quelladresse ersetzte keinen Principal

Der Empfänger prüfte zuerst Kodierung und lokale Ziel-Party. Äußeres und inneres Ziel mussten übereinstimmen, die behauptete Quell-Party bekannt sein. Danach folgten das konfigurierte Authentisierungsprotokoll, die Auflösung des Kontexts und eine ACL aus Ziel, Subjekt, Ressourcen und Kommunikationsklasse.

Erst dann durfte die Operation eine lokale MIB View oder eine Proxy-Beziehung erreichen. Die Netzwerkquelle war ein Transportbefund. Auch das historische noAuth verlieh ihr keine kryptographische Identität.

Ankunft, Party-Behauptung, Authentisierung und Autorisierung waren verbundene, aber eigenständige Entscheidungen.

Die Antwort gehörte zum beobachteten Austausch

Abschnitt 3.3 vertauschte Source und Destination Party, übernahm den Kontext und setzte das Operationsergebnis ein. Beim Senden galt jedoch eine Ausnahme: Die Response verwendete Transportadresse und -domäne, aus denen der entsprechende Request gekommen war, auch wenn die Party-Datenbank andere Informationen enthielt.

Für diesen einen Vorgang überstimmte Running Code den Katalog. Eine neue Zielsuche hätte die Response von dem Austausch trennen können, der sie ausgelöst hatte.

Die Ausnahme sagte nicht, dass jede Beobachtung richtiger als Konfiguration sei. Sie band Autorität an einen Zweck: diesen Reply zurückzuschicken.

Der Datensatz wurde nicht still überschrieben

Die Response-Prozedur enthielt keine automatische Aktualisierung der Party-Datenbank. Hinter der Differenz konnten veraltete Daten, ein anderes Interface, ein Vermittler oder eine weitere Ursache stehen. Die Quellen bestimmen keinen Grund für eine konkrete Installation.

Ein gesendeter Reply beweist nicht den Empfang. Empfang beweist keine Inventarkorrektur. Eine positive Set-Response beweist weder Persistenz nach Neustart noch den beabsichtigten Netzeffekt.

Zwei Werte mit Zeit und Provenienz waren daher wahrheitsnäher als ein unkommentierter Ersatz. Konfiguration war eine administrative Festlegung, die Quelle eine kurzlebige Beobachtung.

Schreibzugriff auf die Tabellen war Macht

Die Party MIB aus RFC 1447 stellte Party-, Kontext-, ACL- und View-Tabellen bereit. Vollzugriff auf alle vier entsprach laut Warnung Root-Rechten, weil sich Parties mit beliebigen Fähigkeiten konfigurieren ließen.

Eine Adresse zu ändern war kein neutrales Aufräumen. Der Ort gehörte zu derselben Verwaltungsbeziehung wie Sicherheit und Privilegien. Ein kleinerer Manager konnte eigene Parties pflegen, ohne ihre Fähigkeiten erweitern zu dürfen.

Automatische Rückwegkontinuität und dauerhafte Änderungshoheit blieben getrennt.

Spätere Architektur bewahrte Request-Zustand

RFC 3411 trennte Dispatch, Message Processing, Security, Access Control, Anwendungen und Transport. RFC 3412 erzeugte aus einem eingegangenen Request eine stateReference für eine mögliche Antwort.

Diese lieferte Ziel-Transportdomäne und -adresse an den Dispatcher, der zum Originator antwortete. Im SNMPv3-Zustand wurden Transportkoordinaten mitgeführt. Ein Reply hing damit weiter an seinem konkreten Austausch und nicht nur am allgemeinen Adresskatalog.

Das belegt weder universelle Implementierung noch eine heutige Party-Deploymentform. Es zeigt die fortgesetzte Trennung von Gesprächszustand und persistentem Inventar.

Quellen