path: root/doc/rfc/rfc1212.txt

Network Working Group                                           M. Rose
Request for Comments: 1212            Performance Systems International
                                                          K. McCloghrie
                                                     Hughes LAN Systems
                                                                Editors
                                                             March 1991


                        Concise MIB Definitions
Status of this Memo

   This memo defines a format for producing MIB modules.  This RFC
   specifies an IAB standards track document for the Internet community,
   and requests discussion and suggestions for improvements.  Please
   refer to the current edition of the "IAB Official Protocol Standards"
   for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Table of Contents

   1. Abstract..............................................    2
   2. Historical Perspective ...............................    2
   3. Columnar Objects .....................................    3
   3.1 Row Deletion ........................................    4
   3.2 Row Addition ........................................    4
   4. Defining Objects .....................................    5
   4.1 Mapping of the OBJECT-TYPE macro ....................    7
   4.1.1 Mapping of the SYNTAX clause ......................    7
   4.1.2 Mapping of the ACCESS clause ......................    8
   4.1.3 Mapping of the STATUS clause ......................    8
   4.1.4 Mapping of the DESCRIPTION clause .................    8
   4.1.5 Mapping of the REFERENCE clause ...................    8
   4.1.6 Mapping of the INDEX clause .......................    8
   4.1.7 Mapping of the DEFVAL clause ......................   10
   4.1.8 Mapping of the OBJECT-TYPE value ..................   11
   4.2 Usage Example .......................................   11
   5. Appendix: DE-osifying MIBs ...........................   13
   5.1 Managed Object Mapping ..............................   14
   5.1.1 Mapping to the SYNTAX clause ......................   15
   5.1.2 Mapping to the ACCESS clause ......................   15
   5.1.3 Mapping to the STATUS clause ......................   15
   5.1.4 Mapping to the DESCRIPTION clause .................   15
   5.1.5 Mapping to the REFERENCE clause ...................   16
   5.1.6 Mapping to the INDEX clause .......................   16
   5.1.7 Mapping to the DEFVAL clause ......................   16
   5.2 Action Mapping ......................................   16
   5.2.1 Mapping to the SYNTAX clause ......................   16
   5.2.2 Mapping to the ACCESS clause ......................   16



SNMP Working Group                                              [Page 1]
^L
RFC 1212                Concise MIB Definitions               March 1991


   5.2.3 Mapping to the STATUS clause ......................   16
   5.2.4 Mapping to the DESCRIPTION clause .................   16
   5.2.5 Mapping to the REFERENCE clause ...................   16
   6. Acknowledgements .....................................   17
   7. References ...........................................   18
   8. Security Considerations...............................   19
   9. Authors' Addresses....................................   19

1.  Abstract

   This memo describes a straight-forward approach toward producing
   concise, yet descriptive, MIB modules.  It is intended that all
   future MIB modules be written in this format.

2.  Historical Perspective

   As reported in RFC 1052, IAB Recommendations for the Development of
   Internet Network Management Standards [1], a two-prong strategy for
   network management of TCP/IP-based internets was undertaken.  In the
   short-term, the Simple Network Management Protocol (SNMP), defined in
   RFC 1067, was to be used to manage nodes in the Internet community.
   In the long-term, the use of the OSI network management framework was
   to be examined.  Two documents were produced to define the management
   information: RFC 1065, which defined the Structure of Management
   Information (SMI), and RFC 1066, which defined the Management
   Information Base (MIB).  Both of these documents were designed so as
   to be compatible with both the SNMP and the OSI network management
   framework.

   This strategy was quite successful in the short-term: Internet-based
   network management technology was fielded, by both the research and
   commercial communities, within a few months.  As a result of this,
   portions of the Internet community became network manageable in a
   timely fashion.

   As reported in RFC 1109, Report of the Second Ad Hoc Network
   Management Review Group [2], the requirements of the SNMP and the OSI
   network management frameworks were more different than anticipated.
   As such, the requirement for compatibility between the SMI/MIB and
   both frameworks was suspended.  This action permitted the operational
   network management framework, based on the SNMP, to respond to new
   operational needs in the Internet community by producing MIB-II.

   In May of 1990, the core documents were elevated to "Standard
   Protocols" with "Recommended" status.  As such, the Internet-standard
   network management framework consists of: Structure and
   Identification of Management Information for TCP/IP-based internets,
   RFC 1155 [3], which describes how managed objects contained in the



