RFC 1024 (rfc1024) - Page 3 of 74

HEMS variable definitions

RFC 1024                    HEMS Definitions                October 1987


   This memo defines a universal type space.  A subset of this type
   space is expected to be an appropriate type space for any entity
   (e.g., a gateway or a multi-user host).  The type space is divided
   into required and optional portions.  Implementors should implement
   the required portion of the type space plus that part of the optional
   type space which is appropriate for their particular entity.

   One problem with defining a universal type space is that certain
   interesting objects are not universal, but are instead very machine
   specific (for example, status registers on specialized hardware).  To
   allow implementors to retrieve such implementation-specific objects
   using the HEMS system, a special APPLICATION type is reserved for
   non-standard values.

   Putting objects in ASN.1 form implies an ability to map to and from
   ASN.1 format.  One of the design goals of this system has been to
   minimize the amount of ASN.1 compilation required by the query
   processor to reduce the expense of processing queries at entities.
   (This implies a certain willingness to force the applications
   querying entities to be more powerful).  We expect that most of the
   complex mapping will be done when objects are read; most writable
   objects have a simple format (e.g., an INTEGER, or OCTETSTRING).  As
   a result, we have made a heavy use of the ASN.1 SET type, which
   allows values to be presented in any order.  Applications which
   require particular fields in an object may use the template structure
   to specify particular fields to be retrieved, but this still permits
   the query processor to return the fields in whatever order is
   convenient.

   In addition to ease the problems of ASN.1 compilation, query
   processors are not required to reduce an INTEGER to the minimum
   number of octets as specified in ASN.1.  Applications should be
   prepared to receive INTEGERs which have leading octets with all zeros
   or ones.

   More generally, a design goal of HEMS was to try to limit the data
   processing done at the entity, and to place the burden of data
   reduction on the querying application.  As a result, the objects
   presented here are typically counters, or values which the entity has
   to compute already.  Object definitions which require the entity to
   do data reduction are not supported, although consideration might be
   given to making them optionally available.

   Finally, HEMS is required to support access by multiple network
   management centers or applications.  This constraint has some
   important consequences.  First, the SET operation cannot be applied
   to any Counter, since changing the value of a Counter may impair data
   acquisition by other centers.  More generally, there are questions



Partridge & Trewitt