Guest

Cisco BTS 10200 Softswitch

SNMPv2-TC.mib (Release 4.5.1)

MIME-Version: 1.0 Content-Location: file:///C:/1F3BD2C3/451SNMPv2TC.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" -- Copyright (c) 2003, 2004, 2005, 2006 by Cisco Systems, Inc

-- Copyright (c) 2003, 2004, 2005, 2006 by Cisco Sy= stems, Inc.
--
-- Proprietary        =        Information of Cisco Systems Inc.
--
-- Module:        =            BTS10200 Softswitch Mib Definition.
--
-- Revision:        =          4.5
--
-- Authors:                 =   Brandon Doan
--

SNMPv2-TC DEFINITIONS ::=3D BEGIN

IMPORTS
    TimeTicks -- ,ObjectSyntax    rem= oved by Wes.
        FROM SNMPv2-SMI;

DisplayString ::=3D TEXTUAL-CONVENTION
    DISPLAY-HINT "255a"
    STATUS       curr= ent
    DESCRIPTION
        "Represents textual information taken from the NVT ASCII
       =   character set, as defined in pages 4, 10-11 of RFC 854.

       =   To summarize RFC 854, the NVT ASCII repertoire specifies:

        =    - the use of character codes 0-127 (decimal)

        =    - the graphics charact= ers (32-126) are interpreted as
        =      US ASCII

        =    - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
        =      meanings specified in RFC 854

        =    - the other 25 codes have no standard interpretation

           = - the sequence 'CR LF' means newline

        =    - the sequence 'CR NUL' means carriage-return

        =    - an 'LF' not preceded by a 'CR' means moving to the
        =      same column on the next line.

        =    - the sequence 'CR x' for any x other than LF or NUL is
        =      illegal.  (Note that th= is also means that a string may
        =      end with either 'CR LF' or 'CR NUL', but not with CR.)

       =   Any object defined using this syntax may not exceed 255
       =   characters in length."
    SYNTAX       OCTET STRING

PhysAddress ::=3D TEXTUAL-CONVENTION
    DISPLAY-HINT "1x:"
    STATUS       curr= ent
    DESCRIPTION
        "Represents media- or physical-level addresses."
    SYNTAX       OCTET STRING

MacAddress ::=3D TEXTUAL-CONVENTION
    DISPLAY-HINT "1x:"
    STATUS       curr= ent
    DESCRIPTION
        "Represents an 802 MAC address represented in the
       =   `canonical' order defined by IEEE 802.1a, i.e., as if it
       =   were transmitted least significant bit first, even though
         802.5 (in contrast to other 802.x protocols) requires MAC
       =   addresses to be transmitted most significant bit first."
    SYNTAX       OCTET STRING

TruthValue ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "Represents a boolean value."
    SYNTAX       INTE= GER {
        =          true(1),
        =          false(2)
        =        }

TestAndIncr ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "Represents integer-valued information used for atomic
         opera= tions.  When the management protocol is us= ed to specify
       =   that an object instance having this syntax is to be
       =   modified, the new value supplied via the management protocol
       =   must precisely match the value presently held by the
       =   instance.  If not, the management protocol set operation
       =   fails with an error of `inconsistentValue'.  Otherwise, if
       =   the current value is the maximum value of 2^31-1 (2147483647
       =   decimal), then the value held by the instance is wrapped to
       =   zero; otherwise, the value held by the instance is
       =   incremented by one.  (N= ote that regardless of whether the
       =   management protocol set operation succeeds, the variable-
       =   binding in the request and response PDUs are identical.)

       =   The value of the ACCESS clause for objects having this
       =   syntax is either `read-write' or `read-create'.  When an
       =   instance of a columnar object having this syntax is created,
       =   any value may be supplied via the management protocol.

       =   When the network management portion of the system is re-
       =   initialized, the value of every object instance having this
       =   syntax must either be incremented from its value prior to
       =   the re-initialization, or (if the value prior to the re-
       =   initialization is unknown) be set to a pseudo-randomly
       =   generated value."
    SYNTAX       INTEGER

AutonomousType ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "Represents an independently extensible type identification
       =   value.  It may, for exa= mple, indicate a particular sub-tree
       =   with further MIB definitions, or define a particular type of
       =   protocol or hardware."
    SYNTAX       OBJE= CT IDENTIFIER