SNMP Working Group                                              [Page 2]
^L
RFC 1212                Concise MIB Definitions               March 1991


   MIB are defined; Management Information Base for Network Management
   of TCP/IP-based internets, which describes the managed objects
   contained in the MIB, RFC 1156 [4]; and, the Simple Network
   Management Protocol, RFC 1157 [5], which defines the protocol used to
   manage these objects.  Consistent with the IAB directive to produce
   simple, workable systems in the short-term, the list of managed
   objects defined in the Internet-standard MIB was derived by taking
   only those elements which are considered essential.  However, the SMI
   defined three extensibility mechanisms: one, the addition of new
   standard objects through the definitions of new versions of the MIB;
   two, the addition of widely-available but non-standard objects
   through the experimental subtree; and three, the addition of private
   objects through the enterprises subtree.  Such additional objects can
   not only be used for vendor-specific elements, but also for
   experimentation as required to further the knowledge of which other
   objects are essential.

   As more objects are defined using the second method, experience has
   shown that the resulting MIB descriptions contain redundant
   information.  In order to provide for MIB descriptions which are more
   concise, and yet as informative, an enhancement is suggested.  This
   enhancement allows the author of a MIB to remove the redundant
   information, while retaining the important descriptive text.

   Before presenting the approach, a brief presentation of columnar
   object handling by the SNMP is necessary.  This explains and further
   motivates the value of the enhancement.

3.  Columnar Objects

   The SNMP supports operations on MIB objects whose syntax is
   ObjectSyntax as defined in the SMI.  Informally stated, SNMP
   operations apply exclusively to scalar objects.  However, it is
   convenient for developers of management applications to impose
   imaginary, tabular structures on the ordered collection of objects
   that constitute the MIB.  Each such conceptual table contains zero or
   more rows, and each row may contain one or more scalar objects,
   termed columnar objects.  Historically, this conceptualization has
   been formalized by using the OBJECT-TYPE macro to define both an
   object which corresponds to a table and an object which corresponds
   to a row in that table.  (The ACCESS clause for such objects is
   "not-accessible", of course.) However, it must be emphasized that, at
   the protocol level, relationships among columnar objects in the same
   row is a matter of convention, not of protocol.

   Note that there are good reasons why the tabular structure is not a
   matter of protocol.  Consider the operation of the SNMP Get-Next-PDU
   acting on the last columnar object of an instance of a conceptual



SNMP Working Group                                              [Page 3]
^L
RFC 1212                Concise MIB Definitions               March 1991


   row; it returns the next column of the first conceptual row or the
   first object instance occurring after the table.  In contrast, if the
   rows were a matter of protocol, then it would instead return an
   error.  By not returning an error, a single PDU exchange informs the
   manager that not only has the end of the conceptual row/table been
   reached, but also provides information on the next object instance,
   thereby increasing the information density of the PDU exchange.

3.1.  Row Deletion

   Nonetheless, it is highly useful to provide a means whereby a
   conceptual row may be removed from a table. In MIB-II, this was
   achieved by defining, for each conceptual row, an integer-valued
   columnar object.  If a management station sets the value of this
   object to some value, usually termed "invalid", then the effect is
   one of invalidating the corresponding row in the table.  However, it
   is an implementation-specific matter as to whether an agent removes
   an invalidated entry from the table.  Accordingly, management
   stations must be prepared to receive tabular information from agents
   that corresponds to entries not currently in use.  Proper
   interpretation of such entries requires examination of the columnar
   object indicating the in-use status.

3.2.  Row Addition

   It is also highly useful to have a clear understanding of how a
   conceptual row may be added to a table.  In the SNMP, at the protocol
   level, a management station issues an SNMP set operation containing
   an arbitrary set of variable bindings.  In the case that an agent
   detects that one or more of those variable bindings refers to an
   object instance not currently available in that agent, it may,
   according to the rules of the SNMP, behave according to any of the
   following paradigms:

          (1)  It may reject the SNMP set operation as referring to
               non-existent object instances by returning a response
               with the error-status field set to "noSuchName" and the
               error-index field set to refer to the first vacuous
               reference.

          (2)  It may accept the SNMP set operation as requesting the
               creation  of new object instances corresponding to each
               of the object instances named in the variable bindings.
               The value of each (potentially) newly created object
               instance is specified by the "value" component of the
               relevant variable binding.  In this case, if the request
               specifies a value for a newly (or previously) created
               object that it deems inappropriate by reason of value or



