[457] | 1 | SNMPv2-TC DEFINITIONS ::= BEGIN
|
---|
| 2 |
|
---|
| 3 | IMPORTS
|
---|
| 4 | TimeTicks FROM SNMPv2-SMI;
|
---|
| 5 |
|
---|
| 6 |
|
---|
| 7 | -- definition of textual conventions
|
---|
| 8 |
|
---|
| 9 | TEXTUAL-CONVENTION MACRO ::=
|
---|
| 10 | BEGIN
|
---|
| 11 | TYPE NOTATION ::=
|
---|
| 12 | DisplayPart
|
---|
| 13 | "STATUS" Status
|
---|
| 14 | "DESCRIPTION" Text
|
---|
| 15 | ReferPart
|
---|
| 16 | "SYNTAX" Syntax
|
---|
| 17 |
|
---|
| 18 | VALUE NOTATION ::=
|
---|
| 19 | value(VALUE Syntax) -- adapted ASN.1
|
---|
| 20 |
|
---|
| 21 | DisplayPart ::=
|
---|
| 22 | "DISPLAY-HINT" Text
|
---|
| 23 | | empty
|
---|
| 24 |
|
---|
| 25 | Status ::=
|
---|
| 26 | "current"
|
---|
| 27 | | "deprecated"
|
---|
| 28 | | "obsolete"
|
---|
| 29 |
|
---|
| 30 | ReferPart ::=
|
---|
| 31 | "REFERENCE" Text
|
---|
| 32 | | empty
|
---|
| 33 |
|
---|
| 34 | -- a character string as defined in [2]
|
---|
| 35 | Text ::= value(IA5String)
|
---|
| 36 |
|
---|
| 37 | Syntax ::= -- Must be one of the following:
|
---|
| 38 | -- a base type (or its refinement), or
|
---|
| 39 | -- a BITS pseudo-type
|
---|
| 40 | type
|
---|
| 41 | | "BITS" "{" NamedBits "}"
|
---|
| 42 |
|
---|
| 43 | NamedBits ::= NamedBit
|
---|
| 44 | | NamedBits "," NamedBit
|
---|
| 45 |
|
---|
| 46 | NamedBit ::= identifier "(" number ")" -- number is nonnegative
|
---|
| 47 |
|
---|
| 48 | END
|
---|
| 49 |
|
---|
| 50 |
|
---|
| 51 |
|
---|
| 52 |
|
---|
| 53 | DisplayString ::= TEXTUAL-CONVENTION
|
---|
| 54 | DISPLAY-HINT "255a"
|
---|
| 55 | STATUS current
|
---|
| 56 | DESCRIPTION
|
---|
| 57 | "Represents textual information taken from the NVT ASCII
|
---|
| 58 | character set, as defined in pages 4, 10-11 of RFC 854.
|
---|
| 59 |
|
---|
| 60 | To summarize RFC 854, the NVT ASCII repertoire specifies:
|
---|
| 61 |
|
---|
| 62 | - the use of character codes 0-127 (decimal)
|
---|
| 63 |
|
---|
| 64 | - the graphics characters (32-126) are interpreted as
|
---|
| 65 | US ASCII
|
---|
| 66 |
|
---|
| 67 | - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
|
---|
| 68 | meanings specified in RFC 854
|
---|
| 69 |
|
---|
| 70 | - the other 25 codes have no standard interpretation
|
---|
| 71 |
|
---|
| 72 | - the sequence 'CR LF' means newline
|
---|
| 73 |
|
---|
| 74 | - the sequence 'CR NUL' means carriage-return
|
---|
| 75 |
|
---|
| 76 | - an 'LF' not preceded by a 'CR' means moving to the
|
---|
| 77 | same column on the next line.
|
---|
| 78 |
|
---|
| 79 | - the sequence 'CR x' for any x other than LF or NUL is
|
---|
| 80 | illegal. (Note that this also means that a string may
|
---|
| 81 | end with either 'CR LF' or 'CR NUL', but not with CR.)
|
---|
| 82 |
|
---|
| 83 | Any object defined using this syntax may not exceed 255
|
---|
| 84 | characters in length."
|
---|
| 85 | SYNTAX OCTET STRING (SIZE (0..255))
|
---|
| 86 |
|
---|
| 87 | PhysAddress ::= TEXTUAL-CONVENTION
|
---|
| 88 | DISPLAY-HINT "1x:"
|
---|
| 89 | STATUS current
|
---|
| 90 | DESCRIPTION
|
---|
| 91 | "Represents media- or physical-level addresses."
|
---|
| 92 | SYNTAX OCTET STRING
|
---|
| 93 |
|
---|
| 94 |
|
---|
| 95 | MacAddress ::= TEXTUAL-CONVENTION
|
---|
| 96 | DISPLAY-HINT "1x:"
|
---|
| 97 | STATUS current
|
---|
| 98 | DESCRIPTION
|
---|
| 99 | "Represents an 802 MAC address represented in the
|
---|
| 100 | `canonical' order defined by IEEE 802.1a, i.e., as if it
|
---|
| 101 | were transmitted least significant bit first, even though
|
---|
| 102 | 802.5 (in contrast to other 802.x protocols) requires MAC
|
---|
| 103 | addresses to be transmitted most significant bit first."
|
---|
| 104 | SYNTAX OCTET STRING (SIZE (6))
|
---|
| 105 |
|
---|
| 106 | TruthValue ::= TEXTUAL-CONVENTION
|
---|
| 107 | STATUS current
|
---|
| 108 | DESCRIPTION
|
---|
| 109 | "Represents a boolean value."
|
---|
| 110 | SYNTAX INTEGER { true(1), false(2) }
|
---|
| 111 |
|
---|
| 112 | TestAndIncr ::= TEXTUAL-CONVENTION
|
---|
| 113 | STATUS current
|
---|
| 114 | DESCRIPTION
|
---|
| 115 | "Represents integer-valued information used for atomic
|
---|
| 116 | operations. When the management protocol is used to specify
|
---|
| 117 | that an object instance having this syntax is to be
|
---|
| 118 | modified, the new value supplied via the management protocol
|
---|
| 119 | must precisely match the value presently held by the
|
---|
| 120 | instance. If not, the management protocol set operation
|
---|
| 121 | fails with an error of `inconsistentValue'. Otherwise, if
|
---|
| 122 | the current value is the maximum value of 2^31-1 (2147483647
|
---|
| 123 | decimal), then the value held by the instance is wrapped to
|
---|
| 124 | zero; otherwise, the value held by the instance is
|
---|
| 125 | incremented by one. (Note that regardless of whether the
|
---|
| 126 | management protocol set operation succeeds, the variable-
|
---|
| 127 | binding in the request and response PDUs are identical.)
|
---|
| 128 |
|
---|
| 129 | The value of the ACCESS clause for objects having this
|
---|
| 130 | syntax is either `read-write' or `read-create'. When an
|
---|
| 131 | instance of a columnar object having this syntax is created,
|
---|
| 132 | any value may be supplied via the management protocol.
|
---|
| 133 |
|
---|
| 134 | When the network management portion of the system is re-
|
---|
| 135 | initialized, the value of every object instance having this
|
---|
| 136 | syntax must either be incremented from its value prior to
|
---|
| 137 | the re-initialization, or (if the value prior to the re-
|
---|
| 138 | initialization is unknown) be set to a pseudo-randomly
|
---|
| 139 | generated value."
|
---|
| 140 | SYNTAX INTEGER (0..2147483647)
|
---|
| 141 |
|
---|
| 142 | AutonomousType ::= TEXTUAL-CONVENTION
|
---|
| 143 | STATUS current
|
---|
| 144 | DESCRIPTION
|
---|
| 145 | "Represents an independently extensible type identification
|
---|
| 146 | value. It may, for example, indicate a particular sub-tree
|
---|
| 147 | with further MIB definitions, or define a particular type of
|
---|
| 148 | protocol or hardware."
|
---|
| 149 | SYNTAX OBJECT IDENTIFIER
|
---|
| 150 |
|
---|
| 151 |
|
---|
| 152 | InstancePointer ::= TEXTUAL-CONVENTION
|
---|
| 153 | STATUS obsolete
|
---|
| 154 | DESCRIPTION
|
---|
| 155 | "A pointer to either a specific instance of a MIB object or
|
---|
| 156 | a conceptual row of a MIB table in the managed device. In
|
---|
| 157 | the latter case, by convention, it is the name of the
|
---|
| 158 | particular instance of the first accessible columnar object
|
---|
| 159 | in the conceptual row.
|
---|
| 160 |
|
---|
| 161 | The two uses of this textual convention are replaced by
|
---|
| 162 | VariablePointer and RowPointer, respectively."
|
---|
| 163 | SYNTAX OBJECT IDENTIFIER
|
---|
| 164 |
|
---|
| 165 |
|
---|
| 166 | VariablePointer ::= TEXTUAL-CONVENTION
|
---|
| 167 | STATUS current
|
---|
| 168 | DESCRIPTION
|
---|
| 169 | "A pointer to a specific object instance. For example,
|
---|
| 170 | sysContact.0 or ifInOctets.3."
|
---|
| 171 | SYNTAX OBJECT IDENTIFIER
|
---|
| 172 |
|
---|
| 173 |
|
---|
| 174 | RowPointer ::= TEXTUAL-CONVENTION
|
---|
| 175 | STATUS current
|
---|
| 176 | DESCRIPTION
|
---|
| 177 | "Represents a pointer to a conceptual row. The value is the
|
---|
| 178 | name of the instance of the first accessible columnar object
|
---|
| 179 | in the conceptual row.
|
---|
| 180 |
|
---|
| 181 | For example, ifIndex.3 would point to the 3rd row in the
|
---|
| 182 | ifTable (note that if ifIndex were not-accessible, then
|
---|
| 183 | ifDescr.3 would be used instead)."
|
---|
| 184 | SYNTAX OBJECT IDENTIFIER
|
---|
| 185 |
|
---|
| 186 | RowStatus ::= TEXTUAL-CONVENTION
|
---|
| 187 | STATUS current
|
---|
| 188 | DESCRIPTION
|
---|
| 189 | "The RowStatus textual convention is used to manage the
|
---|
| 190 | creation and deletion of conceptual rows, and is used as the
|
---|
| 191 | value of the SYNTAX clause for the status column of a
|
---|
| 192 | conceptual row (as described in Section 7.7.1 of [2].)
|
---|
| 193 | The status column has six defined values:
|
---|
| 194 |
|
---|
| 195 | - `active', which indicates that the conceptual row is
|
---|
| 196 | available for use by the managed device;
|
---|
| 197 |
|
---|
| 198 | - `notInService', which indicates that the conceptual
|
---|
| 199 | row exists in the agent, but is unavailable for use by
|
---|
| 200 | the managed device (see NOTE below); 'notInService' has
|
---|
| 201 | no implication regarding the internal consistency of
|
---|
| 202 | the row, availability of resources, or consistency with
|
---|
| 203 | the current state of the managed device;
|
---|
| 204 |
|
---|
| 205 | - `notReady', which indicates that the conceptual row
|
---|
| 206 | exists in the agent, but is missing information
|
---|
| 207 | necessary in order to be available for use by the
|
---|
| 208 | managed device (i.e., one or more required columns in
|
---|
| 209 | the conceptual row have not been instanciated);
|
---|
| 210 |
|
---|
| 211 | - `createAndGo', which is supplied by a management
|
---|
| 212 | station wishing to create a new instance of a
|
---|
| 213 | conceptual row and to have its status automatically set
|
---|
| 214 | to active, making it available for use by the managed
|
---|
| 215 | device;
|
---|
| 216 |
|
---|
| 217 | - `createAndWait', which is supplied by a management
|
---|
| 218 | station wishing to create a new instance of a
|
---|
| 219 | conceptual row (but not make it available for use by
|
---|
| 220 | the managed device); and,
|
---|
| 221 |
|
---|
| 222 | - `destroy', which is supplied by a management station
|
---|
| 223 | wishing to delete all of the instances associated with
|
---|
| 224 | an existing conceptual row.
|
---|
| 225 |
|
---|
| 226 | Whereas five of the six values (all except `notReady') may
|
---|
| 227 | be specified in a management protocol set operation, only
|
---|
| 228 | three values will be returned in response to a management
|
---|
| 229 | protocol retrieval operation: `notReady', `notInService' or
|
---|
| 230 | `active'. That is, when queried, an existing conceptual row
|
---|
| 231 | has only three states: it is either available for use by
|
---|
| 232 | the managed device (the status column has value `active');
|
---|
| 233 | it is not available for use by the managed device, though
|
---|
| 234 | the agent has sufficient information to attempt to make it
|
---|
| 235 | so (the status column has value `notInService'); or, it is
|
---|
| 236 | not available for use by the managed device, and an attempt
|
---|
| 237 | to make it so would fail because the agent has insufficient
|
---|
| 238 | information (the state column has value `notReady').
|
---|
| 239 |
|
---|
| 240 | NOTE WELL
|
---|
| 241 |
|
---|
| 242 | This textual convention may be used for a MIB table,
|
---|
| 243 | irrespective of whether the values of that table's
|
---|
| 244 | conceptual rows are able to be modified while it is
|
---|
| 245 | active, or whether its conceptual rows must be taken
|
---|
| 246 | out of service in order to be modified. That is, it is
|
---|
| 247 | the responsibility of the DESCRIPTION clause of the
|
---|
| 248 | status column to specify whether the status column must
|
---|
| 249 | not be `active' in order for the value of some other
|
---|
| 250 | column of the same conceptual row to be modified. If
|
---|
| 251 | such a specification is made, affected columns may be
|
---|
| 252 | changed by an SNMP set PDU if the RowStatus would not
|
---|
| 253 | be equal to `active' either immediately before or after
|
---|
| 254 | processing the PDU. In other words, if the PDU also
|
---|
| 255 | contained a varbind that would change the RowStatus
|
---|
| 256 | value, the column in question may be changed if the
|
---|
| 257 | RowStatus was not equal to `active' as the PDU was
|
---|
| 258 | received, or if the varbind sets the status to a value
|
---|
| 259 | other than 'active'.
|
---|
| 260 |
|
---|
| 261 |
|
---|
| 262 | Also note that whenever any elements of a row exist, the
|
---|
| 263 | RowStatus column must also exist.
|
---|
| 264 |
|
---|
| 265 | To summarize the effect of having a conceptual row with a
|
---|
| 266 | status column having a SYNTAX clause value of RowStatus,
|
---|
| 267 | consider the following state diagram:
|
---|
| 268 |
|
---|
| 269 |
|
---|
| 270 | STATE
|
---|
| 271 | +--------------+-----------+-------------+-------------
|
---|
| 272 | | A | B | C | D
|
---|
| 273 | | |status col.|status column|
|
---|
| 274 | |status column | is | is |status column
|
---|
| 275 | ACTION |does not exist| notReady | notInService| is active
|
---|
| 276 | --------------+--------------+-----------+-------------+-------------
|
---|
| 277 | set status |noError ->D|inconsist- |inconsistent-|inconsistent-
|
---|
| 278 | column to | or | entValue| Value| Value
|
---|
| 279 | createAndGo |inconsistent- | | |
|
---|
| 280 | | Value| | |
|
---|
| 281 | --------------+--------------+-----------+-------------+-------------
|
---|
| 282 | set status |noError see 1|inconsist- |inconsistent-|inconsistent-
|
---|
| 283 | column to | or | entValue| Value| Value
|
---|
| 284 | createAndWait |wrongValue | | |
|
---|
| 285 | --------------+--------------+-----------+-------------+-------------
|
---|
| 286 | set status |inconsistent- |inconsist- |noError |noError
|
---|
| 287 | column to | Value| entValue| |
|
---|
| 288 | active | | | |
|
---|
| 289 | | | or | |
|
---|
| 290 | | | | |
|
---|
| 291 | | |see 2 ->D|see 8 ->D| ->D
|
---|
| 292 | --------------+--------------+-----------+-------------+-------------
|
---|
| 293 | set status |inconsistent- |inconsist- |noError |noError ->C
|
---|
| 294 | column to | Value| entValue| |
|
---|
| 295 | notInService | | | |
|
---|
| 296 | | | or | | or
|
---|
| 297 | | | | |
|
---|
| 298 | | |see 3 ->C| ->C|see 6
|
---|
| 299 | --------------+--------------+-----------+-------------+-------------
|
---|
| 300 | set status |noError |noError |noError |noError ->A
|
---|
| 301 | column to | | | | or
|
---|
| 302 | destroy | ->A| ->A| ->A|see 7
|
---|
| 303 | --------------+--------------+-----------+-------------+-------------
|
---|
| 304 | set any other |see 4 |noError |noError |see 5
|
---|
| 305 | column to some| | | |
|
---|
| 306 | value | | see 1| ->C| ->D
|
---|
| 307 | --------------+--------------+-----------+-------------+-------------
|
---|
| 308 |
|
---|
| 309 | (1) goto B or C, depending on information available to the
|
---|
| 310 | agent.
|
---|
| 311 |
|
---|
| 312 | (2) if other variable bindings included in the same PDU,
|
---|
| 313 | provide values for all columns which are missing but
|
---|
| 314 | required, and all columns have acceptable values, then
|
---|
| 315 | return noError and goto D.
|
---|
| 316 |
|
---|
| 317 | (3) if other variable bindings included in the same PDU,
|
---|
| 318 | provide legal values for all columns which are missing but
|
---|
| 319 | required, then return noError and goto C.
|
---|
| 320 |
|
---|
| 321 | (4) at the discretion of the agent, the return value may be
|
---|
| 322 | either:
|
---|
| 323 |
|
---|
| 324 | inconsistentName: because the agent does not choose to
|
---|
| 325 | create such an instance when the corresponding
|
---|
| 326 | RowStatus instance does not exist, or
|
---|
| 327 |
|
---|
| 328 | inconsistentValue: if the supplied value is
|
---|
| 329 | inconsistent with the state of some other MIB object's
|
---|
| 330 | value, or
|
---|
| 331 |
|
---|
| 332 | noError: because the agent chooses to create the
|
---|
| 333 | instance.
|
---|
| 334 |
|
---|
| 335 | If noError is returned, then the instance of the status
|
---|
| 336 | column must also be created, and the new state is B or C,
|
---|
| 337 | depending on the information available to the agent. If
|
---|
| 338 | inconsistentName or inconsistentValue is returned, the row
|
---|
| 339 | remains in state A.
|
---|
| 340 |
|
---|
| 341 | (5) depending on the MIB definition for the column/table,
|
---|
| 342 | either noError or inconsistentValue may be returned.
|
---|
| 343 |
|
---|
| 344 | (6) the return value can indicate one of the following
|
---|
| 345 | errors:
|
---|
| 346 |
|
---|
| 347 | wrongValue: because the agent does not support
|
---|
| 348 | notInService (e.g., an agent which does not support
|
---|
| 349 | createAndWait), or
|
---|
| 350 |
|
---|
| 351 | inconsistentValue: because the agent is unable to take
|
---|
| 352 | the row out of service at this time, perhaps because it
|
---|
| 353 | is in use and cannot be de-activated.
|
---|
| 354 |
|
---|
| 355 | (7) the return value can indicate the following error:
|
---|
| 356 |
|
---|
| 357 | inconsistentValue: because the agent is unable to
|
---|
| 358 | remove the row at this time, perhaps because it is in
|
---|
| 359 | use and cannot be de-activated.
|
---|
| 360 |
|
---|
| 361 | (8) the transition to D can fail, e.g., if the values of the
|
---|
| 362 | conceptual row are inconsistent, then the error code would
|
---|
| 363 | be inconsistentValue.
|
---|
| 364 |
|
---|
| 365 | NOTE: Other processing of (this and other varbinds of) the
|
---|
| 366 | set request may result in a response other than noError
|
---|
| 367 | being returned, e.g., wrongValue, noCreation, etc.
|
---|
| 368 |
|
---|
| 369 |
|
---|
| 370 | Conceptual Row Creation
|
---|
| 371 |
|
---|
| 372 | There are four potential interactions when creating a
|
---|
| 373 | conceptual row: selecting an instance-identifier which is
|
---|
| 374 | not in use; creating the conceptual row; initializing any
|
---|
| 375 | objects for which the agent does not supply a default; and,
|
---|
| 376 | making the conceptual row available for use by the managed
|
---|
| 377 | device.
|
---|
| 378 |
|
---|
| 379 | Interaction 1: Selecting an Instance-Identifier
|
---|
| 380 |
|
---|
| 381 | The algorithm used to select an instance-identifier varies
|
---|
| 382 | for each conceptual row. In some cases, the instance-
|
---|
| 383 | identifier is semantically significant, e.g., the
|
---|
| 384 | destination address of a route, and a management station
|
---|
| 385 | selects the instance-identifier according to the semantics.
|
---|
| 386 |
|
---|
| 387 | In other cases, the instance-identifier is used solely to
|
---|
| 388 | distinguish conceptual rows, and a management station
|
---|
| 389 | without specific knowledge of the conceptual row might
|
---|
| 390 | examine the instances present in order to determine an
|
---|
| 391 | unused instance-identifier. (This approach may be used, but
|
---|
| 392 | it is often highly sub-optimal; however, it is also a
|
---|
| 393 | questionable practice for a naive management station to
|
---|
| 394 | attempt conceptual row creation.)
|
---|
| 395 |
|
---|
| 396 | Alternately, the MIB module which defines the conceptual row
|
---|
| 397 | might provide one or more objects which provide assistance
|
---|
| 398 | in determining an unused instance-identifier. For example,
|
---|
| 399 | if the conceptual row is indexed by an integer-value, then
|
---|
| 400 | an object having an integer-valued SYNTAX clause might be
|
---|
| 401 | defined for such a purpose, allowing a management station to
|
---|
| 402 | issue a management protocol retrieval operation. In order
|
---|
| 403 | to avoid unnecessary collisions between competing management
|
---|
| 404 | stations, `adjacent' retrievals of this object should be
|
---|
| 405 | different.
|
---|
| 406 |
|
---|
| 407 | Finally, the management station could select a pseudo-random
|
---|
| 408 | number to use as the index. In the event that this index
|
---|
| 409 | was already in use and an inconsistentValue was returned in
|
---|
| 410 | response to the management protocol set operation, the
|
---|
| 411 | management station should simply select a new pseudo-random
|
---|
| 412 | number and retry the operation.
|
---|
| 413 |
|
---|
| 414 | A MIB designer should choose between the two latter
|
---|
| 415 | algorithms based on the size of the table (and therefore the
|
---|
| 416 | efficiency of each algorithm). For tables in which a large
|
---|
| 417 | number of entries are expected, it is recommended that a MIB
|
---|
| 418 | object be defined that returns an acceptable index for
|
---|
| 419 | creation. For tables with small numbers of entries, it is
|
---|
| 420 | recommended that the latter pseudo-random index mechanism be
|
---|
| 421 | used.
|
---|
| 422 |
|
---|
| 423 | Interaction 2: Creating the Conceptual Row
|
---|
| 424 |
|
---|
| 425 | Once an unused instance-identifier has been selected, the
|
---|
| 426 | management station determines if it wishes to create and
|
---|
| 427 | activate the conceptual row in one transaction or in a
|
---|
| 428 | negotiated set of interactions.
|
---|
| 429 |
|
---|
| 430 | Interaction 2a: Creating and Activating the Conceptual Row
|
---|
| 431 |
|
---|
| 432 | The management station must first determine the column
|
---|
| 433 | requirements, i.e., it must determine those columns for
|
---|
| 434 | which it must or must not provide values. Depending on the
|
---|
| 435 | complexity of the table and the management station's
|
---|
| 436 | knowledge of the agent's capabilities, this determination
|
---|
| 437 | can be made locally by the management station. Alternately,
|
---|
| 438 | the management station issues a management protocol get
|
---|
| 439 | operation to examine all columns in the conceptual row that
|
---|
| 440 | it wishes to create. In response, for each column, there
|
---|
| 441 | are three possible outcomes:
|
---|
| 442 |
|
---|
| 443 | - a value is returned, indicating that some other
|
---|
| 444 | management station has already created this conceptual
|
---|
| 445 | row. We return to interaction 1.
|
---|
| 446 |
|
---|
| 447 | - the exception `noSuchInstance' is returned,
|
---|
| 448 | indicating that the agent implements the object-type
|
---|
| 449 | associated with this column, and that this column in at
|
---|
| 450 | least one conceptual row would be accessible in the MIB
|
---|
| 451 | view used by the retrieval were it to exist. For those
|
---|
| 452 | columns to which the agent provides read-create access,
|
---|
| 453 | the `noSuchInstance' exception tells the management
|
---|
| 454 | station that it should supply a value for this column
|
---|
| 455 | when the conceptual row is to be created.
|
---|
| 456 |
|
---|
| 457 | - the exception `noSuchObject' is returned, indicating
|
---|
| 458 | that the agent does not implement the object-type
|
---|
| 459 | associated with this column or that there is no
|
---|
| 460 | conceptual row for which this column would be
|
---|
| 461 | accessible in the MIB view used by the retrieval. As
|
---|
| 462 | such, the management station can not issue any
|
---|
| 463 | management protocol set operations to create an
|
---|
| 464 | instance of this column.
|
---|
| 465 |
|
---|
| 466 | Once the column requirements have been determined, a
|
---|
| 467 | management protocol set operation is accordingly issued.
|
---|
| 468 | This operation also sets the new instance of the status
|
---|
| 469 | column to `createAndGo'.
|
---|
| 470 |
|
---|
| 471 | When the agent processes the set operation, it verifies that
|
---|
| 472 | it has sufficient information to make the conceptual row
|
---|
| 473 | available for use by the managed device. The information
|
---|
| 474 | available to the agent is provided by two sources: the
|
---|
| 475 | management protocol set operation which creates the
|
---|
| 476 | conceptual row, and, implementation-specific defaults
|
---|
| 477 | supplied by the agent (note that an agent must provide
|
---|
| 478 | implementation-specific defaults for at least those objects
|
---|
| 479 | which it implements as read-only). If there is sufficient
|
---|
| 480 | information available, then the conceptual row is created, a
|
---|
| 481 | `noError' response is returned, the status column is set to
|
---|
| 482 | `active', and no further interactions are necessary (i.e.,
|
---|
| 483 | interactions 3 and 4 are skipped). If there is insufficient
|
---|
| 484 | information, then the conceptual row is not created, and the
|
---|
| 485 | set operation fails with an error of `inconsistentValue'.
|
---|
| 486 | On this error, the management station can issue a management
|
---|
| 487 | protocol retrieval operation to determine if this was
|
---|
| 488 | because it failed to specify a value for a required column,
|
---|
| 489 | or, because the selected instance of the status column
|
---|
| 490 | already existed. In the latter case, we return to
|
---|
| 491 | interaction 1. In the former case, the management station
|
---|
| 492 | can re-issue the set operation with the additional
|
---|
| 493 | information, or begin interaction 2 again using
|
---|
| 494 | `createAndWait' in order to negotiate creation of the
|
---|
| 495 | conceptual row.
|
---|
| 496 |
|
---|
| 497 | NOTE WELL
|
---|
| 498 |
|
---|
| 499 | Regardless of the method used to determine the column
|
---|
| 500 | requirements, it is possible that the management
|
---|
| 501 | station might deem a column necessary when, in fact,
|
---|
| 502 | the agent will not allow that particular columnar
|
---|
| 503 | instance to be created or written. In this case, the
|
---|
| 504 | management protocol set operation will fail with an
|
---|
| 505 | error such as `noCreation' or `notWritable'. In this
|
---|
| 506 | case, the management station decides whether it needs
|
---|
| 507 | to be able to set a value for that particular columnar
|
---|
| 508 | instance. If not, the management station re-issues the
|
---|
| 509 | management protocol set operation, but without setting
|
---|
| 510 | a value for that particular columnar instance;
|
---|
| 511 | otherwise, the management station aborts the row
|
---|
| 512 | creation algorithm.
|
---|
| 513 |
|
---|
| 514 | Interaction 2b: Negotiating the Creation of the Conceptual
|
---|
| 515 | Row
|
---|
| 516 |
|
---|
| 517 | The management station issues a management protocol set
|
---|
| 518 | operation which sets the desired instance of the status
|
---|
| 519 | column to `createAndWait'. If the agent is unwilling to
|
---|
| 520 | process a request of this sort, the set operation fails with
|
---|
| 521 | an error of `wrongValue'. (As a consequence, such an agent
|
---|
| 522 | must be prepared to accept a single management protocol set
|
---|
| 523 | operation, i.e., interaction 2a above, containing all of the
|
---|
| 524 | columns indicated by its column requirements.) Otherwise,
|
---|
| 525 | the conceptual row is created, a `noError' response is
|
---|
| 526 | returned, and the status column is immediately set to either
|
---|
| 527 | `notInService' or `notReady', depending on whether it has
|
---|
| 528 | sufficient information to (attempt to) make the conceptual
|
---|
| 529 | row available for use by the managed device. If there is
|
---|
| 530 | sufficient information available, then the status column is
|
---|
| 531 | set to `notInService'; otherwise, if there is insufficient
|
---|
| 532 | information, then the status column is set to `notReady'.
|
---|
| 533 | Regardless, we proceed to interaction 3.
|
---|
| 534 |
|
---|
| 535 | Interaction 3: Initializing non-defaulted Objects
|
---|
| 536 |
|
---|
| 537 | The management station must now determine the column
|
---|
| 538 | requirements. It issues a management protocol get operation
|
---|
| 539 | to examine all columns in the created conceptual row. In
|
---|
| 540 | the response, for each column, there are three possible
|
---|
| 541 | outcomes:
|
---|
| 542 |
|
---|
| 543 | - a value is returned, indicating that the agent
|
---|
| 544 | implements the object-type associated with this column
|
---|
| 545 | and had sufficient information to provide a value. For
|
---|
| 546 | those columns to which the agent provides read-create
|
---|
| 547 | access (and for which the agent allows their values to
|
---|
| 548 | be changed after their creation), a value return tells
|
---|
| 549 | the management station that it may issue additional
|
---|
| 550 | management protocol set operations, if it desires, in
|
---|
| 551 | order to change the value associated with this column.
|
---|
| 552 |
|
---|
| 553 | - the exception `noSuchInstance' is returned,
|
---|
| 554 | indicating that the agent implements the object-type
|
---|
| 555 | associated with this column, and that this column in at
|
---|
| 556 | least one conceptual row would be accessible in the MIB
|
---|
| 557 | view used by the retrieval were it to exist. However,
|
---|
| 558 | the agent does not have sufficient information to
|
---|
| 559 | provide a value, and until a value is provided, the
|
---|
| 560 | conceptual row may not be made available for use by the
|
---|
| 561 | managed device. For those columns to which the agent
|
---|
| 562 | provides read-create access, the `noSuchInstance'
|
---|
| 563 | exception tells the management station that it must
|
---|
| 564 | issue additional management protocol set operations, in
|
---|
| 565 | order to provide a value associated with this column.
|
---|
| 566 |
|
---|
| 567 | - the exception `noSuchObject' is returned, indicating
|
---|
| 568 | that the agent does not implement the object-type
|
---|
| 569 | associated with this column or that there is no
|
---|
| 570 | conceptual row for which this column would be
|
---|
| 571 | accessible in the MIB view used by the retrieval. As
|
---|
| 572 | such, the management station can not issue any
|
---|
| 573 | management protocol set operations to create an
|
---|
| 574 | instance of this column.
|
---|
| 575 |
|
---|
| 576 | If the value associated with the status column is
|
---|
| 577 | `notReady', then the management station must first deal with
|
---|
| 578 | all `noSuchInstance' columns, if any. Having done so, the
|
---|
| 579 | value of the status column becomes `notInService', and we
|
---|
| 580 | proceed to interaction 4.
|
---|
| 581 |
|
---|
| 582 | Interaction 4: Making the Conceptual Row Available
|
---|
| 583 |
|
---|
| 584 | Once the management station is satisfied with the values
|
---|
| 585 | associated with the columns of the conceptual row, it issues
|
---|
| 586 | a management protocol set operation to set the status column
|
---|
| 587 | to `active'. If the agent has sufficient information to
|
---|
| 588 | make the conceptual row available for use by the managed
|
---|
| 589 | device, the management protocol set operation succeeds (a
|
---|
| 590 | `noError' response is returned). Otherwise, the management
|
---|
| 591 | protocol set operation fails with an error of
|
---|
| 592 | `inconsistentValue'.
|
---|
| 593 |
|
---|
| 594 | NOTE WELL
|
---|
| 595 |
|
---|
| 596 | A conceptual row having a status column with value
|
---|
| 597 | `notInService' or `notReady' is unavailable to the
|
---|
| 598 | managed device. As such, it is possible for the
|
---|
| 599 | managed device to create its own instances during the
|
---|
| 600 | time between the management protocol set operation
|
---|
| 601 | which sets the status column to `createAndWait' and the
|
---|
| 602 | management protocol set operation which sets the status
|
---|
| 603 | column to `active'. In this case, when the management
|
---|
| 604 | protocol set operation is issued to set the status
|
---|
| 605 | column to `active', the values held in the agent
|
---|
| 606 | supersede those used by the managed device.
|
---|
| 607 |
|
---|
| 608 | If the management station is prevented from setting the
|
---|
| 609 | status column to `active' (e.g., due to management station
|
---|
| 610 | or network failure) the conceptual row will be left in the
|
---|
| 611 | `notInService' or `notReady' state, consuming resources
|
---|
| 612 | indefinitely. The agent must detect conceptual rows that
|
---|
| 613 | have been in either state for an abnormally long period of
|
---|
| 614 | time and remove them. It is the responsibility of the
|
---|
| 615 | DESCRIPTION clause of the status column to indicate what an
|
---|
| 616 | abnormally long period of time would be. This period of
|
---|
| 617 | time should be long enough to allow for human response time
|
---|
| 618 | (including `think time') between the creation of the
|
---|
| 619 | conceptual row and the setting of the status to `active'.
|
---|
| 620 | In the absence of such information in the DESCRIPTION
|
---|
| 621 | clause, it is suggested that this period be approximately 5
|
---|
| 622 | minutes in length. This removal action applies not only to
|
---|
| 623 | newly-created rows, but also to previously active rows which
|
---|
| 624 | are set to, and left in, the notInService state for a
|
---|
| 625 | prolonged period exceeding that which is considered normal
|
---|
| 626 | for such a conceptual row.
|
---|
| 627 |
|
---|
| 628 | Conceptual Row Suspension
|
---|
| 629 |
|
---|
| 630 | When a conceptual row is `active', the management station
|
---|
| 631 | may issue a management protocol set operation which sets the
|
---|
| 632 | instance of the status column to `notInService'. If the
|
---|
| 633 | agent is unwilling to do so, the set operation fails with an
|
---|
| 634 | error of `wrongValue' or `inconsistentValue'. Otherwise,
|
---|
| 635 | the conceptual row is taken out of service, and a `noError'
|
---|
| 636 | response is returned. It is the responsibility of the
|
---|
| 637 | DESCRIPTION clause of the status column to indicate under
|
---|
| 638 | what circumstances the status column should be taken out of
|
---|
| 639 | service (e.g., in order for the value of some other column
|
---|
| 640 | of the same conceptual row to be modified).
|
---|
| 641 |
|
---|
| 642 |
|
---|
| 643 | Conceptual Row Deletion
|
---|
| 644 |
|
---|
| 645 | For deletion of conceptual rows, a management protocol set
|
---|
| 646 | operation is issued which sets the instance of the status
|
---|
| 647 | column to `destroy'. This request may be made regardless of
|
---|
| 648 | the current value of the status column (e.g., it is possible
|
---|
| 649 | to delete conceptual rows which are either `notReady',
|
---|
| 650 | `notInService' or `active'.) If the operation succeeds,
|
---|
| 651 | then all instances associated with the conceptual row are
|
---|
| 652 | immediately removed."
|
---|
| 653 | SYNTAX INTEGER {
|
---|
| 654 | -- the following two values are states:
|
---|
| 655 | -- these values may be read or written
|
---|
| 656 | active(1),
|
---|
| 657 | notInService(2),
|
---|
| 658 |
|
---|
| 659 | -- the following value is a state:
|
---|
| 660 | -- this value may be read, but not written
|
---|
| 661 | notReady(3),
|
---|
| 662 |
|
---|
| 663 | -- the following three values are
|
---|
| 664 | -- actions: these values may be written,
|
---|
| 665 | -- but are never read
|
---|
| 666 | createAndGo(4),
|
---|
| 667 | createAndWait(5),
|
---|
| 668 | destroy(6)
|
---|
| 669 | }
|
---|
| 670 |
|
---|
| 671 | TimeStamp ::= TEXTUAL-CONVENTION
|
---|
| 672 | STATUS current
|
---|
| 673 | DESCRIPTION
|
---|
| 674 | "The value of the sysUpTime object at which a specific
|
---|
| 675 | occurrence happened. The specific occurrence must be
|
---|
| 676 | defined in the description of any object defined using this
|
---|
| 677 | type.
|
---|
| 678 |
|
---|
| 679 | If sysUpTime is reset to zero as a result of a re-
|
---|
| 680 | initialization of the network management (sub)system, then
|
---|
| 681 | the values of all TimeStamp objects are also reset.
|
---|
| 682 | However, after approximately 497 days without a re-
|
---|
| 683 | initialization, the sysUpTime object will reach 2^^32-1 and
|
---|
| 684 | then increment around to zero; in this case, existing values
|
---|
| 685 | of TimeStamp objects do not change. This can lead to
|
---|
| 686 | ambiguities in the value of TimeStamp objects."
|
---|
| 687 | SYNTAX TimeTicks
|
---|
| 688 |
|
---|
| 689 |
|
---|
| 690 | TimeInterval ::= TEXTUAL-CONVENTION
|
---|
| 691 | STATUS current
|
---|
| 692 | DESCRIPTION
|
---|
| 693 | "A period of time, measured in units of 0.01 seconds."
|
---|
| 694 | SYNTAX INTEGER (0..2147483647)
|
---|
| 695 |
|
---|
| 696 | DateAndTime ::= TEXTUAL-CONVENTION
|
---|
| 697 | DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
|
---|
| 698 | STATUS current
|
---|
| 699 | DESCRIPTION
|
---|
| 700 | "A date-time specification.
|
---|
| 701 |
|
---|
| 702 | field octets contents range
|
---|
| 703 | ----- ------ -------- -----
|
---|
| 704 | 1 1-2 year* 0..65536
|
---|
| 705 | 2 3 month 1..12
|
---|
| 706 | 3 4 day 1..31
|
---|
| 707 | 4 5 hour 0..23
|
---|
| 708 | 5 6 minutes 0..59
|
---|
| 709 | 6 7 seconds 0..60
|
---|
| 710 | (use 60 for leap-second)
|
---|
| 711 | 7 8 deci-seconds 0..9
|
---|
| 712 | 8 9 direction from UTC '+' / '-'
|
---|
| 713 | 9 10 hours from UTC* 0..13
|
---|
| 714 | 10 11 minutes from UTC 0..59
|
---|
| 715 |
|
---|
| 716 | * Notes:
|
---|
| 717 | - the value of year is in network-byte order
|
---|
| 718 | - daylight saving time in New Zealand is +13
|
---|
| 719 |
|
---|
| 720 | For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
|
---|
| 721 | displayed as:
|
---|
| 722 |
|
---|
| 723 | 1992-5-26,13:30:15.0,-4:0
|
---|
| 724 |
|
---|
| 725 | Note that if only local time is known, then timezone
|
---|
| 726 | information (fields 8-10) is not present."
|
---|
| 727 | SYNTAX OCTET STRING (SIZE (8 | 11))
|
---|
| 728 |
|
---|
| 729 |
|
---|
| 730 | StorageType ::= TEXTUAL-CONVENTION
|
---|
| 731 | STATUS current
|
---|
| 732 | DESCRIPTION
|
---|
| 733 | "Describes the memory realization of a conceptual row. A
|
---|
| 734 | row which is volatile(2) is lost upon reboot. A row which
|
---|
| 735 | is either nonVolatile(3), permanent(4) or readOnly(5), is
|
---|
| 736 | backed up by stable storage. A row which is permanent(4)
|
---|
| 737 | can be changed but not deleted. A row which is readOnly(5)
|
---|
| 738 | cannot be changed nor deleted.
|
---|
| 739 |
|
---|
| 740 | If the value of an object with this syntax is either
|
---|
| 741 | permanent(4) or readOnly(5), it cannot be written.
|
---|
| 742 | Conversely, if the value is either other(1), volatile(2) or
|
---|
| 743 | nonVolatile(3), it cannot be modified to be permanent(4) or
|
---|
| 744 | readOnly(5). (All illegal modifications result in a
|
---|
| 745 | 'wrongValue' error.)
|
---|
| 746 |
|
---|
| 747 | Every usage of this textual convention is required to
|
---|
| 748 | specify the columnar objects which a permanent(4) row must
|
---|
| 749 | at a minimum allow to be writable."
|
---|
| 750 | SYNTAX INTEGER {
|
---|
| 751 | other(1), -- eh?
|
---|
| 752 | volatile(2), -- e.g., in RAM
|
---|
| 753 | nonVolatile(3), -- e.g., in NVRAM
|
---|
| 754 | permanent(4), -- e.g., partially in ROM
|
---|
| 755 | readOnly(5) -- e.g., completely in ROM
|
---|
| 756 | }
|
---|
| 757 |
|
---|
| 758 | TDomain ::= TEXTUAL-CONVENTION
|
---|
| 759 | STATUS current
|
---|
| 760 | DESCRIPTION
|
---|
| 761 | "Denotes a kind of transport service.
|
---|
| 762 |
|
---|
| 763 | Some possible values, such as snmpUDPDomain, are defined in
|
---|
| 764 | the SNMPv2-TM MIB module. Other possible values are defined
|
---|
| 765 | in other MIB modules."
|
---|
| 766 | REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
|
---|
| 767 | SYNTAX OBJECT IDENTIFIER
|
---|
| 768 |
|
---|
| 769 |
|
---|
| 770 | TAddress ::= TEXTUAL-CONVENTION
|
---|
| 771 | STATUS current
|
---|
| 772 | DESCRIPTION
|
---|
| 773 | "Denotes a transport service address.
|
---|
| 774 |
|
---|
| 775 | A TAddress value is always interpreted within the context of a
|
---|
| 776 | TDomain value. Thus, each definition of a TDomain value must
|
---|
| 777 | be accompanied by a definition of a textual convention for use
|
---|
| 778 | with that TDomain. Some possible textual conventions, such as
|
---|
| 779 | SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM
|
---|
| 780 | MIB module. Other possible textual conventions are defined in
|
---|
| 781 | other MIB modules."
|
---|
| 782 | REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
|
---|
| 783 | SYNTAX OCTET STRING (SIZE (1..255))
|
---|
| 784 |
|
---|
| 785 |
|
---|
| 786 | END
|
---|