Summary

  • RFC 1052 selected SNMP as the Internet's short-term management basis and recorded Craig Partridge's recommendation that HEMS withdraw from consideration. The same decision named HEMS RFC 1024 as an input to the common MIB effort.
  • RFC 1076, published after that withdrawal, preserved HEMS's alternative execution model: a small streaming interpreter could walk a hierarchical data tree, filter changing tables, and return represented values after reads or permitted modifications.
  • The protocol decision, reused information definitions, authorization to issue a query, the agent's returned tree and the device's observed effect were separate facts. HEMS did not secretly become SNMP, and a successful-looking reply did not prove traffic outcome.

A protocol could leave without taking every idea with it

By 1987, network management had become a coordination problem. RFC 1021 described an Internet growing in size and vendor variety. When a few manufacturers supplied most critical gateways, an experienced administrator could learn their private tools. That strategy stopped scaling as devices, networks and implementations multiplied.

The High-Level Entity Management System, or HEMS, tried to create a common language for that heterogeneous world. It divided work among a small query processor on each manageable entity, an event generator for unsolicited notices, and more intelligent applications at management centres. The processor exposed a standard data view; the application decided what to ask and how to interpret the answer.

HEMS also separated monitoring from control. Monitoring collected facts about behaviour. Control tried to alter behaviour in real time. RFC 1021 made the dependency explicit: changing a network without observing the effect was not useful. It therefore concentrated the initial design on monitoring, while acknowledging that generic control functions and strong access-control mechanisms were not yet complete.

That caution matters because the history did not proceed as a simple contest in which the most expressive protocol won. In March 1988, the Internet Activities Board reviewed HEMS, SNMP and the ISO-oriented CMIP/CMIS approach. RFC 1052 recommended SNMP as the short-term basis. Its reason was operational: software was available and in use, and the community needed convergence quickly.

The same record says that Craig Partridge recommended withdrawing HEMS from consideration so an Internet-wide agreement could form. Withdrawal was an act inside the selection process, not evidence that every HEMS idea was defective. RFC 1052 immediately made the distinction. It praised HEMS's monitored-element work as thorough and widely discussed, and told the new MIB working group to take the definitions in RFC 1024 as one starting input alongside SNMP and CMIP/CMIS material.

The protocol left the race. Its information work stayed in the room.

RFC 1076 documented the road not selected

The timing of RFC 1076 prevents an easy winner-and-loser story. It appeared in November 1988, seven months after RFC 1052, and superseded RFC 1023. The authors did not present a new Internet-wide selection. They completed a more detailed description of the experimental HEMS monitoring and control language.

That language was richer than a single remote procedure. A HEMS request could contain multiple instructions, a performance choice already explained in RFC 1021. The managed entity did not need to store the whole request. It could consume ASN.1 objects as they arrived, push data objects onto a bounded stack, execute an operation code immediately, and begin producing parts of the reply while later instructions were still in flight.

The design assigned work carefully. The agent understood only eight executable operations: BEGIN, END, GET, GET-ATTRIBUTES, GET-RANGE, SET, CREATE and DELETE. There were no stored programs, subroutines or explicit control structures. Expressiveness came from composing these few operations with paths, templates, values and filters.

The manageable world appeared as a tree. Internal dictionaries grouped related information; paths named nodes from a known root; leaves contained values. A query moved a cursor through that hierarchy. As the processor visited a branch, it reproduced that fully qualified structure in the response. The result was not an informal printout. It was an encoded image of the part of the management tree traversed by the query.

This division pursued a demanding combination: keep the software on a critical gateway small, but let a remote application ask a selective, compound question. Complexity was not abolished. It was moved into the request author, the data definitions and the evidence needed to interpret the reply.

Filters chose changing objects by meaning, not by position

Large tables made positional indexes fragile. An interface numbered third before a reboot might not remain third afterward. Routing tables and TCP connection tables could change while an operator was forming a query. RFC 1076 therefore let filters select array entries by the values inside them.

A filter could ask whether an item was present, compare it for equality or against upper and lower bounds, and combine tests with AND, OR and NOT. A filtered GET could request counters only for the interface holding a named IP address. A filtered SET could modify every matching entry. A filtered BEGIN could descend into a matching dictionary and then operate on a table below it.

The convenience had a declared ambiguity. If several dictionaries matched a filtered BEGIN, the processor could choose any match; the specification said experience was needed to decide whether multiplicity should instead be an error. A syntactically valid filter therefore did not necessarily identify one stable object. Operators still needed a uniqueness assumption and evidence that it held.