SNMP Working Group                                              [Page 4]
^L
RFC 1212                Concise MIB Definitions               March 1991


               syntax, then it rejects the SNMP set operation by
               responding with the error-status field set to badValue
               and the error-index field set to refer to the first
               offending variable binding.

          (3)  It may accept the SNMP set operation and create new
               object instances as described in (2) above and, in
               addition, at its discretion, create supplemental object
               instances to complete a row in a conceptual table of
               which the new object instances specified in the request
               may be a part.

   It should be emphasized that all three of the above behaviors are
   fully conformant to the SNMP specification and are fully acceptable,
   subject to any restrictions which may be imposed by access control
   and/or the definitions of the MIB objects themselves.

4.  Defining Objects

   The Internet-standard SMI employs a two-level approach towards object
   definition.  A MIB definition consists of two parts: a textual part,
   in which objects are placed into groups, and a MIB module, in which
   objects are described solely in terms of the ASN.1 macro OBJECT-TYPE,
   which is defined by the SMI.

   An example of the former definition might be:

          OBJECT:
          -------
               sysLocation { system 6 }

          Syntax:
               DisplayString (SIZE (0..255))

          Definition:
               The physical location of this node (e.g., "telephone
               closet, 3rd floor").

          Access:
               read-only.

          Status:
               mandatory.

          An example of the latter definition might be:

               sysLocation OBJECT-TYPE
                   SYNTAX  DisplayString (SIZE (0..255))



SNMP Working Group                                              [Page 5]
^L
RFC 1212                Concise MIB Definitions               March 1991


                   ACCESS  read-only
                   STATUS  mandatory
                   ::= { system 6 }

          In the interests of brevity and to reduce the chance of
          editing errors, it would seem useful to combine the two
          definitions.  This can be accomplished by defining an
          extension to the OBJECT-TYPE macro:

          IMPORTS
              ObjectName
                  FROM RFC1155-SMI
              DisplayString
                  FROM RFC1158-MIB;

          OBJECT-TYPE MACRO ::=
          BEGIN
              TYPE NOTATION ::=
                                          -- must conform to
                                          -- RFC1155's ObjectSyntax
                                "SYNTAX" type(ObjectSyntax)
                                "ACCESS" Access
                                "STATUS" Status
                                DescrPart
                                ReferPart
                                IndexPart
                                DefValPart
              VALUE NOTATION ::= value (VALUE ObjectName)

              Access ::= "read-only"
                              | "read-write"
                              | "write-only"
                              | "not-accessible"
              Status ::= "mandatory"
                              | "optional"
                              | "obsolete"
                              | "deprecated"

              DescrPart ::=
                         "DESCRIPTION" value (description DisplayString)
                              | empty

              ReferPart ::=
                         "REFERENCE" value (reference DisplayString)
                              | empty

              IndexPart ::=
                         "INDEX" "{" IndexTypes "}"



SNMP Working Group                                              [Page 6]
^L
RFC 1212                Concise MIB Definitions               March 1991


                              | empty
              IndexTypes ::=
                         IndexType | IndexTypes "," IndexType
              IndexType ::=
                                  -- if indexobject, use the SYNTAX
                                  -- value of the correspondent
                                  -- OBJECT-TYPE invocation
                         value (indexobject ObjectName)
                                  -- otherwise use named SMI type
                                  -- must conform to IndexSyntax below
                              | type (indextype)

              DefValPart ::=
                         "DEFVAL" "{" value (defvalue ObjectSyntax) "}"
                              | empty

          END

          IndexSyntax ::=
              CHOICE {
                  number
                      INTEGER (0..MAX),
                  string
                      OCTET STRING,
                  object
                      OBJECT IDENTIFIER,
                  address
                      NetworkAddress,
                  ipAddress
                      IpAddress
              }


4.1.  Mapping of the OBJECT-TYPE macro

   It should be noted that the expansion of the OBJECT-TYPE macro is
   something which conceptually happens during implementation and not
   during run-time.

4.1.1.  Mapping of the SYNTAX clause

   The SYNTAX clause, which must be present, defines the abstract data
   structure corresponding to that object type.  The ASN.1 language [6]
   is used for this purpose.  However, the SMI purposely restricts the
   ASN.1 constructs which may be used.  These restrictions are made
   expressly for simplicity.





SNMP Working Group                                              [Page 7]
^L
RFC 1212                Concise MIB Definitions               March 1991


4.1.2.  Mapping of the ACCESS clause

   The ACCESS clause, which must be present, defines the minimum level
   of support required for that object type.  As a local matter,
   implementations may support other access types (e.g., an
   implementation may elect to permitting writing a variable marked as
   read-only).  Further, protocol-specific "views" (e.g., those
   indirectly implied by an SNMP community) may make further
   restrictions on access to a variable.

4.1.3.  Mapping of the STATUS clause

   The STATUS clause, which must be present, defines the implementation
   support required for that object type.

4.1.4.  Mapping of the DESCRIPTION clause

   The DESCRIPTION clause, which need not be present, contains a textual
   definition of that object type which provides all semantic
   definitions necessary for implementation, and should embody any
   information which would otherwise be communicated in any ASN.1
   commentary annotations associated with the object.  Note that, in
   order to conform to the ASN.1 syntax, the entire value of this clause
   must be enclosed in double quotation marks, although the value may be
   multi-line.

   Further, note that if the MIB module does not contain a textual
   description of the object type elsewhere then the DESCRIPTION clause
   must be present.

4.1.5.  Mapping of the REFERENCE clause

   The REFERENCE clause, which need not be present, contains a textual
   cross-reference to an object defined in some other MIB module.  This
   is useful when de-osifying a MIB produced by some other organization.

4.1.6.  Mapping of the INDEX clause

   The INDEX clause, which may be present only if that object type
   corresponds to a conceptual row, defines instance identification
   information for that object type.  (Historically, each MIB definition
   contained a section entitled "Identification of OBJECT instances for
   use with the SNMP".  By using the INDEX clause, this section need no
   longer occur as this clause concisely captures the precise semantics
   needed for instance identification.)

   If the INDEX clause is not present, and the object type corresponds
   to a non-columnar object, then instances of the object are identified



SNMP Working Group                                              [Page 8]
^L
RFC 1212                Concise MIB Definitions               March 1991


   by appending a sub-identifier of zero to the name of that object.
   Further, note that if the MIB module does not contain a textual
   description of how instance identification information is derived for
   columnar objects, then the INDEX clause must be present.

   To define the instance identification information, determine which
   object value(s) will unambiguously distinguish a conceptual row.  The
   syntax of those objects indicate how to form the instance-identifier:

          (1)  integer-valued: a single sub-identifier taking the
               integer value (this works only for non-negative
               integers);

          (2)  string-valued, fixed-length strings: `n' sub-identifiers,
               where `n' is the length of the string (each octet of the
               string is encoded in a separate sub-identifier);

          (3)  string-valued, variable-length strings: `n+1' sub-
               identifiers, where `n' is the length of the string (the
               first sub-identifier is `n' itself, following this, each
               octet of the string is encoded in a separate sub-
               identifier);

          (4)  object identifier-valued: `n+1' sub-identifiers, where
               `n' is the number of sub-identifiers in the value (the
               first sub-identifier is `n' itself, following this, each
               sub-identifier in the value is copied);

          (5)  NetworkAddress-valued: `n+1' sub-identifiers, where `n'
               depends on the kind of address being encoded (the first
               sub-identifier indicates the kind of address, value 1
               indicates an IpAddress); or,

          (6)  IpAddress-valued: 4 sub-identifiers, in the familiar
               a.b.c.d notation.

   Note that if an "indextype" value is present (e.g., INTEGER rather
   than ifIndex), then a DESCRIPTION clause must be present; the text
   contained therein indicates the semantics of the "indextype" value.












