Summary

  • RFC 1447 indexed each access row by target party, subject party and resource context, then stored the permitted PDU classes separately.
  • Authentication and a known party name were inputs to a receive-side decision; neither supplied portable permission to read, write or notify everywhere.
  • Later VACM changed the vocabulary but retained the relational discipline: principal, context, security conditions, view type and individual object all mattered.

Four drawers before the instrument

The Party MIB appeared in April 1993 as one component of the original SNMPv2 framework. Its name can make it sound like a directory of principals. It was more ambitious. It exposed the administrative facts that an SNMPv2 entity used to decide how a management communication could be processed: parties, contexts, access privileges and MIB views.

RFC 1445 defined a party as a conceptual execution environment whose operations were limited to an administratively chosen subset of the entity's possibilities. A party was therefore not simply a human, a company or an address. The same entity could realise several parties with overlapping or disjoint authority. A remote party could be known locally without being realised locally. The name selected an administrative record; it did not carry a universal role.

RFC 1447 made that restraint concrete in aclTable. One row did not have “user” as its only key. Its index consisted of aclTarget, aclSubject and aclResources. The target identified the party asked to perform an operation. The subject identified the party requesting it. The resources value identified the SNMPv2 context against which the request was made.

Only after that triple selected a row did aclPrivileges say which management communication classes were permitted. Authority was a sentence with a subject, a receiver, an object world and a verb class. Remove one term and the sentence changed.

Thirty-five was not an administrator role

The privilege field was an integer from zero through 255, but it was not a rank. Each PDU class occupied a value derived from its context-specific tag: Get was 1, GetNext 2, Response 4, Set 8, GetBulk 32, Inform 64 and SNMPv2-Trap 128. A permitted set was represented by addition. Zero meant no permitted class.

The default value was 35: Get plus GetNext plus GetBulk. It did not sit halfway up a ladder from guest to administrator. It named three read-side message classes and omitted Set, Response, Inform and Trap. Forty-three added Set to the same retrieval set. Four meant Response alone. The number had meaning only after decomposition.

That design matters whenever compact policy becomes dashboard prose. If 35 is rendered as “read access,” the summary may be useful, but the underlying evidence is still the exact bit set. If it is rendered as “trusted,” the summary has crossed a boundary. Trust does not reveal the target, context, request direction or allowed operation.

The initial configuration examples made the asymmetry visible. A manager-side subject could be allowed to issue Get, GetNext and GetBulk toward an agent-side target in one context, while the reverse row permitted Response and Trap. The corresponding directions were different policies. Permission to ask did not automatically grant permission to answer, and neither row authorised a Set unless its class was present.

Sending did not run the receiver's policy

RFC 1445 stated an easily lost timing rule: access control was applied when a management communication was received, not when it was transmitted. The request generator assembled a source party, destination party, context and PDU and sent the message without consulting the remote entity's local access policy.

On receipt, the path became sequential. The receiver checked that the destination party was known and locally realised. It looked up the originating party. It evaluated authentication under the parties' configured protocols. It looked up the context. It then consulted the local access-policy database for the origin–destination–context relation and determined the PDU class.

These were not decorative repetitions. Each lookup could fail for a different reason. A syntactically valid message could name an unknown destination. A known destination could receive a message from an unknown source. An authentic source could request an absent context. A known context could lack the relevant ACL row. A matching row could omit Set.

The decision was local in a strong sense. Two receivers could know the same subject identifier yet maintain different target parties, contexts, rows and MIB views. A sender could know what it intended to request, but it could not manufacture the receiver's current authorisation simply by transmitting a well-formed packet.

Context kept “what” apart from “who”

An SNMPv2 context identified a collection of managed-object resources. For local resources it pointed to a MIB view; for remote resources it could describe a proxy relationship. The same subject and target could therefore have different privileges for different contexts, and the same operation name could reach different resource surfaces.

That separation prevented a principal label from silently swallowing scope. “May read” was incomplete without “which context,” just as “may set” was incomplete without the receiving party and PDU class. Even after the access row admitted a request, the context's view still bounded the objects on which the operation could run.

This also limited what a denial proved. Failure to reach an object through one context did not prove that the object did not exist, that another context excluded it, or that another subject lacked access. It established the result of one relation at one receiver under one administrative state.

The policy row had a life of its own

The ACL entry also carried aclStorageType and aclStatus. Storage could be volatile, non-volatile or permanent. Status used RowStatus. The policy was therefore not timeless merely because it appeared in a table. A row could depend on volatile memory, be backed by stable storage, resist modification, or be unready or inactive under its lifecycle rules.

RFC 1447 did not promise that reading a row proved that every dependency was active, that concurrent administrators had not raced, or that a successful Set would survive a restart. Those questions belonged to the row state, storage realisation, response and later observation. The generic RowStatus mechanism has its own history; here its importance is narrower. The access relation itself was managed state.

That creates a recursion worth preserving rather than hiding. Management traffic could change the administrative facts that governed later management traffic. A successful write to a policy object was not evidence that a future request would be admitted under the intended relation. The operator needed the written values, returned status, active dependencies and a new receive-side test.

VACM changed the map, not the need for coordinates

The original party-based framework did not endure. RFC 2575 and its later replacement RFC 3415 defined the View-based Access Control Model for the modular SNMP architecture. The representation changed: a security model and security name mapped to a group; group, context name, security model and security level selected an access entry; read, write or notify selected a view; the individual variable name was then tested against that view.

VACM even named failures at different joins: no such context, no group name, no access entry, no such view and not in view. Those outcomes did not all mean “bad credentials.” They located missing or excluding state in different parts of the decision.

The lineage is not equivalence. Party MIB ACL rows and VACM tables are different systems with different architecture. What survived was the refusal to equate a principal with unrestricted authority. The answer to “who?” remained only one input. “Where?”, “under what security model and level?”, “for which operation?” and “for which object?” still constrained the result.

A policy fact was not an operational effect

Lu Heng's running-code principle separates specification, implementation, validation, deployment and use. His account of reality layers distinguishes symbolic authority from executable effect. RFC 1447 offers a small historical instance of both ideas.

The party identifier belonged to the symbolic layer. The ACL row expressed local policy. Receive-side processing executed that policy. A protocol response recorded one outcome. A changed counter, interface state or routing behaviour belonged to another observation again.

None of those records is worthless. The error begins when one is promoted to represent all the others. A known party does not prove authorisation. A matching ACL row does not prove it was active. An admitted Set does not prove a durable change. A returned value does not prove semantic correctness.

The Party MIB's administrative model is Historic. Its evidence discipline is not. Authority is easier to audit when it remains a relation that can be reconstructed, rather than a flattering adjective attached to an identity.

Sources