rfc1442.txt

<VC++网络游戏建摸与实现>源代码

               sub-identifier in the value is copied);

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

          (6)  NsapAddress-valued: `n' sub-identifiers, where `n' is the
               length of the value (each octet of the value is encoded
               in a separate sub-identifier);






          Case, McCloghrie, Rose & Waldbusser                  [Page 29]





          RFC 1442                SMI for SNMPv2              April 1993


          Note that the IMPLIED keyword can only be present for objects
          having a variable-length syntax (e.g., variable-length strings
          or object identifier-valued objects).  Further, the IMPLIED
          keyword may appear at most once within the INDEX clause, and
          if so, is associated with the right-most object having a
          variable-length syntax.  Finally, the IMPLIED keyword may not
          be used on a variable-length string object if that string
          might have a value of zero-length.

          Instances identified by use of integer-valued objects should
          be numbered starting from one (i.e., not from zero).  The use
          of zero as a value for an integer-valued index object should
          be avoided, except in special cases.

          Objects which are both specified in the INDEX clause of a
          conceptual row and also columnar objects of the same
          conceptual row are termed auxiliary objects.  The MAX-ACCESS
          clause for newly-defined auxiliary objects is "not-
          accessible".  However, a conceptual row must contain at least
          one columnar object which is not an auxiliary object (i.e.,
          the value of the MAX-ACCESS clause for such an object is
          either "read-only" or "read-create").

          Note that objects specified in a conceptual row's INDEX clause
          need not be columnar objects of that conceptual row.  In this
          situation, the DESCRIPTION clause of the conceptual row must
          include a textual explanation of how the objects which are
          included in the INDEX clause but not columnar objects of that
          conceptual row, are used in uniquely identifying instances of
          the conceptual row's columnar objects.


          7.7.1.  Creation and Deletion of Conceptual Rows

          For newly-defined conceptual rows which allow the creation of
          new object instances and the deletion of existing object
          instances, there should be one columnar object with a SYNTAX
          clause value of RowStatus (a textual convention defined in
          [3]) and a MAX-ACCESS clause value of read-create.  By
          convention, this is termed the status column for the
          conceptual row.









          Case, McCloghrie, Rose & Waldbusser                  [Page 30]





          RFC 1442                SMI for SNMPv2              April 1993


          7.8.  Mapping of the AUGMENTS clause

          The AUGMENTS clause, which must not be present unless the
          object corresponds to a conceptual row, is an alternative to
          the INDEX clause.  Every object corresponding to a conceptual
          row has either an INDEX clause or an AUGMENTS clause.

          If an object corresponding to a conceptual row has an INDEX
          clause, that row is termed a base conceptual row;
          alternatively, if the object has an AUGMENTS clause, the row
          is said to be a conceptual row augmentation, where the
          AUGMENTS clause names the object corresponding to the base
          conceptual row which is augmented by this conceptual row
          extension.  Instances of subordinate columnar objects of a
          conceptual row extension are identified according to the INDEX
          clause of the base conceptual row corresponding to the object
          named in the AUGMENTS clause.  Further, instances of
          subordinate columnar objects of a conceptual row extension
          exist according to the same semantics as instances of
          subordinate columnar objects of the base conceptual row being
          augmented.  As such, note that creation of a base conceptual
          row implies the correspondent creation of any conceptual row
          augmentations.

          For example, a MIB designer might wish to define additional
          columns in an "enterprise-specific" MIB which logically extend
          a conceptual row in a "standard" MIB.  The "standard" MIB
          definition of the conceptual row would include the INDEX
          clause and the "enterprise-specific" MIB would contain the
          definition of a conceptual row using the AUGMENTS clause.

          Note that a base conceptual row may be augmented by multiple
          conceptual row extensions.


          7.8.1.  Relation between INDEX and AUGMENTS clauses

          When defining instance identification information for a
          conceptual table:

          (1)  If there is a one-to-one correspondence between the
               conceptual rows of this table and an existing table, then
               the AUGMENTS clause should be used.







          Case, McCloghrie, Rose & Waldbusser                  [Page 31]





          RFC 1442                SMI for SNMPv2              April 1993


          (2)  Otherwise, if there is a sparse relationship between the
               conceptuals rows of this table and an existing table,
               then an INDEX clause should be used which is identical to
               that in the existing table.

          (3)  Otherwise, auxiliary objects should be defined within the
               conceptual row for the new table, and those objects
               should be used within the INDEX clause for the conceptual
               row.


          7.9.  Mapping of the DEFVAL clause

          The DEFVAL clause, which need not be present, defines an
          acceptable default value which may be used at the discretion
          of a SNMPv2 entity acting in an agent role when an object
          instance is created.

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

          The value of the DEFVAL clause must, of course, correspond to
          the SYNTAX clause for the object.  If the value is an OBJECT
          IDENTIFIER, then it must be expressed as a single ASN.1
          identifier, and not as a collection of sub-identifiers.

          Note that if an operand to the management protocol set
          operation is an instance of a read-only object, then the error
          `notWritable' [6] will be returned.  As such, the DEFVAL
          clause can be used to provide an acceptable default value that
          a SNMPv2 entity acting in an agent role might use.

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












          Case, McCloghrie, Rose & Waldbusser                  [Page 32]





          RFC 1442                SMI for SNMPv2              April 1993


         ObjectSyntax        DEFVAL clause
         -----------------   ------------
         Integer32           1
                             -- same for Gauge32, TimeTicks, UInteger32
         INTEGER             valid -- enumerated value
         OCTET STRING        'ffffffffffff'H
         OBJECT IDENTIFIER   sysDescr
         BIT STRING          { primary, secondary } -- enumerated values
               IpAddress           'c0210415'H -- 192.33.4.21

          Object types with SYNTAX of Counter32 and Counter64 may not
          have DEFVAL clauses, since they do not have defined initial
          values.  However, it is recommended that they be initialized
          to zero.


          7.10.  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, an
          administratively assigned name.

          When an OBJECT IDENTIFIER is assigned to an object:

          (1)  If the object corresponds to a conceptual table, then
               only a single assignment, that for a conceptual row, is
               present immediately beneath that object.  The
               administratively assigned name for the conceptual row
               object is derived by appending a sub-identifier of "1" to
               the administratively assigned name for the conceptual
               table.

          (2)  If the object corresponds to a conceptual row, then at
               least one assignment, one for each column in the
               conceptual row, is present beneath that object.  The
               administratively assigned name for each column is derived
               by appending a unique, positive sub-identifier to the
               administratively assigned name for the conceptual row.

          (3)  Otherwise, no other OBJECT IDENTIFIERs which are
               subordinate to the object may be assigned.

          Note that the final sub-identifier of any administratively
          assigned name for an object shall be positive.  A zero-valued
          final sub-identifier is reserved for future use.





          Case, McCloghrie, Rose & Waldbusser                  [Page 33]





          RFC 1442                SMI for SNMPv2              April 1993


          Further note that although conceptual tables and rows are
          given administratively assigned names, these conceptual
          objects may not be manipulated in aggregate form by the
          management protocol.














































          Case, McCloghrie, Rose & Waldbusser                  [Page 34]





          RFC 1442                SMI for SNMPv2              April 1993


          7.11.  Usage Example

          Consider how one might define a conceptual table and its
          subordinates.

          evalSlot OBJECT-TYPE
              SYNTAX      INTEGER
              MAX-ACCESS  read-only
              STATUS      current
              DESCRIPTION
                      "The index number of the first unassigned entry in
                      the evaluation table.

                      A management station should create new entries in
                      the evaluation table using this algorithm: first,
                      issue a management protocol retrieval operation to
                      determine the value of evalSlot; and, second,
                      issue a management protocol set operation to
                      create an instance of the evalStatus object
                      setting its value to underCreation(1).  If this
                      latter operation succeeds, then the management
                      station may continue modifying the instances
                      corresponding to the newly created conceptual row,
                      without fear of collision with other management
                      stations."
              ::= { eval 1 }

          evalTable OBJECT-TYPE
              SYNTAX      SEQUENCE OF EvalEntry
              MAX-ACCESS  not-accessible
              STATUS      current
              DESCRIPTION
                      "The (conceptual) evaluation table."
              ::= { eval 2 }

          evalEntry OBJECT-TYPE
              SYNTAX      EvalEntry
              MAX-ACCESS  not-accessible
              STATUS      current
              DESCRIPTION
                      "An entry (conceptual row) in the evaluation
                      table."
              INDEX   { evalIndex }
              ::= { evalTable 1 }






          Case, McCloghrie, Rose & Waldbusser                  [Page 35]





          RFC 1442                SMI for SNMPv2              April 1993


          EvalEntry ::=
              SEQUENCE {
                  evalIndex       Integer32,
                  evalString      DisplayString,
                  evalValue       Integer32,
                  evalStatus      RowStatus
              }

          evalIndex OBJECT-TYPE
              SYNTAX      Integer32
              MAX-ACCESS  not-accessible
              STATUS      current
              DESCRIPTION
                      "The auxiliary variable used for identifying
                      instances of the columnar objects in the
                      evaluation table."
                  ::= { evalEntry 1 }

          evalString OBJECT-TYPE
              SYNTAX      DisplayString
              MAX-ACCESS  read-create
              STATUS      current
              DESCRIPTION
                      "The string to evaluate."
                  ::= { evalEntry 2 }

          evalValue OBJECT-TYPE
              SYNTAX      Integer32
              MAX-ACCESS  read-only
              STATUS      current
              DESCRIPTION
                      "The value when evalString was last executed."
              DEFVAL  { 0 }
                  ::= { evalEntry 3 }

          evalStatus OBJECT-TYPE
              SYNTAX      RowStatus
              MAX-ACCESS  read-create
              STATUS      current
              DESCRIPTION
                      "The status column used for creating, modifying,
                      and deleting instances of the columnar objects in
                      the evaluation  table."
              DEFVAL  { active }
                  ::= { evalEntry 4 }





          Case, McCloghrie, Rose & Waldbusser                  [Page 36]





          RFC 1442                SMI for SNMPv2              April 1993


          8.  Mapping of the NOTIFICATION-TYPE macro

          The NOTIFICATION-TYPE macro is used to define the information
          contained within an unsolicited transmission of management
          information (i.e., within either a SNMPv2-Trap-PDU or
          InformRequest-PDU).  It should be noted that the expansion of
          the NOTIFICATION-TYPE macro is something which conceptually
          happens during implementation and not during run-time.


          8.1.  Mapping of the OBJECTS clause

          The OBJECTS clause, which need not be present, defines the
          ordered sequence of MIB objects which are contained within
          every in