SNMP Working Group                                              [Page 9]
^L
RFC 1212                Concise MIB Definitions               March 1991


   By way of example, in the context of MIB-II [7], the following INDEX
   clauses might be present:

                 objects under         INDEX clause
               -----------------       ------------
               ifEntry                 { ifIndex }
               atEntry                 { atNetIfIndex,
                                         atNetAddress }
               ipAddrEntry             { ipAdEntAddr }
               ipRouteEntry            { ipRouteDest }
               ipNetToMediaEntry       { ipNetToMediaIfIndex,
                                         ipNetToMediaNetAddress }
               tcpConnEntry            { tcpConnLocalAddress,
                                         tcpConnLocalPort,
                                         tcpConnRemoteAddress,
                                         tcpConnRemotePort }
               udpEntry                { udpLocalAddress,
                                         udpLocalPort }
               egpNeighEntry           { egpNeighAddr }


4.1.7.  Mapping of the DEFVAL clause

   The DEFVAL clause, which need not be present, defines an acceptable
   default value which may be used when an object instance is created at
   the discretion of the agent acting in conformance with the third
   paradigm described in Section 4.2 above.

   During conceptual row creation, if an instance of a columnar object
   is not present as one of the operands in the correspondent SNMP set
   operation, then the value of the DEFVAL clause, if present, indicates
   an acceptable default value that the agent might use.

   The value of the DEFVAL clause must, of course, correspond to the
   SYNTAX clause for the object.  Note that if an operand to the SNMP
   set operation is an instance of a read-only object, then the error
   noSuchName will be returned.  As such, the DEFVAL clause can be used
   to provide an acceptable default value that the agent might use.

   It is possible that no acceptable default value may exist for any of
   the columnar objects in a conceptual row for which the creation of
   new object instances is allowed.  In this case, the objects specified
   in the INDEX clause must have a corresponding ACCESS clause value of
   read-write.







