WebApps/Observium_CE
1
0
Fork 0
Code Pull Requests Activity
Observium_CE/mibs/rfc/SNMPv2-TC-v1

719 lines
32 KiB
Plaintext
Raw Blame History

-- MIB created 10/09/96 17:50:16, by
-- SMICng version 2.0.10(PRO)(MS-DOS32), October 9, 1996.
-- version 1.1, modified 09/04/98
SNMPv2-TC-v1 DEFINITIONS ::= BEGIN
-- From file: "rfc1903.sm2"
-- Compile options "G A"
IMPORTS
TimeTicks
FROM RFC1155-SMI;
--?? No macro TEXTUAL-CONVENTION in SNMPv1
DisplayString ::= OCTET STRING(SIZE(0..255))
-- TEXTUAL-CONVENTION
-- DspHint
-- 255a
-- Status
-- mandatory
-- Descr
-- 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.
PhysAddress ::= OCTET STRING
-- TEXTUAL-CONVENTION
-- DspHint
-- 1x:
-- Status
-- mandatory
-- Descr
-- Represents media- or physical-level addresses.
MacAddress ::= OCTET STRING(SIZE(6))
-- TEXTUAL-CONVENTION
-- DspHint
-- 1x:
-- Status
-- mandatory
-- Descr
-- 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.
TruthValue ::= INTEGER {
true(1),
false(2)
}
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- Represents a boolean value.
TestAndIncr ::= INTEGER(0..2147483647)
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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.
AutonomousType ::= OBJECT IDENTIFIER
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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.
InstancePointer ::= OBJECT IDENTIFIER
-- TEXTUAL-CONVENTION
-- Status
-- obsolete
-- Descr
-- 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.
VariablePointer ::= OBJECT IDENTIFIER
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- A pointer to a specific object instance. For example,
-- sysContact.0 or ifInOctets.3.
RowPointer ::= OBJECT IDENTIFIER
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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).
RowStatus ::= INTEGER {
active(1),
notInService(2),
notReady(3),
createAndGo(4),
createAndWait(5),
destroy(6)
}
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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);
--
-- - `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;
--
-- - `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 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| ->D| ->D
-- ==============+==============+===========+=============+=============
-- set status |inconsistent- |inconsist- |noError |noError ->C
-- column to | Value| entValue| |
-- notInService | | | |
-- | | or | | or
-- | | | |
-- | |see 3 ->C| ->C|wrongValue
-- ==============+==============+===========+=============+=============
-- set status |noError |noError |noError |noError
-- column to | | | |
-- destroy | ->A| ->A| ->A| ->A
-- ==============+==============+===========+=============+=============
-- 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, 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:
--
-- 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.
--
-- NOTE: Other processing 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 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 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.
--
--
-- 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).
--
--
-- 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.
TimeStamp ::= TimeTicks
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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.
TimeInterval ::= INTEGER(0..2147483647)
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- A period of time, measured in units of 0.01 seconds.
DateAndTime ::= OCTET STRING(SIZE(11))
-- TEXTUAL-CONVENTION
-- DspHint
-- 2d-1d-1d,1d:1d:1d.1d,1a1d:1d
-- Status
-- mandatory
-- Descr
-- 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..11
-- 10 11 minutes from UTC 0..59
--
-- 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.
StorageType ::= INTEGER {
other(1),
volatile(2),
nonVolatile(3),
permanent(4),
readOnly(5)
}
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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 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.
TDomain ::= OBJECT IDENTIFIER
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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)'.
TAddress ::= OCTET STRING(SIZE(1..255))
-- TEXTUAL-CONVENTION
-- Status
-- mandatory
-- Descr
-- 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.
END
View Git Blame Copy Permalink