Summary
- RFC 1227 let local user processes register MIB subtrees behind one network-visible SNMP agent; the agent split requests, selected peers and recombined responses.
- Priority and the “subtree mounting effect” decided which peer was consulted. A visible value therefore reflected a local routing decision, not durable ownership, completeness or truth.
- Multi-peer Set operations used an accept/refuse round followed by an unacknowledged commit-or-rollback message. Agreement to proceed did not itself prove that every process applied the outcome.
One address concealed a local switchboard
RFC 1227, published in May 1991, addressed an awkward fact about early network management. An SNMP agent could read kernel variables and stable files, but a routing daemon or another user process held information that the agent did not own. Copying every service's state into one process would have made the agent a warehouse. SMUX instead made it a broker.
A user process became a SMUX peer. It opened an association to the local SNMP agent, registered one or more MIB subtrees and later received management operations concerning those objects. The network management station continued to speak SNMP to one agent. Behind that endpoint, the agent separated variables by registered subtree, sent peer-specific requests, correlated the replies and constructed the outward response.
The RFC Editor record now classifies the memo as Historic; the Datatracker record preserves its Experimental origin. Neither record proves that a particular host used SMUX. The historical value lies in the composition rule: one administrative voice could be assembled from several local processes without exposing that internal route to the remote manager.
The imported SNMP specification supplied familiar Get, GetNext, Set, response and trap forms. The SMI supplied object names, while the concise MIB conventions shaped the tables by which the agent described peers and mounted trees. SMUX did not replace that public vocabulary. It inserted a delegation layer below it.
Registration was a routing decision, not a title deed
Each subtree registration carried a priority: lower numbers won. Several peers could register the same subtree at different priorities. A request for priority -1 asked for the highest available position, but the agent could assign a worse priority from local configuration. The peer proposed a place; the agent retained policy control.
Only the highest-priority registration was consulted. More surprisingly, the agent had to enforce the “subtree mounting effect.” If one peer registered a narrow object and another later mounted a broader ancestor, requests for the narrow object went to the broader mount. Registrations beneath it were hidden from selection.
That rule made the MIB resemble a mounted namespace. It also set a strict evidence boundary. A returned sysDescr, route entry or counter showed what the winning local route supplied at that time. It did not prove that no other process had registered the same name, that a hidden registration agreed, that the winner was the original producer, or that the value described the physical system correctly.
The agent could prohibit registrations around the SNMP and SMUX subtrees and reject other areas by implementation policy. Namespace admission was therefore not automatic authority. It was a local decision whose result could change when a peer disconnected, a priority changed or a broader subtree appeared.
Get-next required the broker to distrust scope
Delegation did not remove the agent's responsibility for boundaries. RFC 1227 told each peer to behave as though it contained the whole MIB while processing GetNext. The peer might return an object outside the subtree that caused the request. The agent then had to check the result, reject the scope escape and continue with the peer responsible for the succeeding registered subtree.
That check reveals where composition lived. The peer generated a candidate successor; the agent decided whether the candidate belonged in the public walk. A remote sequence of OIDs was not a raw enumeration from one database. It was the outcome of repeated local routing, scope checking and possible blocking calls.
Request IDs were also local correlation tools. If one incoming operation became several peer PDUs, those PDUs shared a request ID that did not have to match the manager's original value. The external request, internal fan-out and external response were related records, not one indivisible event. A useful audit would preserve that mapping rather than infer it from matching numbers that the protocol did not require.
Atomic intention stopped before acknowledged outcome
Set operations made the separation sharper. When a request touched several peers, the agent first asked each participant to accept or refuse without performing the change. Any refusal led the agent to send rollback to all. Unanimous acceptance led it to send commit.
This was a simple two-phase decision, but the last edge was deliberately quiet: peers did not respond to the commit-or-rollback SOutPDU. An noError response in the first round meant “I can accept this proposed operation,” not “I have now changed durable state.” A commit sent by the agent established its decision and dispatch attempt. RFC 1227 supplied no final peer acknowledgement that application completed.
The distinction matters whenever a management record is treated as an outcome. To prove the new state, an operator would need later peer state, a fresh SNMP read, process logs or independent observation. To prove coordinated rollback, the same burden applies. Transaction vocabulary can narrow uncertainty without erasing the final gap.
Even the status tables warned against presence as truth
The SMUX MIB exposed peer and tree tables. Yet invalidating a row did not necessarily remove it; deletion was implementation-specific. A management station had to examine the status object to distinguish a valid, connecting or invalid peer, and likewise for tree registrations.
This is a small but durable lesson. Row existence is an inventory fact, not always a live-state fact. A peer identity OID was described as authoritative within the protocol structure, but the SimpleOpen password could be empty and the memo said security issues were not discussed. Neither an OID nor a surviving row established a person, organization, authorization scope or trustworthy producer.
The TCP mapping used port 199 and relied on BER's self-delimiting encoding rather than another packetization layer. The current IANA service-name and port registry can preserve assignment context. A registered number, like a table row, does not prove a listener, deployment or active protocol.
RFC 1227's switchboard was useful precisely because it separated a stable public interface from changing local owners. Historical analysis should preserve that separation. The agent's answer, the selected registration, the peer's proposed value, the transaction decision and the observed system state belong to different evidence layers.
Sources
- RFC 1227 — SNMP MUX Protocol and MIB
- RFC Editor information record for RFC 1227
- IETF Datatracker record for RFC 1227
- RFC 1157 — Simple Network Management Protocol
- RFC 1155 — Structure and Identification of Management Information
- RFC 1212 — Concise MIB Definitions
- IANA — Service Name and Transport Protocol Port Number Registry
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
