SNMPv2-TC.txt
上传用户:wxp200602
上传日期:2007-10-30
资源大小:4028k
文件大小:37k
- 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