doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc1212.txt b/doc/rfc/rfc1212.txt
new file mode 100644
index 0000000..d16bd5e
--- /dev/null
+++ b/doc/rfc/rfc1212.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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]
+
\ No newline at end of file