rfc1212.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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) "}"