snmp: T3606: Install MIBs into well known location

FRR also expects the MIBs in /usr/share/snmp/mibs

1 files changed, 0 insertions, 772 deletions

diff --git a/data/mibs/SNMPv2-TC.txt b/data/mibs/SNMPv2-TC.txt
deleted file mode 100644
index 860bf71ee..000000000
--- a/data/mibs/SNMPv2-TC.txt
+++ /dev/null
@@ -1,772 +0,0 @@
-SNMPv2-TC DEFINITIONS ::= BEGIN
-
-IMPORTS
-    TimeTicks         FROM SNMPv2-SMI;
-
--- definition of textual conventions
-
-TEXTUAL-CONVENTION MACRO ::=
-
-BEGIN
-    TYPE NOTATION ::=
-                  DisplayPart
-                  "STATUS" Status
-                  "DESCRIPTION" Text
-                  ReferPart
-                  "SYNTAX" Syntax
-
-    VALUE NOTATION ::=
-                   value(VALUE Syntax)      -- adapted ASN.1
-
-    DisplayPart ::=
-                  "DISPLAY-HINT" Text
-                | empty
-
-    Status ::=
-                  "current"
-                | "deprecated"
-                | "obsolete"
-
-    ReferPart ::=
-                  "REFERENCE" Text
-                | empty
-
-    -- a character string as defined in [2]
-    Text ::= value(IA5String)
-
-    Syntax ::=   -- Must be one of the following:
-                       -- a base type (or its refinement), or
-                       -- a BITS pseudo-type
-                  type
-                | "BITS" "{" NamedBits "}"
-
-    NamedBits ::= NamedBit
-                | NamedBits "," NamedBit
-
-    NamedBit ::=  identifier "(" number ")" -- number is nonnegative
-
-END
-
-DisplayString ::= TEXTUAL-CONVENTION
-    DISPLAY-HINT "255a"
-    STATUS       current
-    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 characters (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 this 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 (SIZE (0..255))
-
-PhysAddress ::= TEXTUAL-CONVENTION
-    DISPLAY-HINT "1x:"
-    STATUS       current
-    DESCRIPTION
-            "Represents media- or physical-level addresses."
-    SYNTAX       OCTET STRING
-
-MacAddress ::= TEXTUAL-CONVENTION
-    DISPLAY-HINT "1x:"
-    STATUS       current
-    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 (SIZE (6))
-
-TruthValue ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-            "Represents a boolean value."
-    SYNTAX       INTEGER { true(1), false(2) }
-
-TestAndIncr ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-            "Represents integer-valued information used for atomic
-            operations.  When the management protocol is used 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.  (Note 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 (0..2147483647)
-
-AutonomousType ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-            "Represents an independently extensible type identification
-            value.  It may, for example, indicate a particular sub-tree
-            with further MIB definitions, or define a particular type of
-            protocol or hardware."
-    SYNTAX       OBJECT IDENTIFIER
-
-InstancePointer ::= 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       OBJECT IDENTIFIER
-
-VariablePointer ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-            "A pointer to a specific object instance.  For example,
-            sysContact.0 or ifInOctets.3."
-    SYNTAX       OBJECT IDENTIFIER
-
-RowPointer ::= 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       OBJECT IDENTIFIER
-
-RowStatus ::= TEXTUAL-CONVENTION
-    STATUS       current
-    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:
-
-                 - `active', which indicates that the conceptual row is
-                 available for use by the managed device;
-
-                 - `notInService', which indicates that the conceptual
-                 row exists in the agent, but is unavailable for use by
-                 the managed device (see NOTE below); 'notInService' has
-                 no implication regarding the internal consistency of
-                 the row, availability of resources, or consistency with
-                 the current state of the managed device;
-
-                 - `notReady', which indicates that the conceptual row
-                 exists in the agent, but is missing information
-                 necessary in order to be available for use by the
-                 managed device (i.e., one or more required columns in
-                 the conceptual row have not been instanciated);
-
-                 - `createAndGo', which is supplied by a management
-                 station wishing to create a new instance of a
-                 conceptual row and to have its status automatically set
-                 to active, making it available for use by the managed
-                 device;
-
-                 - `createAndWait', which is supplied by a management
-                 station wishing to create a new instance of a
-                 conceptual row (but not make it available for use by
-                 the managed device); and,
-                 - `destroy', which is supplied by a management station
-                 wishing to delete all of the instances associated with
-                 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 attempt 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').
-
-                                     NOTE WELL
-
-                 This textual convention may be used for a MIB table,
-                 irrespective of whether the values of that table's
-                 conceptual rows are able to be modified while it is
-                 active, or whether its conceptual rows must be taken
-                 out of service in order to be modified.  That is, it is
-                 the responsibility of the DESCRIPTION clause of the
-                 status column to specify whether the status column must
-                 not be `active' in order for the value of some other
-                 column of the same conceptual row to be modified.  If
-                 such a specification is made, affected columns may be
-                 changed by an SNMP set PDU if the RowStatus would not
-                 be equal to `active' either immediately before or after
-                 processing the PDU.  In other words, if the PDU also
-                 contained a varbind that would change the RowStatus
-                 value, the column in question may be changed if the
-                 RowStatus was not equal to `active' as the PDU was
-                 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:
-
-                                         STATE
-              +--------------+-----------+-------------+-------------
-              |      A       |     B     |      C      |      D
-              |              |status col.|status column|
-              |status column |    is     |      is     |status column
-    ACTION    |does not exist|  notReady | notInService|  is active
---------------+--------------+-----------+-------------+-------------
-set status    |noError    ->D|inconsist- |inconsistent-|inconsistent-
-column to     |       or     |   entValue|        Value|        Value
-createAndGo   |inconsistent- |           |             |
-              |         Value|           |             |
---------------+--------------+-----------+-------------+-------------
-set status    |noError  see 1|inconsist- |inconsistent-|inconsistent-
-column to     |       or     |   entValue|        Value|        Value
-createAndWait |wrongValue    |           |             |
---------------+--------------+-----------+-------------+-------------
-set status    |inconsistent- |inconsist- |noError      |noError
-column to     |         Value|   entValue|             |
-active        |              |           |             |
-              |              |     or    |             |
-              |              |           |             |
-              |              |see 2   ->D|see 8     ->D|          ->D
---------------+--------------+-----------+-------------+-------------
-set status    |inconsistent- |inconsist- |noError      |noError   ->C
-column to     |         Value|   entValue|             |
-notInService  |              |           |             |
-              |              |     or    |             |      or
-              |              |           |             |
-              |              |see 3   ->C|          ->C|see 6
---------------+--------------+-----------+-------------+-------------
-set status    |noError       |noError    |noError      |noError   ->A
-column to     |              |           |             |      or
-destroy       |           ->A|        ->A|          ->A|see 7
---------------+--------------+-----------+-------------+-------------
-set any other |see 4         |noError    |noError      |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, and all columns have acceptable values, then
-            return noError and goto D.
-
-            (3) if other variable bindings included in the same PDU,
-            provide legal 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:
-
-                 inconsistentName:  because the agent does not choose to
-                 create such an instance when the corresponding
-                 RowStatus instance does not exist, or
-
-                 inconsistentValue:  if the supplied value is
-                 inconsistent with the state of some other MIB object's
-                 value, or
-
-                 noError: because the agent chooses to create the
-                 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.
-
-            (6) the return value can indicate one of the following
-            errors:
-
-                 wrongValue: because the agent does not support
-                 notInService (e.g., an agent which does not support
-                 createAndWait), or
-
-                 inconsistentValue: because the agent is unable to take
-                 the row out of service at this time, perhaps because it
-                 is in use and cannot be de-activated.
-
-            (7) the return value can indicate the following error:
-
-                 inconsistentValue: because the agent is unable to
-                 remove the row at this time, perhaps because it is in
-                 use and cannot be de-activated.
-
-            (8) the transition to D can fail, e.g., if the values of the
-            conceptual row are inconsistent, then the error code would
-            be inconsistentValue.
-
-            NOTE: Other processing of (this and other varbinds of) the
-            set request may result in a response other than noError
-            being returned, e.g., wrongValue, noCreation, etc.
-
-                              Conceptual Row Creation
-
-            There are four potential interactions when creating a
-            conceptual row:  selecting 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 with 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:
-
-                 - a value is returned, indicating that some other
-                 management station has already created this conceptual
-                 row.  We return to interaction 1.
-
-                 - the exception `noSuchInstance' is returned,
-                 indicating that the agent implements the object-type
-                 associated with this column, and that this column in at
-                 least one conceptual row would be accessible in the MIB
-                 view used by the retrieval were it to exist. For those
-                 columns to which the agent provides read-create access,
-                 the `noSuchInstance' exception tells the management
-                 station that it should supply a value for this column
-                 when the conceptual row is to be created.
-
-                 - the exception `noSuchObject' is returned, indicating
-                 that the agent does not implement the object-type
-                 associated with this column or that there is no
-                 conceptual row for which this column would be
-                 accessible in the MIB view used by the retrieval.  As
-                 such, the management station can not issue any
-                 management protocol set operations to create an
-                 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).  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).  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.
-
-                                     NOTE WELL
-
-                 Regardless of the method used to determine the column
-                 requirements, it is possible that the management
-                 station might deem a column necessary when, in fact,
-                 the agent will not allow that particular columnar
-                 instance to be created or written.  In this case, the
-                 management protocol set operation will fail with an
-                 error such as `noCreation' or `notWritable'.  In this
-                 case, the management station decides whether it needs
-                 to be able to set a value for that particular columnar
-                 instance.  If not, the management station re-issues the
-                 management protocol set operation, but without setting
-                 a value for that particular columnar instance;
-                 otherwise, the management station aborts the row
-                 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 (attempt 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: Initializing non-defaulted Objects
-
-            The management station must now determine the column
-            requirements.  It issues 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:
-
-                 - a value is returned, indicating that the agent
-                 implements the object-type associated with this column
-                 and had sufficient information to provide a value.  For
-                 those columns to which the agent provides read-create
-                 access (and for which the agent allows their values to
-                 be changed after their creation), a value return tells
-                 the management station that it may issue additional
-                 management protocol set operations, if it desires, in
-                 order to change the value associated with this column.
-
-                 - the exception `noSuchInstance' is returned,
-                 indicating that the agent implements the object-type
-                 associated with this column, and that this column in at
-                 least one conceptual row would be accessible in the MIB
-                 view used by the retrieval were it to exist. However,
-                 the agent does not have sufficient information to
-                 provide a value, and until a value is provided, the
-                 conceptual row may not be made available for use by the
-                 managed device.  For those columns to which the agent
-                 provides read-create access, the `noSuchInstance'
-                 exception tells the management station that it must
-                 issue additional management protocol set operations, in
-                 order to provide a value associated with this column.
-
-                 - the exception `noSuchObject' is returned, indicating
-                 that the agent does not implement the object-type
-                 associated with this column or that there is no
-                 conceptual row for which this column would be
-                 accessible in the MIB view used by the retrieval.  As
-                 such, the management station can not issue any
-                 management protocol set operations to create an
-                 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 agent 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).  Otherwise, the management
-            protocol set operation fails with an error of
-            `inconsistentValue'.
-
-                                     NOTE WELL
-
-                 A conceptual row having a status column with value
-                 `notInService' or `notReady' is unavailable to the
-                 managed device.  As such, it is possible for the
-                 managed device to create its own instances during the
-                 time between the management protocol set operation
-                 which sets the status column to `createAndWait' and the
-                 management protocol set operation which sets the status
-                 column to `active'.  In this case, when the management
-                 protocol set operation is issued to set the status
-                 column to `active', the values held in the agent
-                 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 agent 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 absence 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.
-
-                             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' or `inconsistentValue'.  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).
-
-                              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'.  This 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       INTEGER {
-                     -- the following two values are states:
-                     -- these values may be read or written
-                     active(1),
-                     notInService(2),
-                     -- the following value is a state:
-                     -- this value may be read, but not written
-                     notReady(3),
-                     -- the following three values are
-                     -- actions: these values may be written,
-                     --   but are never read
-                     createAndGo(4),
-                     createAndWait(5),
-                     destroy(6)
-                 }
-
-TimeStamp ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-            "The value of the sysUpTime object at which a specific
-            occurrence happened.  The specific occurrence must be
-
-            defined in the description of any object defined using this
-            type.
-
-            If sysUpTime is reset to zero as a result of a re-
-            initialization of the network management (sub)system, then
-            the values of all TimeStamp objects are also reset.
-            However, after approximately 497 days without a re-
-            initialization, the sysUpTime object will reach 2^^32-1 and
-            then increment around to zero; in this case, existing values
-            of TimeStamp objects do not change.  This can lead to
-            ambiguities in the value of TimeStamp objects."
-    SYNTAX       TimeTicks
-
-TimeInterval ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-            "A period of time, measured in units of 0.01 seconds."
-    SYNTAX       INTEGER (0..2147483647)
-
-DateAndTime ::= 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*                     0..65536
-              2       3    month                     1..12
-              3       4    day                       1..31
-              4       5    hour                      0..23
-              5       6    minutes                   0..59
-              6       7    seconds                   0..60
-                           (use 60 for leap-second)
-              7       8    deci-seconds              0..9
-              8       9    direction from UTC        '+' / '-'
-              9      10    hours from UTC*           0..13
-             10      11    minutes from UTC          0..59
-
-            * Notes:
-            - the value of year is in network-byte order
-            - daylight saving time in New Zealand is +13
-
-            For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
-            displayed as:
-
-                             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 (SIZE (8 | 11))
-
-StorageType ::= 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.  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 written.
-            Conversely, if the value is either other(1), volatile(2) or
-            nonVolatile(3), it cannot be modified to be permanent(4) or
-            readOnly(5).  (All illegal modifications result in a
-            'wrongValue' error.)
-
-            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       INTEGER {
-                     other(1),       -- eh?
-                     volatile(2),    -- e.g., in RAM
-                     nonVolatile(3), -- e.g., in NVRAM
-                     permanent(4),   -- e.g., partially in ROM
-                     readOnly(5)     -- e.g., completely in ROM
-                 }
-
-TDomain ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-          "Denotes a kind of transport service.
-
-          Some possible values, such as snmpUDPDomain, are defined in
-          the SNMPv2-TM MIB module.  Other possible values are defined
-          in other MIB modules."
-    REFERENCE    "The SNMPv2-TM MIB module is defined in RFC 1906."
-    SYNTAX       OBJECT IDENTIFIER
-
-TAddress ::= TEXTUAL-CONVENTION
-    STATUS       current
-    DESCRIPTION
-          "Denotes a transport service address.
-
-          A TAddress value is always interpreted within the context of a
-          TDomain value.  Thus, each definition of a TDomain value must
-          be accompanied by a definition of a textual convention for use
-          with that TDomain.  Some possible textual conventions, such as
-          SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM
-          MIB module.  Other possible textual conventions are defined in
-          other MIB modules."
-    REFERENCE    "The SNMPv2-TM MIB module is defined in RFC 1906."
-    SYNTAX       OCTET STRING (SIZE (1..255))
-
-END