RFC 1076 also allowed GET-RANGE to retrieve a portion of an OctetString, including a machine-dependent representation of memory. Yet memory was deliberately omitted from a whole-dictionary GET. General discovery was not permission to dump every sensitive or expensive object. The data view encoded policy choices about what broad retrieval meant.

A reply mirrored represented state, not the whole machine

The most revealing HEMS rule concerned modification. SET and CREATE returned the affected part of the tree after the operation. DELETE normally returned nothing, while an item that matched but could not be deleted might be returned. If an application tried to SET a non-settable item, the processor did not necessarily emit an error. It returned the current value, which the application could compare with the requested value.

For ordinary stored configuration, that post-operation image could be useful evidence. Control functions were harder. RFC 1076 proposed a “virtual command-and-status register”: assigning a command code to a tree item could trigger an arbitrary implementation-defined side effect, such as bringing an interface down or up. Reading the item might return current status.

The word “might” preserves the boundary. A reply containing the requested value establishes what the HEMS data-tree interface represented after processing. It does not independently establish that the physical interface stopped carrying frames, that routes converged, that peers noticed the change, that the state survived a restart, or that traffic followed the intended alternative.

This is not a defect unique to an old protocol. It is the difference between command-plane evidence and outcome evidence. A management system can report its own accepted representation accurately while the controlled subsystem is delayed, partly changed, immediately overwritten or observable only from another surface.

Authorization was outside the language, and absence became ambiguous

RFC 1022 defined the HEMP envelope around queries, replies, events and errors. It reserved places for authentication and encryption information and separated protocol errors from application errors. But an available envelope field did not prove that a particular request was authenticated or encrypted; the 1987 specification assigned no encryption types.

RFC 1076 deliberately left the authorization system open. A query ran with a level or capability set supplied by its HEMS environment, and each data item applied a local test. The language itself had no login or permission operation. Retrieval and modification could be restricted, but navigation through dictionaries could not be hidden if doing so would make BEGIN fail and terminate the entire query.

That choice created a useful but consequential ambiguity. A GET for a tag that was undefined, unimplemented or unauthorized returned the same zero-length no-value object. Generic queries could run against unlike devices without dying on every optional field. The price was that the reply alone could not distinguish three different causes of silence.

Errors that did terminate processing were made conspicuous. An error identified its kind, implementation instance, byte offset, operation and printable description. If the processor had already opened several nested ASN.1 reply objects, it inserted a copy of the error at every unfinished level and once more at the end. Because output could begin before input ended, failure evidence had to close the structure already on the wire.

The response was therefore a ledger of processing, not a timeless snapshot. Some values might have been emitted before a later instruction failed. Nested closure told a decoder where interpretation stopped; it did not roll back earlier side effects.

The selected protocol was simpler; the inheritance claim must stay narrow

By August 1989, RFC 1109 reported SNMP implementations in several networks, from vendors and public reference efforts. It also recorded continuing gaps in scaling, configuration management, user access control and command authentication. Selection solved the immediate coordination problem; it did not finish network management.

The later RFC 1155 described the standardized Structure of Management Information: hierarchical OBJECT IDENTIFIER names, restricted ASN.1 types and a virtual information store. RFC 1157 specified SNMP with a deliberately smaller Get, GetNext, Set and Trap surface and recorded the SMI, MIB and SNMP framework as the recommended operational architecture.

It is tempting to draw a straight arrow from the HEMS tree to every later OID. The sources do not support that. RFC 1052 proves one institutional link: RFC 1024 was an explicit starting input for the MIB group. Similar hierarchy and ASN.1 choices show that the designs inhabited the same problem space. They do not establish that every later object, operation or encoding descended from RFC 1076.

The more defensible history is also more interesting. The community separated the need to choose one deployable protocol from the need to preserve useful semantic work. HEMS could withdraw as a common-protocol candidate while its object definitions remained evidence for another working group. RFC 1076 could document an alternate query model without reversing the selection.

Sources and limits

RFC 1021 supplies the experimental system scope; RFC 1022 the message envelope; RFC 1024 the object-definition work named as input; RFC 1052 the selection and withdrawal decision; RFC 1076 the query language; RFC 1109 the operational follow-up; RFC 1155 the later SMI structure; and RFC 1157 the later SNMP framework. They do not provide a deployment census for HEMS, packet captures of RFC 1076, a complete field-by-field migration map or proof of a particular device effect.

The conclusion should remain exact. HEMS did not win the common protocol selection. Its information work was not automatically erased. RFC 1076 shows a coherent management language whose replies carefully describe represented tree state. History must keep those three propositions separate.