diff options
Diffstat (limited to 'data/mibs/SNMPv2-TC.txt')
| -rw-r--r-- | data/mibs/SNMPv2-TC.txt | 772 |
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 |