    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]

    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]