SNMP Working Group                                             [Page 10]
^L
RFC 1212                Concise MIB Definitions               March 1991


   By way of example, consider the following possible DEFVAL clauses:

       ObjectSyntax            DEFVAL clause
       -----------------       ------------
       INTEGER                 1 -- same for Counter, Gauge, TimeTicks
       OCTET STRING            'ffffffffffff'h
       DisplayString           "any NVT ASCII string"
       OBJECT IDENTIFIER       sysDescr
       OBJECT IDENTIFIER       { system 2 }
       NULL                    NULL
       NetworkAddress          { internet 'c0210415'h }
       IpAddress               'c0210415'h -- 192.33.4.21


4.1.8.  Mapping of the OBJECT-TYPE value

   The value of an invocation of the OBJECT-TYPE macro is the name of
   the object, which is an object identifier.

4.2.  Usage Example

   Consider how the ipNetToMediaTable from MIB-II might be fully
   described:

          -- the IP Address Translation tables

          -- The Address Translation tables contain IpAddress to
          -- "physical" address equivalences.  Some interfaces do not
          -- use translation tables for determining address equivalences
          -- (e.g., DDN-X.25 has an algorithmic method); if all
          -- interfaces are of this type, then the Address Translation
          -- table is empty, i.e., has zero entries.

          ipNetToMediaTable OBJECT-TYPE
              SYNTAX  SEQUENCE OF IpNetToMediaEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "The IP Address Translation table used for mapping
                      from IP addresses to physical addresses."
              ::= { ip 22 }

          ipNetToMediaEntry OBJECT-TYPE
              SYNTAX  IpNetToMediaEntry
              ACCESS  not-accessible
              STATUS  mandatory
              DESCRIPTION
                      "Each entry contains one IpAddress to 'physical'