InstancePointer ::=3D TEXTUAL-CONVENTION
    STATUS       obsolete
    DESCRIPTION
        "A pointer to either a specific instance of a MIB object or
       =   a conceptual row of a MIB table in the managed device.  In
       =   the latter case, by convention, it is the name of the
       =   particular instance of the first accessible columnar object
       =   in the conceptual row.

       =   The two uses of this textual convention are replaced by
       =   VariablePointer and RowPointer, respectively."
    SYNTAX       OBJE= CT IDENTIFIER

VariablePointer ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A pointer to a specific object instance.  For example,
       =   sysContact.0 or ifInOctets.3."
    SYNTAX       OBJE= CT IDENTIFIER

RowPointer ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "Represents a pointer to a conceptual row.  The value is the
       =   name of the instance of the first accessible columnar object
       =   in the conceptual row.

       =   For example, ifIndex.3 would point to the 3rd row in the
       =   ifTable (note that if ifIndex were not-accessible, then
       =   ifDescr.3 would be used instead)."
    SYNTAX       OBJE= CT IDENTIFIER

RowStatus ::=3D TEXTUAL-CONVENTION
    STATUS       curr= ent
    DESCRIPTION
        "The RowStatus textual convention is used to manage the
        =          creation and deletion of conceptual rows, and is used as the
        =          value of the SYNTAX clause for the status column of a
        =          conceptual row (as described in Section 7.7.1 of [2].)

        =          The status column has six defined values:

        =             &nb= sp; - `active', which indicates that the conceptual row is
        =             &nb= sp; available for use by the managed device;

                =       - `notInService', which indicates that the conceptual
        =             &nb= sp; row exists in the agent, but is unavailable for use by
        =             &nb= sp; the managed device (see NOTE below);

        =             &nb= sp; - `notReady', which indicates that the conceptual row
        =             &nb= sp; exists in the agent, but is missing information
        =             &nb= sp; necessary in order to be available for use by the
        =             &nb= sp; managed device;

        =             &nb= sp; - `createAndGo', which is supplied by a management
        =             &nb= sp; station wishing to create a new instance of a
        =             &nb= sp; conceptual row and to have its status automatically set
        =             &nb= sp; to active, making it available for use by the managed
        =            =    device;

        =             &nb= sp; - `createAndWait', which is supplied by a management
        =             &nb= sp; station wishing to create a new instance of a
        =             &nb= sp; conceptual row (but not make it available for use by
        =               the managed device); and,

        =             &nb= sp; - `destroy', which is supplied by a management station
        =             &nb= sp; wishing to delete all of the instances associated with
        =             &nb= sp; an existing conceptual row.

        =          Whereas five of the six values (all except `notReady') may
        =          be specified in a management protocol set operation, only
        =          three values will be returned in response to a management
        =          protocol retrieval operation:  `notReady', `notInService' or
        =          `active'.  That is, when queried, an existing conceptual row
        =          has only three states:  it is either available for use by
        =          the managed device (the status column has value `active');
        =          it is not available for use by the managed device, though
        =          the agent has sufficient information to make it so (the
        =          status column has value `notInService'); or, it is not
        =          available for use by the managed device, and an attempt to
        =          make it so would fail because the agent has insufficient
        =          information (the state column has value `notReady').
        =             &nb= sp;            =          NOTE WELL

        =               This textual convention may be used for a MIB table,
        =             &nb= sp; irrespective of whether the values of that table's
        =             &nb= sp; conceptual rows are able to be modified while it is
        =             &nb= sp; active, or whether its conceptual rows must be taken
        =             &nb= sp; out of service in order to be modified.  That is, it is
        =             &nb= sp; the responsibility of the DESCRIPTION clause of the
        =             &nb= sp; status column to specify whether the status column must
           =            not be `active' in order for the value of some other
        =             &nb= sp; column of the same conceptual row to be modified.  If
        =             &nb= sp; such a specification is made, affected columns may be
        =             &nb= sp; changed by an SNMP set PDU if the RowStatus would not
        =             &nb= sp; be equal to `active' either immediately before or after
        =             &nb= sp; processing the PDU.  In= other words, if the PDU also
        =             &nb= sp; contained a varbind that would change the RowStatus
        =             &nb= sp; value, the column in question may be changed if the
        =             &nb= sp; RowStatus was not equal to `active' as the PDU was
        =             &nb= sp; received, or if the varbind sets the status to a value
        =               other than 'active'.

        =          Also note that whenever any elements of a row exist, the
        =          RowStatus column must also exist.
        =          To summarize the effect of having a conceptual row with a
        =          status column having a SYNTAX clause value of RowStatus,
        =          consider the following state diagram:

        =             &nb= sp;            =              STATE
        =             &nb= sp;  +--------------+-----------+-------------+-------------
        =             &nb= sp;  |      A     &nbs= p; |     B<= span style=3D'mso-spacerun:yes'>    
|      C      |      D
        =             &nb= sp;  |        =       |status col.|status column|
        =             &nb= sp;  |status column |    is     |=       is     |status column        =   ACTION         |does not exist|   notRe= ady | notInService|   is active
       =   --------------+--------------+-----------+-------------+------------= -
       =   set status     |noError     ->D|inconsist- |inconsistent-|inconsistent-
       =   column to      |      &nbs= p; or      |=    entValue|         Value|      = ;   Value
         createAndGo=    |inconsistent- |         =    |         =      |
        =             &nb= sp;  |          Value|         =    |         =      |
       =   --------------+--------------+-----------+-------------+------------= -
       =   set status     |noError   see 1|inconsi= st- |inconsistent-|inconsistent-
       =   column to      |      &nbs= p; or      |=    entValue|         Value|      = ;   Value
       =   createAndWait |wrongValue     |         =    |         =      |
       =   --------------+--------------+-----------+-------------+------------= -
         set status    |inconsist= ent- |inconsist- |noError      |noError        =   column to      |          Value|    entValue|=         =      |
       =   active         |         =       |         =    |         =      |
        =             &nb= sp;  |         =       |      or=     |           =    |
        =             &nb= sp;  |         =       |         =    |         =      |
        =             &nb= sp;  |         =       |see 2    ->D|         =  
->D|     &nbs= p;     ->D
       =   --------------+--------------+-----------+-------------+------------= -
       =   set status     |inconsistent- |inconsist- |noError       |noError    ->C
       =   column to      |          Value|    entValue|=         =      |
       =   notInService   |         =       |         =    |         =      |
        =             &nb= sp;  |         =       |      or=     |         =      |       or
        =             &nb= sp;  |         =       |         =    |         =      |
        =             &nb= sp;  |         =       |see 3    ->C|         =   ->C|wrongValue
       =   --------------+--------------+-----------+-------------+------------= -
       =   set status     |noError       |noError    |noError    &nb= sp; |noError
       =   column to     |        =       |        =    |        =      |
       =   destroy       |         =   
->A|         ->A|         =   ->A|     &nbs= p;     ->A
       =   --------------+--------------+-----------+-------------+------------= -
       =   set any other |see 4          |noError     |noError     &nb= sp; |see 5
       =   column to some|         =       |         =    |         =      |
       =   value          |         =       |       see 1|         =   ->C|         =   ->D
       =   --------------+--------------+-----------+-------------+------------= -

        =          (1) goto B or C, depending on information available to the
        =          agent.
        =          (2) if other variable bindings included in the same PDU,
        =          provide values for all columns which are missing but
        =          required, then return noError and goto D.

        =          (3) if other variable bindings included in the same PDU,
        =          provide values for all columns which are missing but
                =  required, then return noError and goto C.

        =          (4) at the discretion of the agent, the return value may be
        =          either:

        =             &nb= sp; inconsistentName:   beca= use the agent does not choose to
        =             &nb= sp; create such an instance when the corresponding
        =             &nb= sp; RowStatus instance does not exist, or

        =             &nb= sp; inconsistentValue:   if = the supplied value is
        =             &nb= sp; inconsistent with the state of some other MIB object's
             =          value, or

        =             &nb= sp; noError: because the agent chooses to create the
        =             &nb= sp; instance.

        =          If noError is returned, then the instance of the status
        =          column must also be created, and the new state is B or C,
        =          depending on the information available to the agent.   If
        =          inconsistentName or inconsistentValue is returned, the row
        =          remains in state A.

        =          (5) depending on the MIB definition for the column/table,
        =          either noError or inconsistentValue may be returned.

        =          NOTE: Other processing of the set request may result in a
        =          response other than noError being returned, e.g.,
        =          wrongValue, noCreation, etc.

        =             &nb= sp;            =   Conceptual Row Creation

        =          There are four potential interactions when creating a
        =          conceptual row:   select= ing an instance-identifier which is
        =          not in use; creating the conceptual row; initializing any
        =          objects for which the agent does not supply a default; and,
        =          making the conceptual row available for use by the managed
        =          device.
        =          Interaction 1: Selecting an Instance-Identifier

        =          The algorithm used to select an instance-identifier varies
        =          for each conceptual row.   In some cases, the instance-
        =          identifier is semantically significant, e.g., the
        =          destination address of a route, and a management station
        =          selects the instance-identifier according to the semantics.

        =          In other cases, the instance-identifier is used solely to
        =          distinguish conceptual rows, and a management station
        =          without specific knowledge of the conceptual row might
        =          examine the instances present in order to determine an
        =          unused instance-identifier.  (This approach may be used, but
        =          it is often highly sub-optimal; however, it is also a
        =          questionable practice for a naive management station to
        =          attempt conceptual row creation.)

        =          Alternately, the MIB module which defines the conceptual row
        =          might provide one or more objects which provide assistance
        =          in determining an unused instance-identifier.  For example,
        =          if the conceptual row is indexed by an integer-value, then
        =          an object having an integer-valued SYNTAX clause might be
        =          defined for such a purpose, allowing a management station to
        =          issue a management protocol retrieval operation.  In order
        =          to avoid unnecessary collisions between competing management
        =          stations, `adjacent' retrievals of this object should be
        =          different.

        =          Finally, the management station could select a pseudo-random
        =          number to use as the index.  In the event that this index
        =          was already in use and an inconsistentValue was returned in
        =          response to the management protocol set operation, the
        =          management station should simply select a new pseudo-random
        =          number and retry the operation.

        =          A MIB designer should choose between the two latter
        =          algorithms based on the size of the table (and therefore the
        =          efficiency of each algorithm).  For tables in which a large
        =          number of entries are expected, it is recommended that a MIB
        =          object be defined that returns an acceptable index for
        =          creation.  For tables w= ith small numbers of entries, it is
        =          recommended that the latter pseudo-random index mechanism be
        =          used.
        =          Interaction 2: Creating the Conceptual Row

        =          Once an unused instance-identifier has been selected, the
           =       management station determines if it wishes to create and
        =          activate the conceptual row in one transaction or in a
        =          negotiated set of interactions.

        =          Interaction 2a: Creating and Activating the Conceptual Row

        =          The management station must first determine the column
        =          requirements, i.e., it must determine those columns for
        =          which it must or must not provide values.  Depending on the
        =          complexity of the table and the management station's
        =          knowledge of the agent's capabilities, this determination
        =          can be made locally by the management station.  Alternately,
        =          the management station issues a management protocol get
        =          operation to examine all columns in the conceptual row that
        =          it wishes to create.  In response, for each column, there
        =          are three possible outcomes:

        =             &nb= sp; - a value is returned, indicating that some other
        =             &nb= sp; management station has already created this conceptual
        =             &nb= sp; row.  We return to interaction 1.

        =             &nb= sp; - the exception `noSuchInstance' is returned,
        =               indicating= that the agent implements the object-type
        =             &nb= sp; associated with this column, and that this column in at
        =             &nb= sp; least one conceptual row would be accessible in the MIB
        =             &nb= sp; view used by the retrieval were it to exist. For those
        =             &nb= sp; columns to which the agent provides read-create access,
        =             &nb= sp; the `noSuchInstance' exception tells the management
        =             &nb= sp; station that it should supply a value for this column
        =             &nb= sp; when the conceptual row is to be created.

        =             &nb= sp; - the exception `noSuchObject' is returned, indicating
        =             &nb= sp; that the agent does not implement the object-type
        =             &nb= sp; associated with this column or that there is no
        =             &nb= sp; conceptual row for which this column would be
        =             &nb= sp; accessible in the MIB view used by the retrieval.  As
        =             &nb= sp; such, the management station can not issue any
        =           =     management protocol set operations to create an
        =             &nb= sp; instance of this column.

        =          Once the column requirements have been determined, a
        =          management protocol set operation is accordingly issued.
            =      This operation also sets the new instance of the status
        =          column to `createAndGo'.
        =          When the agent processes the set operation, it verifies that
        =          it has sufficient information to make the conceptual row
        =          available for use by the managed device.  The information
        =          available to the agent is provided by two sources:  the
        =          management protocol set operation which creates the
        =          conceptual row, and, implementation-specific defaults
        =          supplied by the agent (note that an agent must provide
        =          implementation-specific defaults for at least those objects
        =          which it implements as read-only).&= nbsp; If there is sufficient
        =          information available, then the conceptual row is created, a
        =          `noError' response is returned, the status column is set to
        =          `active', and no further interactions are necessary (i.e.,
        =          interactions 3 and 4 are skipped).&= nbsp; If there is insufficient
        =          information, then the conceptual row is not created, and the
        =          set operation fails with an error of `inconsistentValue'.
        =          On this error, the management station can issue a management
        =          protocol retrieval operation to determine if this was
        =          because it failed to specify a value for a required column,
        =          or, because the selected instance of the status column
        =          already existed.  In the latter case, we return to
        =          interaction 1.  In the = former case, the management station
        =          can re-issue the set operation with the additional
        =          information, or begin interaction 2 again using
        =          `createAndWait' in order to negotiate creation of the
        =          conceptual row.

        =             &nb= sp;            =          NOTE WELL

        =             &nb= sp; Regardless of the method used to determine the column
         =              requirements, it is possible that the management
        =             &nb= sp; station might deem a column necessary when, in fact,
        =             &nb= sp; the agent will not allow that particular columnar
        =             &nb= sp; instance to be created or written.&= nbsp; In this case, the
        =             &nb= sp; management protocol set operation will fail with an
        =             &nb= sp; error such as `noCreation' or `notWritable'.  In this
        =             &nb= sp; case, the management station decides whether it needs
        =             &nb= sp; to be able to set a value for that particular columnar
        =             &nb= sp; instance.  If not, the management station re-issues the
        =             &nb= sp; management protocol set operation, but without setting
        =               a value for that particular columnar instance;
        =             &nb= sp; otherwise, the management station aborts the row
        =             &nb= sp; creation algorithm.

        =          Interaction 2b: Negotiating the Creation of the Conceptual
        =          Row

        =          The management station issues a management protocol set
        =          operation which sets the desired instance of the status
        =          column to `createAndWait'.  If the agent is unwilling to
        =          process a request of this sort, the set operation fails with
        =          an error of `wrongValue'.  (As a consequence, such an agent
        =          must be prepared to accept a single management protocol set
        =          operation, i.e., interaction 2a above, containing all of the
        =          columns indicated by its column requirements.)  Otherwise,
        =          the conceptual row is created, a `noError' response is
        =          returned, and the status column is immediately set to either
            =      `notInService' or `notReady', depending on whether it has
        =          sufficient information to make the conceptual row available
        =          for use by the managed device.  If there is sufficient
        =          information available, then the status column is set to
        =          `notInService'; otherwise, if there is insufficient
        =          information, then the status column is set to `notReady'.
        =          Regardless, we proceed to interaction 3.

        =          Interaction 3: Initial= izing non-defaulted Objects

        =          The management station must now determine the column
        =          requirements.  It issue= s a management protocol get operation
        =          to examine all columns in the created conceptual row.  In
        =          the response, for each column, there are three possible
        =          outcomes:

        =             &nb= sp; - a value is returned, indicating that the agent
        =             &nb= sp; implements the object-type associated with this column
        =             &nb= sp; and had sufficient information to provide a value.  For
        =             &nb= sp; those columns to which the agent provides read-create
        =             &nb= sp; access (and for which the agent allows their values to
        =              =  be changed after their creation), a value return tells
        =             &nb= sp; the management station that it may issue additional
        =             &nb= sp; management protocol set operations, if it desires, in
        =             &nb= sp; order to change the value associated with this column.

        =             &nb= sp; - the exception `noSuchInstance' is returned,
        =             &nb= sp; indicating that the agent implements the object-type
        =             &nb= sp; associated with this column, and that this column in at
        =             &nb= sp; least one conceptual row would be accessible in the MIB
        =             &nb= sp; view used by the retrieval were it to exist. However,
        =             &nb= sp; the agent does not have sufficient information to
        =             &nb= sp; provide a value, and until a value is provided, the
        =             &nb= sp; conceptual row may not be made available for use by the
        =             &nb= sp; managed device.  For th= ose columns to which the agent
        =             &nb= sp; provides read-create access, the `noSuchInstance'
        =             &nb= sp; exception tells the management station that it must
        =             &nb= sp; issue additional management protocol set operations, in
        =             &nb= sp; order to provide a value associated with this column.
        =              =  - the exception `noSuchObject' is returned, indicating
        =             &nb= sp; that the agent does not implement the object-type
        =             &nb= sp; associated with this column or that there is no
        =             &nb= sp; conceptual row for which this column would be
        =             &nb= sp; accessible in the MIB view used by the retrieval.  As
        =             &nb= sp; such, the management station can not issue any
        =             &nb= sp; management protocol set operations to create an
        =             &nb= sp; instance of this column.

        =          If the value associated with the status column is
        =          `notReady', then the management station must first deal with
        =          all `noSuchInstance' columns, if any.  Having done so, the
        =          value of the status column becomes `notInService', and we
        =          proceed to interaction 4.

        =          Interaction 4: Making the Conceptual Row Available

        =          Once the management station is satisfied with the values
            =      associated with the columns of the conceptual row, it issues
        =          a management protocol set operation to set the status column
        =          to `active'.  If the ag= ent has sufficient information to
        =          make the conceptual row available for use by the managed
        =          device, the management protocol set operation succeeds (a
        =          `noError' response is returned).&nb= sp; Otherwise, the management
        =          protocol set operation fails with an error of
        =          `inconsistentValue'.

        =             &nb= sp;            =          NOTE WELL

        =             &nb= sp; A conceptual row having a status column with value
        =             &nb= sp; `notInService' or `notReady' is unavailable to the
        =               managed device.  As such, it is possib= le for the
        =             &nb= sp; managed device to create its own instances during the
        =             &nb= sp; time between the management protocol set operation
        =             &nb= sp; which sets the status column to `createAndWait' and the
        =             &nb= sp; management protocol set operation which sets the status
        =             &nb= sp; column to `active'.  In= this case, when the management
        =             &nb= sp; protocol set operation is issued to set the status
         =              column to `active', the values held in the agent
        =             &nb= sp; supersede those used by the managed device.

        =          If the management station is prevented from setting the
        =          status column to `active' (e.g., due to management station
        =          or network failure) the conceptual row will be left in the
        =          `notInService' or `notReady' state, consuming resources
        =          indefinitely.  The agen= t must detect conceptual rows that
          =        have been in either state for an abnormally long period of
        =          time and remove them.  = It is the responsibility of the
        =          DESCRIPTION clause of the status column to indicate what an
        =          abnormally long period of time would be.  This period of
        =          time should be long enough to allow for human response time
        =          (including `think time') between the creation of the
        =          conceptual row and the setting of the status to `active'.
        =          In the absense of such information in the DESCRIPTION
        =          clause, it is suggested that this period be approximately 5
        =          minutes in length.  This removal action applies not only to
        =          newly-created rows, but also to previously active rows which
        =          are set to, and left in, the notInService state for a
        =          prolonged period exceeding that which is considered normal
        =          for such a conceptual row.

        =           =             &nb= sp;   Conceptual Row Suspension

        =          When a conceptual row is `active', the management station
        =          may issue a management protocol set operation which sets the
        =          instance of the status column to `notInService'.  If the
        =          agent is unwilling to do so, the set operation fails with an
        =          error of `wrongValue'.  Otherwise, the conceptual row is
        =          taken out of service, and a `noError' response is returned.
             =     It is the responsibility of the DESCRIPTION clause of the
        =          status column to indicate under what circumstances the
        =          status column should be taken out of service (e.g., in order
        =          for the value of some other column of the same conceptual
        =          row to be modified).

        =             &nb= sp;            =   Conceptual Row Deletion

        =          For deletion of conceptual rows, a management protocol set
        =          operation is issued which sets the instance of the status
        =          column to `destroy'.  T= his request may be made regardless of
        =          the current value of the status column (e.g., it is possible
        =          to delete conceptual rows which are either `notReady',
        =          `notInService' or `active'.)  If the operation succeeds,
        =          then all instances associated with the conceptual row are
        =          immediately removed."
    SYNTAX       INTE= GER {
        =          active(1),
                =  notInService(2),
        =          notReady(3),
        =          createAndGo(4),
        =          createAndWait(5),
        =          destroy(6)
        =        }

TimeStamp ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "The value of the sysUpTime object at which a specific
       =   occurrence happened.  T= he specific occurrence must be
       =   defined in the description of any object defined using this
       =   type."
    SYNTAX       TimeTicks

TimeInterval ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A period of time, measured in units of 0.01 seconds."
    SYNTAX       INTEGER

DateAndTime ::=3D TEXTUAL-CONVENTION
    DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
    STATUS       current
    DESCRIPTION
        "A date-time specification.

       =   field  octets  contents        =           range
       =   -----  ------  --------        =           -----
        =    1      1-2   year        =             &nb= sp; 0..65536
        =    2     &nbs= p; 3    month         =      
       1..12
        =    3     &nbs= p; 4    day        =             &nb= sp;  1..31
        =    4     &nbs= p; 5    hour        =             &nb= sp; 0..23
        =    5     &nbs= p; 6    minutes<= span style=3D'mso-spacerun:yes'>        =           
0..59
        =    6     &nbs= p; 7    seconds<= span style=3D'mso-spacerun:yes'>        =           
0..60
        =                 (use 60 for leap-second)
        =    7     &nbs= p; 8    deci-sec= onds        =       0..9
        =    8     &nbs= p; 9    directio= n from UTC      &nb= sp; '+' / '-'
        =    9      10    hours f= rom UTC        =     0..11
        =   10      11    minutes= from UTC        =   0..59

       =   For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
       =   displayed as:

        =             &nb= sp;     1992-5-26,13:30:15.0,-4:0

       =   Note that if only local time is known, then timezone
       =   information (fields 8-10) is not present."
    SYNTAX       OCTET STRING

StorageType ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "Describes the memory realization of a conceptual row.  A
       =   row which is volatile(2) is lost upon reboot.  A row which
         is either nonVolatile(= 3), permanent(4) or readOnly(5), is
       =   backed up by stable storage.  A row which is permanent(4)
       =   can be changed but not deleted.&nbs= p; A row which is readOnly(5)
       =   cannot be changed nor deleted.

       =   If the value of an object with this syntax is either
       =   permanent(4) or readOnly(5), it cannot be modified.
       =   Conversely, if the value is either other(1), volatile(2) or
       =   nonVolatile(3), it cannot be modified to be permanent(4) or
       =   readOnly(5).

       =   Every usage of this textual convention is required to
       =   specify the columnar objects which a permanent(4) row must
       =   at a minimum allow to be writable."
    SYNTAX       INTE= GER {
        =          other(1),
        =          volatile(2),
        =          nonVolatile(3),
        =          permanent(4),
        =         
readOnly(5)
        =        }

TDomain ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "Denotes a kind of transport service.

       =   Some possible values, such as snmpUDPDomain, are defined in
       =   'Transport Mappings for Version 2 of the Simple Network
       =   Management Protocol (SNMPv2)'."
    SYNTAX       OBJE= CT IDENTIFIER

TAddress ::=3D TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "Denotes a transport service address.

       =   For snmpUDPDomain, a TAddress is 6 octets long, the initial 4
       =   octets containing the IP-address in network-byte order and the
       =   last 2 containing the UDP port in network-byte order.  Consult
       =   'Transport Mappings for Version 2 of the Simple Network
       =   Management Protocol (SNMPv2)' for further information on
       =   snmpUDPDomain."
    SYNTAX       OCTET STRING

END