GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1212

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:
  1. - the IP Address Translation tables
  1. - The Address Translation tables contain IpAddress to
  2. - "physical" address equivalences. Some interfaces do not
  3. - use translation tables for determining address equivalences
  4. - (e.g., DDN-X.25 has an algorithmic method); if all
  5. - interfaces are of this type, then the Address Translation
  6. - 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;
  1. - 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1212.txt · Last modified: 1991/06/03 23:45 (external edit)