SNMP Working Group                                             [Page 11]
^L
RFC 1212                Concise MIB Definitions               March 1991


                      address equivalence."
              INDEX   { ipNetToMediaIfIndex,
                        ipNetToMediaNetAddress }
              ::= { ipNetToMediaTable 1 }

          IpNetToMediaEntry ::=
              SEQUENCE {
                  ipNetToMediaIfIndex
                      INTEGER,
                  ipNetToMediaPhysAddress
                      OCTET STRING,
                  ipNetToMediaNetAddress
                      IpAddress,
                  ipNetoToMediaType
                      INTEGER
              }

          ipNetToMediaIfIndex OBJECT-TYPE
              SYNTAX  INTEGER
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "The interface on which this entry's equivalence
                      is effective.  The interface identified by a
                      particular value of this index is the same
                      interface as identified by the same value of
                      ifIndex."
              ::= { ipNetToMediaEntry 1 }

          ipNetToMediaPhysAddress OBJECT-TYPE
              SYNTAX  OCTET STRING
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "The media-dependent 'physical' address."
              ::= { ipNetToMediaEntry 2 }

          ipNetToMediaNetAddress OBJECT-TYPE
              SYNTAX  IpAddress
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "The IpAddress corresponding to the media-
                      dependent 'physical' address."
              ::= { ipNetToMediaEntry 3 }

          ipNetToMediaType OBJECT-TYPE
              SYNTAX  INTEGER {



SNMP Working Group                                             [Page 12]
^L
RFC 1212                Concise MIB Definitions               March 1991


                          other(1),   -- none of the following
                          invalid(2), -- an invalidated mapping
                          dynamic(3),
                          static(4)
                      }
              ACCESS  read-write
              STATUS  mandatory
              DESCRIPTION
                      "The type of mapping.

                      Setting this object to the value invalid(2) has
                      the effect of invalidating the corresponding entry
                      in the ipNetToMediaTable.  That is, it effectively
                      disassociates the interface identified with said
                      entry from the mapping identified with said entry.
                      It is an implementation-specific matter as to
                      whether the agent removes an invalidated entry
                      from the table.  Accordingly, management stations
                      must be prepared to receive tabular information
                      from agents that corresponds to entries not
                      currently in use.  Proper interpretation of such
                      entries requires examination of the relevant
                      ipNetToMediaType object."
                  ::= { ipNetToMediaEntry 4 }


5.  Appendix: DE-osifying MIBs

   There has been an increasing amount of work recently on taking MIBs
   defined by other organizations (e.g., the IEEE) and de-osifying them
   for use with the Internet-standard network management framework.  The
   steps to achieve this are straight-forward, though tedious.  Of
   course, it is helpful to already be experienced in writing MIB
   modules for use with the Internet-standard network management
   framework.

   The first step is to construct a skeletal MIB module, e.g.,

               RFC1213-MIB DEFINITIONS ::= BEGIN

               IMPORTS
                       experimental, OBJECT-TYPE, Counter
                           FROM RFC1155-SMI;

                       -- contact IANA for actual number
               root    OBJECT IDENTIFIER ::= { experimental xx }

               END



SNMP Working Group                                             [Page 13]
^L
RFC 1212                Concise MIB Definitions               March 1991


   The next step is to categorize the objects into groups.  For
   experimental MIBs, optional objects are permitted.  However, when a
   MIB module is placed in the Internet-standard space, these optional
   objects are either removed, or placed in a optional group, which, if
   implemented, all objects in the group must be implemented.  For the
   first pass, it is wisest to simply ignore any optional objects in the
   original MIB: experience shows it is better to define a core MIB
   module first, containing only essential objects; later, if experience
   demands, other objects can be added.

   It must be emphasized that groups are "units of conformance" within a
   MIB: everything in a group is "mandatory" and implementations do
   either whole groups or none.

5.1.  Managed Object Mapping

   Next for each managed object class, determine whether there can exist
   multiple instances of that managed object class.  If not, then for
   each of its attributes, use the OBJECT-TYPE macro to make an
   equivalent definition.

   Otherwise, if multiple instances of the managed object class can
   exist, then define a conceptual table having conceptual rows each
   containing a columnar object for each of the managed object class's
   attributes. If the managed object class is contained within the
   containment tree of another managed object class, then the assignment
   of an object type is normally required for each of the "distinguished
   attributes" of the containing managed object class.  If they do not
   already exist within the MIB module, then they can be added via the
   definition of additional columnar objects in the conceptual row
   corresponding to the contained managed object class.

   In defining a conceptual row, it is useful to consider the
   optimization of network management operations which will act upon its
   columnar objects.  In particular, it is wisest to avoid defining more
   columnar objects within a conceptual row, than can fit in a single
   PDU.  As a rule of thumb, a conceptual row should contain no more
   than approximately 20 objects.  Similarly, or as a way to abide by
   the "20 object guideline", columnar objects should be grouped into
   tables according to the expected grouping of network management
   operations upon them.  As such, the content of conceptual rows should
   reflect typical access scenarios, e.g., they should be organized
   along functional lines such as one row for statistics and another row
   for parameters, or along usage lines such as commonly-needed objects
   versus rarely-needed objects.

   On the other hand, the definition of conceptual rows where the number
   of columnar objects used as indexes outnumbers the number used to



