rfc1076.txt

RFC 的详细文档！

   it.  Extensive descriptions of standard data are optional, since they
   are defined in RFC-1024.  Complete descriptions of extensions must be
   available, even if they are documented in a user's manual.  Network
   firefighters may not have a current manual handy when the network is
   broken.

   The format of the attributes is not as simple as the format of the
   data itself.  It isn't possible to use the data's tag, since that
   would look exactly like the data itself.  The format is:

       Attributes ::= [APPLICATION 3] IMPLICIT SEQUENCE {
               tagASN1         [0] IMPLICIT INTEGER,



Trewitt & Partridge                                            [Page 16]

RFC 1076          HEMS Monitoring and Control Language     November 1988


               valueFormat     [1] IMPLICIT INTEGER,
               longDesc        [2] IMPLICIT IA5String OPTIONAL,
               shortDesc       [3] IMPLICIT IA5String OPTIONAL,
               unitsDesc       [4] IMPLICIT IA5String OPTIONAL,
               precision       [5] IMPLICIT INTEGER OPTIONAL,
               properties      [6] IMPLICIT BITSTRING OPTIONAL,
               valueSet        [7] IMPLICIT SET OF valueDesc OPTIONAL
               }

   The GET-ATTRIBUTES operator is similar to the GET operator.  The
   major difference is that dictionaries named in the template do not
   elicit data for the entire subtree.

   GET-ATTRIBUTES
                        dict template   GET-ATTRIBUTES   dict
             Emit a single ASN.1 Attributes object for each of the
             objects named in <template>.  For each of these, the
             tagASN1 field will be set to the corresponding tag from the
             template.  The rest of the fields are set as appropriate
             for the data object.  Any items in the template that are
             not in <dictionary> (or its components) elicit an
             Attributes object with a valueFormat of NULL, and no other
             descriptive information.

   or
                                 dict   GET-ATTRIBUTES   dict
             If there is no template, emit Attribute objects for all of
             the items in the dictionary.  This is equivalent to
             providing a template that lists all of the items in the
             dictionary.  This allows a complete list of a dictionary's
             contents to be obtained.

   An additional form of GET-ATTRIBUTES, which takes a filter argument,
   is described later.

   Here is an example of using the GET-ATTRIBUTES operator to request
   attributes for three objects in the System dictionary:

       System{ name, badtag, clock-msec } GET-ATTRIBUTES

   "badtag" is some unknown tag.  The result might be:

       System{
               Attributes{
                       tagASN1(name),
                       valueFormat(IA5String),
                       longDesc("The primary hostname."),




Trewitt & Partridge                                            [Page 17]

RFC 1076          HEMS Monitoring and Control Language     November 1988


                       shortDesc("hostname")
               },
               Attributes{
                       tagASN1(badtag), valueFormat(NULL)
               }
               Attributes{
                       tagASN1(clock-msec),
                       valueFormat(Integer),
                       longDesc("milliseconds since boot"),
                       shortDesc("uptime"), unitsDesc("ms")
                       precision(4294967296),
                       properties(1)
               }

   Note that in this example "name" and "clock-msec" are integer values
   for the ASN.1 tags for the two data items.  "badtag" is an integer
   value that has no corresponding name in this context.

   There will always be exactly as many Attributes items in the result
   as there are objects in the template.  Attributes objects for items
   which do not exist in the entity will have a valueFormat of NULL and
   none of the optional elements will appear.

       [ A much cleaner method would be to store the attributes as
       sub-components of the data item of interest.  For example,
       requesting
           System{ clock-msec }  GET
       would normally just get the value of the data.  Asking for an
       additional layer down the tree would now get its attributes:
           System{ clock-msec{ shortDesc, unitsDesc }  GET
       would get the named attributes.  (The attributes would be
       named with application-specific tags.)  Unfortunately, ASN.1
       doesn't provide a notation to describe this type of
       organization.  So, we're stuck with the GET-ATTRIBUTES
       operator.  However, if a cleaner organization were possible,
       this decision would have been made differently. ]

8.4 Examining Memory

   Even with the ability to symbolically access all of this information
   in an entity, there will still be times when it is necessary to get
   to very low levels and examine memory, as in remote debugging
   operations.  The building blocks outlined so far can easily be
   extended to allow memory to be examined.

   Memory is modeled as an ordinary object in the data tree, with an
   ASN.1 representation of OctetString.  Because of the variety of
   addressing architectures in existence, the conversion from the



Trewitt & Partridge                                            [Page 18]

RFC 1076          HEMS Monitoring and Control Language     November 1988


   internal memory model to OctetString is very machine-dependent.  The
   only simple case is for byte-addressed machines with 8 bits per byte.

   Each address space in an entity is represented by one "memory" data
   item.  In a one-address-space situation, this dictionary will
   probably be in "System" dictionary.  If each process has its own
   address space, then one "memory" item might exist for each process.
   Again, this is very machine-dependent.

   Although the GET-RANGE operator is provided primarily for the purpose
   of retrieving the contents of memory, it can be used on any object
   whose base type is OctetString.

   GET-RANGE   dict path start length   GET-RANGE   dict
             Get <length> elements of the OctetString, starting at
             <start>.  <start> and <length> are both ASN.1 INTEGER type.
             <path>, starting from <dict>, must specify a node
             representing memory, or some other OctetString.

   The returned data may not be <length> octets long, since it may take
   more than one octet to represent one memory location.

   Memory items in the data tree are special in that they will not
   automatically be returned when the entire contents of a dictionary
   are requested.  e.g., If memory is part of the "System" dictionary,
   then the query
       System GET
   will emit the entire contents of the System dictionary, but not the
   memory item.

8.5 Control Operations:  Modifying the Data Tree

   All of the operators defined so far only allow data in an entity to
   be retrieved.  By replacing the template argument used in the GET
   operators with a value, data in the entity can be changed.  Very few
   items in the data tree can be changed; those that can are noted in
   RFC-1024.

   Values in the data tree can modified in order to change configuration
   parameters, patch routing tables, etc.  Control functions, such as
   bringing an interface "down" or "up", do not usually map directly to
   changing a value.  In such cases, an item in the tree can be defined
   to have arbitrary side-effects when a value is assigned to it.
   Control operations then consist of "setting" this item to an
   appropriate command code.  Reading the value of such an item might
   return the current status.  Again, details of such data tree items
   are given in RFC-1024.




Trewitt & Partridge                                            [Page 19]

RFC 1076          HEMS Monitoring and Control Language     November 1988


   This "virtual command-and-status register" model is very powerful,
   and can be extended by an implementation to provide whatever controls
   are needed.  It has the advantage that the control function is
   associated with the controlled object in the data tree.  In addition,
   no additional language features are required to support control
   functions, and the same operations used to locate data for retrieval
   are used to describe what is being controlled.

   For all of the control and data modification operations, the fill-
   in-the-blank model used for data retrieval is extended: the response
   to an operation is the affected part of the data tree, after the
   operation has been executed.  Therefore, for normal execution, SET
   and CREATE will return the object given as an argument, and DELETE
   will return nothing (because the affected portion was deleted).

   SET                     dict value   SET   dict
             Set the value(s) of data in the entity to the value(s)
             given in <value>.  The result will be the value of the data
             after the SET.  Attempting to set a non-settable item will
             not produce an error, but will yield a result in the reply
             different from what was sent.

   CREATE                 array value   CREATE   dict
             Insert a new entry into <array>.  Depending upon the
             context, there may be severe restrictions about what
             constitutes a valid <value>.  The result will be the actual
             item added to the <array>.  Note that only one item can be
             added per CREATE operation.

   DELETE                array filter   DELETE   array
             Delete the entry(s) in <array> that match <filter>.
             Filters are described later in this document.  Normally, no
             data items will be produced in the response, but if any of
             the items that matched the filter could not be deleted,
             they will be returned in the response.

   An additional form of SET, which takes a filter argument, is
   described later.

   Here is an example of attempting to use SET to change the number of
   interfaces in an entity:
       System{ interfaces(5) } SET
   Since that is not a settable parameter, the result would be:
       System{ interfaces(2) }
   giving the old value.

   Here is an example of how CREATE would be used to add a routing table
   entry for net for 128.89.0.0.



Trewitt & Partridge                                            [Page 20]

RFC 1076          HEMS Monitoring and Control Language     November 1988


       IPRouting BEGIN                   -- get dictionary
       Entries{ DestAddr(128.89.0.0), ... }    -- entry to insert
       CREATE
       END                                 -- finished with dict

   The result would be what was added:
       IPRouting{ Entries{ DestAddr(128.89.0.0), ... } }

   The results in the response of these operators is consistent of the
   global model of the response:  it contains a subset of the data in
   the tree immediately after the query is executed.

   Note that CREATE and DELETE only operate on arrays, and then only on
   arrays that are specifically intended for it.  For example, it is
   quite reasonable to add and remove entries from routing tables or ARP
   tables, both of which are arrays.  However, it doesn't make sense to
   add or remove entries in the "Interfaces" dictionary, since the
   contents of that array is dictated by the hardware.  For each array
   in the data tree, RFC-1024 indicates whether CREATE and DELETE are
   valid.

   CREATE and DELETE are always invalid in non-array contexts.  If
   DELETE were allowed on monitored data, then the deleted data would
   become unmonitorable to the entire world.  Conversely, if it were
   possible to CREATE arbitrary dictionary entries, there would be no
   way to give such entries any meaning.  Even with the data in place,
   there is nothing that would couple the data to the operation of the
   monitored entity. [Creation and deletion would also add considerable
   complication to an implementation, because without them, all of the
   data structures that represent the data tree are essentially static,
   with the exception of dynamic tables such as the ones mentioned,
   which already have mechanisms in place for adding and removing
   entries.]

8.6 Associative Data Access:  Filters

   One problem that has not been dealt with was alluded to earlier: When
   dealing with array data, how do you specify one or more entries based
   upon some value in the array entries?  Consider the situation where
   there are several interfaces.  The data might be organized as:

       Interfaces {                            -- one per interface
               InterfaceData { address, mtu, netMask, ARP{...}, ... }
               InterfaceData { address, mtu, netMask, ARP{...}, ... }
                               :
               }

   If you only want information about one interface (perhaps because