🚀 go-pugleaf

The following message is forwarded for Craig Partridge, who can not post
netnews from his machine:

>  It appears that HEMS consists of a group of variables defined in ASN.1. The
> variables are defined in the standard itself; there is no provision for a
> loadable MIB, or even the concept of a MIB. The variables defined in RFC1024 
> for HEMS are quite extensive, and include considerably more information than
> MIB-I and MIB-II. 
>   The query language for HEMS is extensive, considerably more involved than 
> that of SNMP (and somewhat reminiscent of CMIP). It lacks "the powerful
> get-next" operator; I presume the querying host is expected to know the
> structure of the queried host's data structure. It uses sets and filtering to
> retrieve the desired data.
>
>  So from my persective, SNMP was developed using the query language from SGMP,
> taking some database ideas (ASN.1 notation) from HEMS. Is this correct? Is 
> there anything else of interest about HEMS?

Denny:

    David Waitzman of BBN saw your query and forwarded it to me.

    Your summary is correct in the large, but there are a few subtleties I'd
like to point up.

    (1) HEMS envisioned that vendors would add non-standard variables to
    the MIB and that management stations would have to be able to
    parse those variables.  So ASN.1 was chosen in part because the
    data formats are self-describing.  In addition, a method for
    management stations to get definitions of unknown variables was
    included -- the GET-ATTRIBUTES operator.

    (2) When we designed HEMS, we believed that in the long run, one
    would want to be able to program devices to respond to certain
    types of faults without operator intervention.  So we developed
    a programming language to program devices (with some safeguards,
    like limiting looping capabilities, to ensure that one couldn't
    freeze a box by loading a bad program).  This idea also led us to
    create the notion of write-able MIB variables (which was highly
    controversial -- at the time folks believed one need special
    commands to do anything.  So there would be special CMIP operations
    to "reboot", to "turn off interface 4", etc.  We said that
    allowing one to write to a location should work just fine).
    The program could simply write variables to change behavior.

    Also, the detailed information in events is programmable.  An
    event triggers a program that copies some variables into an
    event message (or the program may actually correct the event
    without intervention by the operator).

    Part of the motivation for making devices programmable was the
    view that in the interests of quick response to problems, one
    doesn't want to waste a lot of time waiting for packets to
    get back and forth across the network, and should put some
    increased intelligence in the device.  SGMP/SNMP took an
    entirely different view and said that in the interests of
    keeping the box simple, we'll wait on the network a lot.

    (3) HEMS lacks the powerful "get next operator" because it allows
    aggregate retrieval of entire sections of the tree.  The idea
    was that a management station could know which section of a
    tree "ought to have" the information needed to trace a problem
    and could thus dump an entire section of the MIB tree in
    one request -- giving a snapshot of the whole subtree
    at a given instant that the operator could then examine
    to locate the problem.  There are also mechanisms to retrieve
    individual pieces of information (ala SNMP).

    (4) In terms of history, you should note that SGMP post-dates
    HEMS.  The SGMP folks had been participating in the HEMS
    activity but got worried that a prototype HEMS implementation
    would not be ready when it was promised and/or would be too
    big and slow.  (They were wrong -- see my paper on implementing
    HEMS in the winter '88 USENIX -- but that's another story).
    So SGMP took both the basic language ideas and the MIB ideas
    from HEMS, including operators.  However to make things simple,
    they took out the tentative security stuff, all the programmability,
    and assumed that management stations would know everything in the MIB
    and didn't have to be told.  SGMP/SNMP also took the view that
    a packet did one operation (SET,GET, etc.) while HEMS said
    a packet contains an arbitrary program to be run or the
    program's result.

    I'm biased, but I think if you ask Marshall Rose or some of
    the other NM folks who weren't aligned with a particular party,
    you'll find that those simplifications were in hindsight
    all mistakes: SNMP has taken a long time to figure out how to
    put security back in; folks are frustrated by the limitations
    of SNMP's ability to configure and manage devices; and the MIB
    space is riddled with vendor extensions that management stations
    have to learn about.  To be fair some of these problems turned out
    to be less acute than the HEMS designers thought they would be.
    MIB compilers make it easier to configure management stations to
    learn new vendor extensions.  The lack of security hasn't completely
    crippled management and network delay is not yet the huge problem
    we foresaw.

Taken in a large context, HEMS is one element of a suite of work in the
late 1980s that argued/showed that it is possible to have device
independent binary languages and data that can be interpretted quite
fast.  These device-independent languages have applications in network
management (e.g HEMS and NICL) but also in distributed systems (REV
and Late-Binding RPC).  My understanding is that there was also work in
this area in the control systems for linear accelerators (some of the
ideas in HEMS were motivated by chats with Van Jacobson about control
systems LBL had developed).

Hope this helps!

Craig

PS: Marshall's description of the network management meeting is correct.
Glenn Trewitt and I stopped working on HEMS not because we didn't believe
in it but rather because because the existence of HEMS was standing in the
way of making a decision between SNMP and CMIP.