SNMP Working Group                                             [Page 14]
^L
RFC 1212                Concise MIB Definitions               March 1991


   hold information, should also be avoided.  In particular, the
   splitting of a managed object class's attributes into many conceptual
   tables should not be used as a way to obtain the same degree of
   flexibility/complexity as is often found in MIB's with a myriad of
   optionals.

5.1.1.  Mapping to the SYNTAX clause

   When mapping to the SYNTAX clause of the OBJECT-type macro:

          (1)  An object with BOOLEAN syntax becomes an INTEGER taking
               either of values true(1) or false(2).

          (2)  An object with ENUMERATED syntax becomes an INTEGER,
               taking any of the values given.

          (3)  An object with BIT STRING syntax containing no more than
               32 bits becomes an INTEGER defined as a sum; otherwise if
               more than 32 bits are present, the object becomes an
               OCTET STRING, with the bits numbered from left-to-right,
               in which the least significant bits of the last octet may
               be "reserved for future use".

          (4)  An object with a character string syntax becomes either
               an OCTET STRING or a DisplayString, depending on the
               repertoire of the character string.

          (5)  An non-tabular object with a complex syntax, such as REAL
               or EXTERNAL, must be decomposed, usually into an OCTET
               STRING (if sensible).  As a rule, any object with a
               complicated syntax should be avoided.

          (6)  Tabular objects must be decomposed into rows of columnar
               objects.

5.1.2.  Mapping to the ACCESS clause

   This is straight-forward.

5.1.3.  Mapping to the STATUS clause

   This is usually straight-forward; however, some osified-MIBs use the
   term "recommended".  In this case, a choice must be made between
   "mandatory" and "optional".

5.1.4.  Mapping to the DESCRIPTION clause

   This is straight-forward: simply copy the text, making sure that any



SNMP Working Group                                             [Page 15]
^L
RFC 1212                Concise MIB Definitions               March 1991


   embedded double quotation marks are sanitized (i.e., replaced with
   single-quotes or removed).

5.1.5.  Mapping to the REFERENCE clause

   This is straight-forward: simply include a textual reference to the
   object being mapped, the document which defines the object, and
   perhaps a page number in the document.

5.1.6.  Mapping to the INDEX clause

   Decide how instance-identifiers for columnar objects are to be formed
   and define this clause accordingly.

5.1.7.  Mapping to the DEFVAL clause

   Decide if a meaningful default value can be assigned to the object
   being mapped, and if so, define the DEFVAL clause accordingly.

5.2.  Action Mapping

   Actions are modeled as read-write objects, in which writing a
   particular value results in the action taking place.

5.2.1.  Mapping to the SYNTAX clause

   Usually an INTEGER syntax is used with a distinguished value provided
   for each action that the object provides access to.  In addition,
   there is usually one other distinguished value, which is the one
   returned when the object is read.

5.2.2.  Mapping to the ACCESS clause

   Always use read-write.

5.2.3.  Mapping to the STATUS clause

   This is straight-forward.

5.2.4.  Mapping to the DESCRIPTION clause

   This is straight-forward: simply copy the text, making sure that any
   embedded double quotation marks are sanitized (i.e., replaced with
   single-quotes or removed).

5.2.5.  Mapping to the REFERENCE clause

   This is straight-forward: simply include a textual reference to the



SNMP Working Group                                             [Page 16]
^L
RFC 1212                Concise MIB Definitions               March 1991


   action being mapped, the document which defines the action, and
   perhaps a page number in the document.

