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