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