6.  Acknowledgements

   This document was produced by the SNMP Working Group:

               Anne Ambler, Spider
               Karl Auerbach, Sun
               Fred Baker, ACC
               Ken Brinkerhoff
               Ron Broersma, NOSC
               Jack Brown, US Army
               Theodore Brunner, Bellcore
               Jeffrey Buffum, HP
               John Burress, Wellfleet
               Jeffrey D. Case, University of Tennessee at Knoxville
               Chris Chiptasso, Spartacus
               Paul Ciarfella, DEC
               Bob Collet
               John Cook, Chipcom
               Tracy Cox, Bellcore
               James R. Davin, MIT-LCS
               Eric Decker, cisco
               Kurt Dobbins, Cabletron
               Nadya El-Afandi, Network Systems
               Gary Ellis, HP
               Fred Engle
               Mike Erlinger
               Mark S. Fedor, PSI
               Richard Fox, Synoptics
               Karen Frisa, CMU
               Chris Gunner, DEC
               Fred Harris, University of Tennessee at Knoxville
               Ken Hibbard, Xylogics
               Ole Jacobsen, Interop
               Ken Jones
               Satish Joshi, Synoptics
               Frank Kastenholz, Racal-Interlan
               Shimshon Kaufman, Spartacus
               Ken Key, University of Tennessee at Knoxville
               Jim Kinder, Fibercom
               Alex Koifman, BBN
               Christopher Kolb, PSI
               Cheryl Krupczak, NCR
               Paul Langille, DEC
               Peter Lin, Vitalink
               John Lunny, TWG



SNMP Working Group                                             [Page 17]
^L
RFC 1212                Concise MIB Definitions               March 1991


               Carl Malamud
               Randy Mayhew, University of Tennessee at Knoxville
               Keith McCloghrie, Hughes LAN Systems
               Donna McMaster, David Systems
               Lynn Monsanto, Sun
               Dave Perkins, 3COM
               Jim Reinstedler, Ungerman Bass
               Anil Rijsinghani, DEC
               Kathy Rinehart, Arnold AFB
               Kary Robertson
               Marshall T. Rose, PSI (chair)
               L. Michael Sabo, NCSC
               Jon Saperia, DEC
               Greg Satz, cisco
               Martin Schoffstall, PSI
               John Seligson
               Steve Sherry, Xyplex
               Fei Shu, NEC
               Sam Sjogren, TGV
               Mark Sleeper, Sparta
               Lance Sprung
               Mike St.Johns
               Bob Stewart, Xyplex
               Emil Sturniold
               Kaj Tesink, Bellcore
               Dean Throop, Data General
               Bill Townsend, Xylogics
               Maurice Turcotte, Racal-Milgo
               Kannan Varadhou
               Sudhanshu Verma, HP
               Bill Versteeg, Network Research Corporation
               Warren Vik, Interactive Systems
               David Waitzman, BBN
               Steve Waldbusser, CMU
               Dan Wintringhan
               David Wood
               Wengyik Yeong, PSI
               Jeff Young, Cray Research

7.  References

   [1] Cerf, V., "IAB Recommendations for the Development of Internet
       Network Management Standards", RFC 1052, NRI, April 1988.

   [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
       Group", RFC 1109, NRI, August 1989.

   [3] Rose M., and K. McCloghrie, "Structure and Identification of



SNMP Working Group                                             [Page 18]
^L
RFC 1212                Concise MIB Definitions               March 1991


       Management Information for TCP/IP-based internets", RFC 1155,
       Performance Systems International, Hughes LAN Systems, May 1990.

   [4] McCloghrie K., and M. Rose, "Management Information Base for
       Network Management of TCP/IP-based internets", RFC 1156, Hughes
       LAN Systems, Performance Systems International, May 1990.

   [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
       Network Management Protocol", RFC 1157, SNMP Research,
       Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

   [6] Information processing systems - Open Systems Interconnection -
       Specification of Abstract Syntax Notation One (ASN.1),
       International Organization for Standardization International
       Standard 8824, December 1987.

   [7] Rose M., Editor, "Management Information Base for Network
       Management of TCP/IP-based internets: MIB-II", RFC 1213,
       Performance Systems International, March 1991.

8.  Security Considerations

   Security issues are not discussed in this memo.

9.  Authors' Addresses

   Marshall T. Rose
   Performance Systems International
   5201 Great America Parkway
   Suite 3106
   Santa Clara, CA  95054

   Phone: +1 408 562 6222
   EMail: mrose@psi.com
   X.500:  rose, psi, us


   Keith McCloghrie
   Hughes LAN Systems
   1225 Charleston Road
   Mountain View, CA 94043
   1225 Charleston Road
   Mountain View, CA 94043

   Phone: (415) 966-7934
   EMail: kzm@hls.com




SNMP Working Group                                             [Page 19]
^L