Summary

  • RFC 1445 gave every SNMPv2 party a configured transport domain and address, and used that local record when originating a new request.
  • A response followed a different rule: it went to the domain and address from which the corresponding request arrived, even when those coordinates contradicted the party database.
  • The observed return path did not become identity or authority. Source party, destination party, authentication, context, access policy, operation result and durable configuration remained separate decisions and records.

One party had more than an address

RFC 1445 called a party a virtual execution environment. It had one unique identity, one logical network location, one authentication protocol, one privacy protocol and an administratively restricted set of operations. The location itself was split into a transport domain and transport addressing information.

That separation prevented a convenient shortcut. An address could say where to deliver a message over UDP or another transport. It did not say which party was acting, which cryptographic rule applied, which management context was intended or which objects that party could touch.

Every SNMPv2 entity kept local databases for known parties, managed resources and access policy. Those records made a new exchange possible. They were also records, not self-proving measurements of the network at every instant.

The RFC Editor record now classifies the model as Historic. Its party framework is not a current deployment recommendation. The procedural distinction it exposed remains useful because it concerns how a system chooses between configuration and evidence when the two diverge.

A fresh request trusted the catalogue

When an entity generated a request, it named the originating party, receiving party, context and operation. It consulted the local party database for the authentication information associated with both sides and for the receiving party’s privacy protocol. After constructing and serializing the message, it transmitted to the transport domain and address recorded for the receiver.

This is the ordinary purpose of configuration. Before any packet has returned, the manager needs a route selected from durable state. The entry is a hypothesis strong enough to begin an exchange.

RFC 1445 explicitly noted that access policy was not applied merely because a request was transmitted. Sending is not authorization at the remote side. A configured destination does not prove that the party is present there. A locally protected packet does not prove that another entity will accept its identity, context or requested operation.

The address book supplied an initial coordinate. It did not collapse the rest of the procedure into that coordinate.

Receipt opened several independent gates

Incoming processing did not treat the source socket as a complete principal. First, the bytes had to decode as the expected private-message wrapper. The named destination party had to exist locally and actually be realized by that entity. The inner destination had to agree with the outer destination.

Then the source party named inside the management communication had to exist in the local database. The receiver evaluated the authentication protocol associated with the parties. It resolved the named context and consulted an access policy that joined target party, subject party, managed resources and permitted communication classes.

Only after those gates could the operation proceed against a local MIB view or through a proxy relationship. Under the historical noAuth configuration, a message was treated as authentic by that chosen protocol. That fact belongs to the 1993 model; it is not cryptographic proof supplied by the packet’s network source.

The order matters. Observed arrival, decoded party claim, configured authentication result, context lookup and ACL decision were related, but none substituted for the others.

The reply trusted the observed journey

Section 3.3 changed one step when generating the response. The source and destination party identities were reversed from the request. The context was retained. The PDU became the result of applying the requested operation.

Then came the exception: transmit the serialized response using the transport address and transport domain from which the corresponding request originated—even if those values differ from the transport information recorded in the local party database.

The live exchange therefore outranked the catalogue for one narrowly bounded act. The response did not reopen destination discovery. It returned through the coordinates attached to the request that caused it.

That choice supported continuity when records and paths had drifted. It also preserved the relation between request and response. The response was not a new unsolicited message to a generic entry. It belonged to an observed exchange.

The exception did not rewrite the record

RFC 1445 did not insert an automatic party-database update into the response procedure. The source tuple controlled delivery of this response; it did not silently become the party’s durable logical location.

This is a crucial limit. A differing tuple might reflect stale configuration, an alternate interface, a proxy boundary, path mobility or another cause. The cited standards do not tell an investigator which explanation is true in a particular deployment. Automatically choosing one would convert a packet observation into an administrative decision.

Nor did a successful return authenticate the source by itself. The party claim and configured authentication remained separate. Returning bytes to an address did not widen the context or ACL. A response PDU did not prove that a Set survived restart or that the intended network effect followed.

Running code was allowed to answer the packet it had actually seen. It was not allowed, by that fact alone, to redefine the catalogue, principal or policy.

The writable tables held a different kind of power

The companion RFC 1447 Party MIB exposed party, context, access-control and view tables. Its own warning was blunt: full access to all four gave a manager the equivalent of root authority, because it could configure parties with any capabilities.

That is why an observed return coordinate could not casually become a configuration write. Changing a party address was not clerical tidying. In this model, location sat beside authentication, privacy, context and privileges. The authority to alter those durable joins was a control-plane privilege.

A lesser manager could be permitted to maintain its own parties without gaining the power to enlarge or reduce their capabilities. The design separated reachability maintenance from policy authority, even though both appeared in related tables.

Later SNMP kept response state explicit

The party model did not survive as SNMP’s final administrative architecture. RFC 3411 later separated dispatcher, message processing, security, access control, applications and transport mappings into explicit subsystems.

RFC 3412 carried a stateReference out of incoming-message processing for a possible response. Response preparation used that state to produce a destination transport domain and address, and the dispatcher sent the message to the request originator. For SNMPv3, the cached state included the transport domain and address and did not allow ordinary response code to override the cached values.

The vocabulary changed, but the evidence pattern remained recognizable. A confirmed exchange needs state belonging to that exchange. Reconstructing a response only from a general inventory can lose the path, security parameters and correlation that made the request valid.

This lineage should not be read as proof that every implementation obeyed every procedure or that the 1993 model caused the later one. It shows that reply state remained architecturally distinct from a durable destination catalogue.

Sources