HEMS monitoring and control language
RFC 1023

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

Network Working Group                                          G. Trewitt
Request for Comments: 1023                                       Stanford
                                                             C. Partridge
                                                                 BBN/NNSC
                                                             October 1987

                  HEMS Monitoring and Control Language

   This RFC specifies the design of a general-purpose, yet efficient,
   monitoring and control language for managing network entities.  The
   data in the entity is modeled as a hierarchy and specific items are
   named by giving the path from the root of the tree.  Most items are
   read-only, but some can be "set" in order to perform control
   operations.  Both requests and responses are represented using the
   ISO ASN.1 data encoding rules.

STATUS OF THIS MEMO

   The purpose of this RFC is provide a specification for monitoring and
   control of network entities in the Internet.  This is an experimental
   specification and is intended for use in testing the ideas presented
   here.  No proposals in this memo are intended as standards for the
   Internet at this time.  After sufficient experimentation and
   discussion, this RFC will be redrafted, perhaps as a standard.
   Distribution of this memo is unlimited.

   This language is a component of the High-Level Entity Monitoring
   System (HEMS) described in RFC-1021 and RFC-1022.  Readers may want
   to consult these RFCs when reading this memo.  RFC-1024 contains
   detailed assignments of numbers and structures used in this system.
   This memo assumes a knowledge of the ISO data encoding standard,
   ASN.1.

OVERVIEW AND SCOPE

   The basic model of monitoring and control used in this proposal is
   that a query is sent to a monitored entity and the entity sends back
   a response.  The term query is used in the database sense -- it may
   request information, modify things, or both.  We will use gateway-
   oriented examples, but it should be understood that this query-
   response mechanism can be applied to other entities besides just
   gateways.

   In particular, there is no notion of an interactive "conversation" as
   in SMTP [RFC-821] or FTP [RFC-959].  A query is a complete request
   that stands on its own and elicits a complete response.

Trewitt & Partridge                                             [Page 1]
RFC 1023                     HEMS Language                  October 1987

   It is not necessary for a monitored entity to be able to store the
   complete query.  It is quite possible for an implementation to
   process the query on the fly, producing portions of the response
   while the query is still being received.

   Other RFCs associated with HEMS are:  RFC-1021 -- Overview; RFC-1022
   -- transport protocol and message encapsulation; RFC-1024 -- precise
   data definitions.  These issues are not dealt with here.  It is
   assumed that there is some mechanism to transport a sequence of
   octets to a query processor within the monitored entity and that
   there is some mechanism to return a sequence of octets to the entity
   making the query.

ENCODING OF QUERIES AND RESPONSES

   Both queries and responses are encoded using the representation
   defined in ISO Standard ASN.1 (Abstract Syntax Notation 1).  ASN.1
   represents data as sequences of <tag,length,contents> triples that
   are encoded as a stream of octets.  The data tuples may be
   recursively nested to represent structured data such as arrays or
   records.  For a full description of this notation, see the ISO
   documents IS 8824 and IS 8825.  See the end of this memo for
   information about ordering these documents.

NOTATION USED IN THIS PROPOSAL

   The notation used in this memo is similar to that used in ASN.1, but
   less formal, smaller, and (hopefully) easier to read.  The most
   important difference is that, in this memo, we are not concerned with
   the length of the data items.

   ASN.1 data items may be either a "simple type" such as integer or
   octet string or a "structured type", a collection of data items.  The
   notation or a "structured type", a collection of data items.  The
   notation:
        ID(value)
   represents a simple data item whose tag is "ID" with the given value.
   A structured data item is represented as:
        ID { ... contents ... }
   where contents is a sequence of data items.  Remember that the
   contents may include both simple and structured types, so the
   structure is fully recursive.

   There are situations where it is desirable to specify a type but give
   no value, such as when there is no meaningful value for a particular
   measured parameter or when the entire contents of a structured type
   is being specified.  In this situation, the same notation is used,

Trewitt & Partridge                                             [Page 2]
RFC 1023                     HEMS Language                  October 1987