]>
Commit | Line | Data |
---|---|---|
a74454a7 | 1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | ||
8 | Network Working Group Editors of this version: | |
9 | Request for Comments: 2578 K. McCloghrie | |
10 | STD: 58 Cisco Systems | |
11 | Obsoletes: 1902 D. Perkins | |
12 | Category: Standards Track SNMPinfo | |
13 | J. Schoenwaelder | |
14 | TU Braunschweig | |
15 | Authors of previous version: | |
16 | J. Case | |
17 | SNMP Research | |
18 | K. McCloghrie | |
19 | Cisco Systems | |
20 | M. Rose | |
21 | First Virtual Holdings | |
22 | S. Waldbusser | |
23 | International Network Services | |
24 | April 1999 | |
25 | ||
26 | ||
27 | Structure of Management Information Version 2 (SMIv2) | |
28 | ||
29 | ||
30 | Status of this Memo | |
31 | ||
32 | This document specifies an Internet standards track protocol for the | |
33 | Internet community, and requests discussion and suggestions for | |
34 | improvements. Please refer to the current edition of the "Internet | |
35 | Official Protocol Standards" (STD 1) for the standardization state | |
36 | and status of this protocol. Distribution of this memo is unlimited. | |
37 | ||
38 | Copyright Notice | |
39 | ||
40 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
41 | ||
42 | ||
43 | Table of Contents | |
44 | ||
45 | 1 Introduction .................................................3 | |
46 | 1.1 A Note on Terminology ......................................4 | |
47 | 2 Definitions ..................................................4 | |
48 | 2.1 The MODULE-IDENTITY macro ..................................5 | |
49 | 2.2 Object Names and Syntaxes ..................................5 | |
50 | 2.3 The OBJECT-TYPE macro ......................................8 | |
51 | 2.5 The NOTIFICATION-TYPE macro ...............................10 | |
52 | 2.6 Administrative Identifiers ................................11 | |
53 | 3 Information Modules .........................................11 | |
54 | 3.1 Macro Invocation ..........................................12 | |
55 | 3.1.1 Textual Values and Strings ..............................13 | |
56 | ||
57 | ||
58 | McCloghrie, et al. Standards Track [Page 1] | |
59 | \f | |
60 | ||
61 | ||
62 | ||
63 | ||
64 | RFC 2578 SMIv2 April 1999 | |
65 | ||
66 | ||
67 | 3.2 IMPORTing Symbols .........................................14 | |
68 | 3.3 Exporting Symbols .........................................14 | |
69 | 3.4 ASN.1 Comments ............................................14 | |
70 | 3.5 OBJECT IDENTIFIER values ..................................15 | |
71 | 3.6 OBJECT IDENTIFIER usage ...................................15 | |
72 | 3.7 Reserved Keywords .........................................16 | |
73 | 4 Naming Hierarchy ............................................16 | |
74 | 5 Mapping of the MODULE-IDENTITY macro ........................17 | |
75 | 5.1 Mapping of the LAST-UPDATED clause ........................17 | |
76 | 5.2 Mapping of the ORGANIZATION clause ........................17 | |
77 | 5.3 Mapping of the CONTACT-INFO clause ........................18 | |
78 | 5.4 Mapping of the DESCRIPTION clause .........................18 | |
79 | 5.5 Mapping of the REVISION clause ............................18 | |
80 | 5.5.1 Mapping of the DESCRIPTION sub-clause ...................18 | |
81 | 5.6 Mapping of the MODULE-IDENTITY value ......................18 | |
82 | 5.7 Usage Example .............................................18 | |
83 | 6 Mapping of the OBJECT-IDENTITY macro ........................19 | |
84 | 6.1 Mapping of the STATUS clause ..............................19 | |
85 | 6.2 Mapping of the DESCRIPTION clause .........................20 | |
86 | 6.3 Mapping of the REFERENCE clause ...........................20 | |
87 | 6.4 Mapping of the OBJECT-IDENTITY value ......................20 | |
88 | 6.5 Usage Example .............................................20 | |
89 | 7 Mapping of the OBJECT-TYPE macro ............................20 | |
90 | 7.1 Mapping of the SYNTAX clause ..............................21 | |
91 | 7.1.1 Integer32 and INTEGER ...................................21 | |
92 | 7.1.2 OCTET STRING ............................................21 | |
93 | 7.1.3 OBJECT IDENTIFIER .......................................22 | |
94 | 7.1.4 The BITS construct ......................................22 | |
95 | 7.1.5 IpAddress ...............................................22 | |
96 | 7.1.6 Counter32 ...............................................23 | |
97 | 7.1.7 Gauge32 .................................................23 | |
98 | 7.1.8 TimeTicks ...............................................24 | |
99 | 7.1.9 Opaque ..................................................24 | |
100 | 7.1.10 Counter64 ..............................................24 | |
101 | 7.1.11 Unsigned32 .............................................25 | |
102 | 7.1.12 Conceptual Tables ......................................25 | |
103 | 7.1.12.1 Creation and Deletion of Conceptual Rows .............26 | |
104 | 7.2 Mapping of the UNITS clause ...............................26 | |
105 | 7.3 Mapping of the MAX-ACCESS clause ..........................26 | |
106 | 7.4 Mapping of the STATUS clause ..............................27 | |
107 | 7.5 Mapping of the DESCRIPTION clause .........................27 | |
108 | 7.6 Mapping of the REFERENCE clause ...........................27 | |
109 | 7.7 Mapping of the INDEX clause ...............................27 | |
110 | 7.8 Mapping of the AUGMENTS clause ............................29 | |
111 | 7.8.1 Relation between INDEX and AUGMENTS clauses .............30 | |
112 | 7.9 Mapping of the DEFVAL clause ..............................30 | |
113 | 7.10 Mapping of the OBJECT-TYPE value .........................31 | |
114 | 7.11 Usage Example ............................................32 | |
115 | ||
116 | ||
117 | McCloghrie, et al. Standards Track [Page 2] | |
118 | \f | |
119 | ||
120 | ||
121 | ||
122 | ||
123 | RFC 2578 SMIv2 April 1999 | |
124 | ||
125 | ||
126 | 8 Mapping of the NOTIFICATION-TYPE macro ......................34 | |
127 | 8.1 Mapping of the OBJECTS clause .............................34 | |
128 | 8.2 Mapping of the STATUS clause ..............................34 | |
129 | 8.3 Mapping of the DESCRIPTION clause .........................35 | |
130 | 8.4 Mapping of the REFERENCE clause ...........................35 | |
131 | 8.5 Mapping of the NOTIFICATION-TYPE value ....................35 | |
132 | 8.6 Usage Example .............................................35 | |
133 | 9 Refined Syntax ..............................................36 | |
134 | 10 Extending an Information Module ............................37 | |
135 | 10.1 Object Assignments .......................................37 | |
136 | 10.2 Object Definitions .......................................38 | |
137 | 10.3 Notification Definitions .................................39 | |
138 | 11 Appendix A: Detailed Sub-typing Rules ......................40 | |
139 | 11.1 Syntax Rules .............................................40 | |
140 | 11.2 Examples .................................................41 | |
141 | 12 Security Considerations ....................................41 | |
142 | 13 Editors' Addresses .........................................41 | |
143 | 14 References .................................................42 | |
144 | 15 Full Copyright Statement ...................................43 | |
145 | ||
146 | 1. Introduction | |
147 | ||
148 | Management information is viewed as a collection of managed objects, | |
149 | residing in a virtual information store, termed the Management | |
150 | Information Base (MIB). Collections of related objects are defined | |
151 | in MIB modules. These modules are written using an adapted subset of | |
152 | OSI's Abstract Syntax Notation One, ASN.1 (1988) [1]. It is the | |
153 | purpose of this document, the Structure of Management Information | |
154 | (SMI), to define that adapted subset, and to assign a set of | |
155 | associated administrative values. | |
156 | ||
157 | The SMI is divided into three parts: module definitions, object | |
158 | definitions, and, notification definitions. | |
159 | ||
160 | (1) Module definitions are used when describing information modules. | |
161 | An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the | |
162 | semantics of an information module. | |
163 | ||
164 | (2) Object definitions are used when describing managed objects. An | |
165 | ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax | |
166 | and semantics of a managed object. | |
167 | ||
168 | (3) Notification definitions are used when describing unsolicited | |
169 | transmissions of management information. An ASN.1 macro, | |
170 | NOTIFICATION-TYPE, is used to concisely convey the syntax and | |
171 | semantics of a notification. | |
172 | ||
173 | ||
174 | ||
175 | ||
176 | McCloghrie, et al. Standards Track [Page 3] | |
177 | \f | |
178 | ||
179 | ||
180 | ||
181 | ||
182 | RFC 2578 SMIv2 April 1999 | |
183 | ||
184 | ||
185 | 1.1. A Note on Terminology | |
186 | ||
187 | For the purpose of exposition, the original Structure of Management | |
188 | Information, as described in RFCs 1155 (STD 16), 1212 (STD 16), and | |
189 | RFC 1215, is termed the SMI version 1 (SMIv1). The current version | |
190 | of the Structure of Management Information is termed SMI version 2 | |
191 | (SMIv2). | |
192 | ||
193 | 2. Definitions | |
194 | ||
195 | SNMPv2-SMI DEFINITIONS ::= BEGIN | |
196 | ||
197 | ||
198 | -- the path to the root | |
199 | ||
200 | org OBJECT IDENTIFIER ::= { iso 3 } -- "iso" = 1 | |
201 | dod OBJECT IDENTIFIER ::= { org 6 } | |
202 | internet OBJECT IDENTIFIER ::= { dod 1 } | |
203 | ||
204 | directory OBJECT IDENTIFIER ::= { internet 1 } | |
205 | ||
206 | mgmt OBJECT IDENTIFIER ::= { internet 2 } | |
207 | mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } | |
208 | transmission OBJECT IDENTIFIER ::= { mib-2 10 } | |
209 | ||
210 | experimental OBJECT IDENTIFIER ::= { internet 3 } | |
211 | ||
212 | private OBJECT IDENTIFIER ::= { internet 4 } | |
213 | enterprises OBJECT IDENTIFIER ::= { private 1 } | |
214 | ||
215 | security OBJECT IDENTIFIER ::= { internet 5 } | |
216 | ||
217 | snmpV2 OBJECT IDENTIFIER ::= { internet 6 } | |
218 | ||
219 | -- transport domains | |
220 | snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 } | |
221 | ||
222 | -- transport proxies | |
223 | snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 } | |
224 | ||
225 | -- module identities | |
226 | snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 } | |
227 | ||
228 | -- Extended UTCTime, to allow dates with four-digit years | |
229 | -- (Note that this definition of ExtUTCTime is not to be IMPORTed | |
230 | -- by MIB modules.) | |
231 | ExtUTCTime ::= OCTET STRING(SIZE(11 | 13)) | |
232 | -- format is YYMMDDHHMMZ or YYYYMMDDHHMMZ | |
233 | ||
234 | ||
235 | McCloghrie, et al. Standards Track [Page 4] | |
236 | \f | |
237 | ||
238 | ||
239 | ||
240 | ||
241 | RFC 2578 SMIv2 April 1999 | |
242 | ||
243 | ||
244 | -- where: YY - last two digits of year (only years | |
245 | -- between 1900-1999) | |
246 | -- YYYY - last four digits of the year (any year) | |
247 | -- MM - month (01 through 12) | |
248 | -- DD - day of month (01 through 31) | |
249 | -- HH - hours (00 through 23) | |
250 | -- MM - minutes (00 through 59) | |
251 | -- Z - denotes GMT (the ASCII character Z) | |
252 | -- | |
253 | -- For example, "9502192015Z" and "199502192015Z" represent | |
254 | -- 8:15pm GMT on 19 February 1995. Years after 1999 must use | |
255 | -- the four digit year format. Years 1900-1999 may use the | |
256 | -- two or four digit format. | |
257 | ||
258 | -- definitions for information modules | |
259 | ||
260 | MODULE-IDENTITY MACRO ::= | |
261 | BEGIN | |
262 | TYPE NOTATION ::= | |
263 | "LAST-UPDATED" value(Update ExtUTCTime) | |
264 | "ORGANIZATION" Text | |
265 | "CONTACT-INFO" Text | |
266 | "DESCRIPTION" Text | |
267 | RevisionPart | |
268 | ||
269 | VALUE NOTATION ::= | |
270 | value(VALUE OBJECT IDENTIFIER) | |
271 | ||
272 | RevisionPart ::= | |
273 | Revisions | |
274 | | empty | |
275 | Revisions ::= | |
276 | Revision | |
277 | | Revisions Revision | |
278 | Revision ::= | |
279 | "REVISION" value(Update ExtUTCTime) | |
280 | "DESCRIPTION" Text | |
281 | ||
282 | -- a character string as defined in section 3.1.1 | |
283 | Text ::= value(IA5String) | |
284 | END | |
285 | ||
286 | ||
287 | OBJECT-IDENTITY MACRO ::= | |
288 | BEGIN | |
289 | TYPE NOTATION ::= | |
290 | "STATUS" Status | |
291 | "DESCRIPTION" Text | |
292 | ||
293 | ||
294 | McCloghrie, et al. Standards Track [Page 5] | |
295 | \f | |
296 | ||
297 | ||
298 | ||
299 | ||
300 | RFC 2578 SMIv2 April 1999 | |
301 | ||
302 | ||
303 | ReferPart | |
304 | ||
305 | VALUE NOTATION ::= | |
306 | value(VALUE OBJECT IDENTIFIER) | |
307 | ||
308 | Status ::= | |
309 | "current" | |
310 | | "deprecated" | |
311 | | "obsolete" | |
312 | ||
313 | ReferPart ::= | |
314 | "REFERENCE" Text | |
315 | | empty | |
316 | ||
317 | -- a character string as defined in section 3.1.1 | |
318 | Text ::= value(IA5String) | |
319 | END | |
320 | ||
321 | ||
322 | -- names of objects | |
323 | -- (Note that these definitions of ObjectName and NotificationName | |
324 | -- are not to be IMPORTed by MIB modules.) | |
325 | ||
326 | ObjectName ::= | |
327 | OBJECT IDENTIFIER | |
328 | ||
329 | NotificationName ::= | |
330 | OBJECT IDENTIFIER | |
331 | ||
332 | -- syntax of objects | |
333 | ||
334 | -- the "base types" defined here are: | |
335 | -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER | |
336 | -- 8 application-defined types: Integer32, IpAddress, Counter32, | |
337 | -- Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64 | |
338 | ||
339 | ObjectSyntax ::= | |
340 | CHOICE { | |
341 | simple | |
342 | SimpleSyntax, | |
343 | ||
344 | -- note that SEQUENCEs for conceptual tables and | |
345 | -- rows are not mentioned here... | |
346 | ||
347 | application-wide | |
348 | ApplicationSyntax | |
349 | } | |
350 | ||
351 | ||
352 | ||
353 | McCloghrie, et al. Standards Track [Page 6] | |
354 | \f | |
355 | ||
356 | ||
357 | ||
358 | ||
359 | RFC 2578 SMIv2 April 1999 | |
360 | ||
361 | ||
362 | -- built-in ASN.1 types | |
363 | ||
364 | SimpleSyntax ::= | |
365 | CHOICE { | |
366 | -- INTEGERs with a more restrictive range | |
367 | -- may also be used | |
368 | integer-value -- includes Integer32 | |
369 | INTEGER (-2147483648..2147483647), | |
370 | ||
371 | -- OCTET STRINGs with a more restrictive size | |
372 | -- may also be used | |
373 | string-value | |
374 | OCTET STRING (SIZE (0..65535)), | |
375 | ||
376 | objectID-value | |
377 | OBJECT IDENTIFIER | |
378 | } | |
379 | ||
380 | -- indistinguishable from INTEGER, but never needs more than | |
381 | -- 32-bits for a two's complement representation | |
382 | Integer32 ::= | |
383 | INTEGER (-2147483648..2147483647) | |
384 | ||
385 | ||
386 | -- application-wide types | |
387 | ||
388 | ApplicationSyntax ::= | |
389 | CHOICE { | |
390 | ipAddress-value | |
391 | IpAddress, | |
392 | ||
393 | counter-value | |
394 | Counter32, | |
395 | ||
396 | timeticks-value | |
397 | TimeTicks, | |
398 | ||
399 | arbitrary-value | |
400 | Opaque, | |
401 | ||
402 | big-counter-value | |
403 | Counter64, | |
404 | ||
405 | unsigned-integer-value -- includes Gauge32 | |
406 | Unsigned32 | |
407 | } | |
408 | ||
409 | -- in network-byte order | |
410 | ||
411 | ||
412 | McCloghrie, et al. Standards Track [Page 7] | |
413 | \f | |
414 | ||
415 | ||
416 | ||
417 | ||
418 | RFC 2578 SMIv2 April 1999 | |
419 | ||
420 | ||
421 | -- (this is a tagged type for historical reasons) | |
422 | IpAddress ::= | |
423 | [APPLICATION 0] | |
424 | IMPLICIT OCTET STRING (SIZE (4)) | |
425 | ||
426 | -- this wraps | |
427 | Counter32 ::= | |
428 | [APPLICATION 1] | |
429 | IMPLICIT INTEGER (0..4294967295) | |
430 | ||
431 | -- this doesn't wrap | |
432 | Gauge32 ::= | |
433 | [APPLICATION 2] | |
434 | IMPLICIT INTEGER (0..4294967295) | |
435 | ||
436 | -- an unsigned 32-bit quantity | |
437 | -- indistinguishable from Gauge32 | |
438 | Unsigned32 ::= | |
439 | [APPLICATION 2] | |
440 | IMPLICIT INTEGER (0..4294967295) | |
441 | ||
442 | -- hundredths of seconds since an epoch | |
443 | TimeTicks ::= | |
444 | [APPLICATION 3] | |
445 | IMPLICIT INTEGER (0..4294967295) | |
446 | ||
447 | -- for backward-compatibility only | |
448 | Opaque ::= | |
449 | [APPLICATION 4] | |
450 | IMPLICIT OCTET STRING | |
451 | ||
452 | -- for counters that wrap in less than one hour with only 32 bits | |
453 | Counter64 ::= | |
454 | [APPLICATION 6] | |
455 | IMPLICIT INTEGER (0..18446744073709551615) | |
456 | ||
457 | ||
458 | -- definition for objects | |
459 | ||
460 | OBJECT-TYPE MACRO ::= | |
461 | BEGIN | |
462 | TYPE NOTATION ::= | |
463 | "SYNTAX" Syntax | |
464 | UnitsPart | |
465 | "MAX-ACCESS" Access | |
466 | "STATUS" Status | |
467 | "DESCRIPTION" Text | |
468 | ReferPart | |
469 | ||
470 | ||
471 | McCloghrie, et al. Standards Track [Page 8] | |
472 | \f | |
473 | ||
474 | ||
475 | ||
476 | ||
477 | RFC 2578 SMIv2 April 1999 | |
478 | ||
479 | ||
480 | IndexPart | |
481 | DefValPart | |
482 | ||
483 | VALUE NOTATION ::= | |
484 | value(VALUE ObjectName) | |
485 | ||
486 | Syntax ::= -- Must be one of the following: | |
487 | -- a base type (or its refinement), | |
488 | -- a textual convention (or its refinement), or | |
489 | -- a BITS pseudo-type | |
490 | type | |
491 | | "BITS" "{" NamedBits "}" | |
492 | ||
493 | NamedBits ::= NamedBit | |
494 | | NamedBits "," NamedBit | |
495 | ||
496 | NamedBit ::= identifier "(" number ")" -- number is nonnegative | |
497 | ||
498 | UnitsPart ::= | |
499 | "UNITS" Text | |
500 | | empty | |
501 | ||
502 | Access ::= | |
503 | "not-accessible" | |
504 | | "accessible-for-notify" | |
505 | | "read-only" | |
506 | | "read-write" | |
507 | | "read-create" | |
508 | ||
509 | Status ::= | |
510 | "current" | |
511 | | "deprecated" | |
512 | | "obsolete" | |
513 | ||
514 | ReferPart ::= | |
515 | "REFERENCE" Text | |
516 | | empty | |
517 | ||
518 | IndexPart ::= | |
519 | "INDEX" "{" IndexTypes "}" | |
520 | | "AUGMENTS" "{" Entry "}" | |
521 | | empty | |
522 | IndexTypes ::= | |
523 | IndexType | |
524 | | IndexTypes "," IndexType | |
525 | IndexType ::= | |
526 | "IMPLIED" Index | |
527 | | Index | |
528 | ||
529 | ||
530 | McCloghrie, et al. Standards Track [Page 9] | |
531 | \f | |
532 | ||
533 | ||
534 | ||
535 | ||
536 | RFC 2578 SMIv2 April 1999 | |
537 | ||
538 | ||
539 | Index ::= | |
540 | -- use the SYNTAX value of the | |
541 | -- correspondent OBJECT-TYPE invocation | |
542 | value(ObjectName) | |
543 | Entry ::= | |
544 | -- use the INDEX value of the | |
545 | -- correspondent OBJECT-TYPE invocation | |
546 | value(ObjectName) | |
547 | ||
548 | DefValPart ::= "DEFVAL" "{" Defvalue "}" | |
549 | | empty | |
550 | ||
551 | Defvalue ::= -- must be valid for the type specified in | |
552 | -- SYNTAX clause of same OBJECT-TYPE macro | |
553 | value(ObjectSyntax) | |
554 | | "{" BitsValue "}" | |
555 | ||
556 | BitsValue ::= BitNames | |
557 | | empty | |
558 | ||
559 | BitNames ::= BitName | |
560 | | BitNames "," BitName | |
561 | ||
562 | BitName ::= identifier | |
563 | ||
564 | -- a character string as defined in section 3.1.1 | |
565 | Text ::= value(IA5String) | |
566 | END | |
567 | ||
568 | ||
569 | -- definitions for notifications | |
570 | ||
571 | NOTIFICATION-TYPE MACRO ::= | |
572 | BEGIN | |
573 | TYPE NOTATION ::= | |
574 | ObjectsPart | |
575 | "STATUS" Status | |
576 | "DESCRIPTION" Text | |
577 | ReferPart | |
578 | ||
579 | VALUE NOTATION ::= | |
580 | value(VALUE NotificationName) | |
581 | ||
582 | ObjectsPart ::= | |
583 | "OBJECTS" "{" Objects "}" | |
584 | | empty | |
585 | Objects ::= | |
586 | Object | |
587 | ||
588 | ||
589 | McCloghrie, et al. Standards Track [Page 10] | |
590 | \f | |
591 | ||
592 | ||
593 | ||
594 | ||
595 | RFC 2578 SMIv2 April 1999 | |
596 | ||
597 | ||
598 | | Objects "," Object | |
599 | Object ::= | |
600 | value(ObjectName) | |
601 | ||
602 | Status ::= | |
603 | "current" | |
604 | | "deprecated" | |
605 | | "obsolete" | |
606 | ||
607 | ReferPart ::= | |
608 | "REFERENCE" Text | |
609 | | empty | |
610 | ||
611 | -- a character string as defined in section 3.1.1 | |
612 | Text ::= value(IA5String) | |
613 | END | |
614 | ||
615 | -- definitions of administrative identifiers | |
616 | ||
617 | zeroDotZero OBJECT-IDENTITY | |
618 | STATUS current | |
619 | DESCRIPTION | |
620 | "A value used for null identifiers." | |
621 | ::= { 0 0 } | |
622 | ||
623 | END | |
624 | ||
625 | 3. Information Modules | |
626 | ||
627 | An "information module" is an ASN.1 module defining information | |
628 | relating to network management. | |
629 | ||
630 | The SMI describes how to use an adapted subset of ASN.1 (1988) to | |
631 | define an information module. Further, additional restrictions are | |
632 | placed on "standard" information modules. It is strongly recommended | |
633 | that "enterprise-specific" information modules also adhere to these | |
634 | restrictions. | |
635 | ||
636 | Typically, there are three kinds of information modules: | |
637 | ||
638 | (1) MIB modules, which contain definitions of inter-related managed | |
639 | objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros; | |
640 | ||
641 | (2) compliance statements for MIB modules, which make use of the | |
642 | MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and, | |
643 | ||
644 | (3) capability statements for agent implementations which make use of | |
645 | the AGENT-CAPABILITIES macros [2]. | |
646 | ||
647 | ||
648 | McCloghrie, et al. Standards Track [Page 11] | |
649 | \f | |
650 | ||
651 | ||
652 | ||
653 | ||
654 | RFC 2578 SMIv2 April 1999 | |
655 | ||
656 | ||
657 | This classification scheme does not imply a rigid taxonomy. For | |
658 | example, a "standard" information module will normally include | |
659 | definitions of managed objects and a compliance statement. | |
660 | Similarly, an "enterprise-specific" information module might include | |
661 | definitions of managed objects and a capability statement. Of | |
662 | course, a "standard" information module may not contain capability | |
663 | statements. | |
664 | ||
665 | The constructs of ASN.1 allowed in SMIv2 information modules include: | |
666 | the IMPORTS clause, value definitions for OBJECT IDENTIFIERs, type | |
667 | definitions for SEQUENCEs (with restrictions), ASN.1 type assignments | |
668 | of the restricted ASN.1 types allowed in SMIv2, and instances of | |
669 | ASN.1 macros defined in this document and its companion documents [2, | |
670 | 3]. Additional ASN.1 macros must not be defined in SMIv2 information | |
671 | modules. SMIv1 macros must not be used in SMIv2 information modules. | |
672 | ||
673 | The names of all standard information modules must be unique (but | |
674 | different versions of the same information module should have the | |
675 | same name). Developers of enterprise information modules are | |
676 | encouraged to choose names for their information modules that will | |
677 | have a low probability of colliding with standard or other enterprise | |
678 | information modules. An information module may not use the ASN.1 | |
679 | construct of placing an object identifier value between the module | |
680 | name and the "DEFINITIONS" keyword. For the purposes of this | |
681 | specification, an ASN.1 module name begins with an upper-case letter | |
682 | and continues with zero or more letters, digits, or hyphens, except | |
683 | that a hyphen can not be the last character, nor can there be two | |
684 | consecutive hyphens. | |
685 | ||
686 | All information modules start with exactly one invocation of the | |
687 | MODULE-IDENTITY macro, which provides contact information as well as | |
688 | revision history to distinguish between versions of the same | |
689 | information module. This invocation must appear immediately after | |
690 | any IMPORTs statements. | |
691 | ||
692 | 3.1. Macro Invocation | |
693 | ||
694 | Within an information module, each macro invocation appears as: | |
695 | ||
696 | <descriptor> <macro> <clauses> ::= <value> | |
697 | ||
698 | where <descriptor> corresponds to an ASN.1 identifier, <macro> names | |
699 | the macro being invoked, and <clauses> and <value> depend on the | |
700 | definition of the macro. (Note that this definition of a descriptor | |
701 | applies to all macros defined in this memo and in [2].) | |
702 | ||
703 | ||
704 | ||
705 | ||
706 | ||
707 | McCloghrie, et al. Standards Track [Page 12] | |
708 | \f | |
709 | ||
710 | ||
711 | ||
712 | ||
713 | RFC 2578 SMIv2 April 1999 | |
714 | ||
715 | ||
716 | For the purposes of this specification, an ASN.1 identifier consists | |
717 | of one or more letters or digits, and its initial character must be a | |
718 | lower-case letter. Note that hyphens are not allowed by this | |
719 | specification (except for use by information modules converted from | |
720 | SMIv1 which did allow hyphens). | |
721 | ||
722 | For all descriptors appearing in an information module, the | |
723 | descriptor shall be unique and mnemonic, and shall not exceed 64 | |
724 | characters in length. (However, descriptors longer than 32 | |
725 | characters are not recommended.) This promotes a common language for | |
726 | humans to use when discussing the information module and also | |
727 | facilitates simple table mappings for user-interfaces. | |
728 | ||
729 | The set of descriptors defined in all "standard" information modules | |
730 | shall be unique. | |
731 | ||
732 | Finally, by convention, if the descriptor refers to an object with a | |
733 | SYNTAX clause value of either Counter32 or Counter64, then the | |
734 | descriptor used for the object should denote plurality. | |
735 | ||
736 | 3.1.1. Textual Values and Strings | |
737 | ||
738 | Some clauses in a macro invocation may take a character string as a | |
739 | textual value (e.g., the DESCRIPTION clause). Other clauses take | |
740 | binary or hexadecimal strings (in any position where a non-negative | |
741 | number is allowed). | |
742 | ||
743 | A character string is preceded and followed by the quote character | |
744 | ("), and consists of an arbitrary number (possibly zero) of: | |
745 | ||
746 | - any 7-bit displayable ASCII characters except quote ("), | |
747 | - tab characters, | |
748 | - spaces, and | |
749 | - line terminator characters (\n or \r\n). | |
750 | ||
751 | The value of a character string is interpreted as ASCII. | |
752 | ||
753 | A binary string consists of a number (possibly zero) of zeros and | |
754 | ones preceded by a single (') and followed by either the pair ('B) or | |
755 | ('b), where the number is a multiple of eight. | |
756 | ||
757 | A hexadecimal string consists of an even number (possibly zero) of | |
758 | hexadecimal digits, preceded by a single (') and followed by either | |
759 | the pair ('H) or ('h). Digits specified via letters can be in upper | |
760 | or lower case. | |
761 | ||
762 | Note that ASN.1 comments can not be enclosed inside any of these | |
763 | types of strings. | |
764 | ||
765 | ||
766 | McCloghrie, et al. Standards Track [Page 13] | |
767 | \f | |
768 | ||
769 | ||
770 | ||
771 | ||
772 | RFC 2578 SMIv2 April 1999 | |
773 | ||
774 | ||
775 | 3.2. IMPORTing Symbols | |
776 | ||
777 | To reference an external object, the IMPORTS statement must be used | |
778 | to identify both the descriptor and the module in which the | |
779 | descriptor is defined, where the module is identified by its ASN.1 | |
780 | module name. | |
781 | ||
782 | Note that when symbols from "enterprise-specific" information modules | |
783 | are referenced (e.g., a descriptor), there is the possibility of | |
784 | collision. As such, if different objects with the same descriptor | |
785 | are IMPORTed, then this ambiguity is resolved by prefixing the | |
786 | descriptor with the name of the information module and a dot ("."), | |
787 | i.e., | |
788 | ||
789 | "module.descriptor" | |
790 | ||
791 | (All descriptors must be unique within any information module.) | |
792 | ||
793 | Of course, this notation can be used to refer to objects even when | |
794 | there is no collision when IMPORTing symbols. | |
795 | ||
796 | Finally, if any of the ASN.1 named types and macros defined in this | |
797 | document, specifically: | |
798 | ||
799 | Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE- | |
800 | IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT- | |
801 | IDENTITY, TimeTicks, Unsigned32, | |
802 | ||
803 | or any of those defined in [2] or [3], are used in an information | |
804 | module, then they must be imported using the IMPORTS statement. | |
805 | However, the following must not be included in an IMPORTS statement: | |
806 | ||
807 | - named types defined by ASN.1 itself, specifically: INTEGER, | |
808 | OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type, | |
809 | - the BITS construct. | |
810 | ||
811 | 3.3. Exporting Symbols | |
812 | ||
813 | The ASN.1 EXPORTS statement is not allowed in SMIv2 information | |
814 | modules. All items defined in an information module are | |
815 | automatically exported. | |
816 | ||
817 | 3.4. ASN.1 Comments | |
818 | ||
819 | ASN.1 comments can be included in an information module. However, it | |
820 | is recommended that all substantive descriptions be placed within an | |
821 | appropriate DESCRIPTION clause. | |
822 | ||
823 | ||
824 | ||
825 | McCloghrie, et al. Standards Track [Page 14] | |
826 | \f | |
827 | ||
828 | ||
829 | ||
830 | ||
831 | RFC 2578 SMIv2 April 1999 | |
832 | ||
833 | ||
834 | ASN.1 comments commence with a pair of adjacent hyphens and end with | |
835 | the next pair of adjacent hyphens or at the end of the line, | |
836 | whichever occurs first. Comments ended by a pair of hyphens have the | |
837 | effect of a single space character. | |
838 | ||
839 | 3.5. OBJECT IDENTIFIER values | |
840 | ||
841 | An OBJECT IDENTIFIER value is an ordered list of non-negative | |
842 | numbers. For the SMIv2, each number in the list is referred to as a | |
843 | sub-identifier, there are at most 128 sub-identifiers in a value, and | |
844 | each sub-identifier has a maximum value of 2^32-1 (4294967295 | |
845 | decimal). | |
846 | ||
847 | All OBJECT IDENTIFIER values have at least two sub-identifiers, where | |
848 | the value of the first sub-identifier is one of the following well- | |
849 | known names: | |
850 | ||
851 | Value Name | |
852 | 0 ccitt | |
853 | 1 iso | |
854 | 2 joint-iso-ccitt | |
855 | ||
856 | (Note that this SMI does not recognize "new" well-known names, e.g., | |
857 | as defined when the CCITT became the ITU.) | |
858 | ||
859 | 3.6. OBJECT IDENTIFIER usage | |
860 | ||
861 | OBJECT IDENTIFIERs are used in information modules in two ways: | |
862 | ||
863 | (1) registration: the definition of a particular item is registered as | |
864 | a particular OBJECT IDENTIFIER value, and associated with a | |
865 | particular descriptor. After such a registration, the semantics | |
866 | thereby associated with the value are not allowed to change, the | |
867 | OBJECT IDENTIFIER can not be used for any other registration, and | |
868 | the descriptor can not be changed nor associated with any other | |
869 | registration. The following macros result in a registration: | |
870 | ||
871 | OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP, | |
872 | OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE, | |
873 | AGENT-CAPABILITIES. | |
874 | ||
875 | (2) assignment: a descriptor can be assigned to a particular OBJECT | |
876 | IDENTIFIER value. For this usage, the semantics associated with | |
877 | the OBJECT IDENTIFIER value is not allowed to change, and a | |
878 | descriptor assigned to a particular OBJECT IDENTIFIER value cannot | |
879 | subsequently be assigned to another. However, multiple descriptors | |
880 | can be assigned to the same OBJECT IDENTIFIER value. Such | |
881 | assignments are specified in the following manner: | |
882 | ||
883 | ||
884 | McCloghrie, et al. Standards Track [Page 15] | |
885 | \f | |
886 | ||
887 | ||
888 | ||
889 | ||
890 | RFC 2578 SMIv2 April 1999 | |
891 | ||
892 | ||
893 | mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156 | |
894 | mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213 | |
895 | fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 } | |
896 | barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 } | |
897 | ||
898 | Note while the above examples are legal, the following is not: | |
899 | ||
900 | dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 } | |
901 | ||
902 | A descriptor is allowed to be associated with both a registration and | |
903 | an assignment, providing both are associated with the same OBJECT | |
904 | IDENTIFIER value and semantics. | |
905 | ||
906 | 3.7. Reserved Keywords | |
907 | ||
908 | The following are reserved keywords which must not be used as | |
909 | descriptors or module names: | |
910 | ||
911 | ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS BEGIN | |
912 | BIT BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-INFO | |
913 | CREATION-REQUIRES Counter32 Counter64 DEFAULT DEFINED | |
914 | DEFINITIONS DEFVAL DESCRIPTION DISPLAY-HINT END ENUMERATED | |
915 | ENTERPRISE EXPLICIT EXPORTS EXTERNAL FALSE FROM GROUP Gauge32 | |
916 | IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INDEX INTEGER | |
917 | Integer32 IpAddress LAST-UPDATED MANDATORY-GROUPS MAX MAX-ACCESS | |
918 | MIN MIN-ACCESS MINUS-INFINITY MODULE MODULE-COMPLIANCE MODULE- | |
919 | IDENTITY NOTIFICATION-GROUP NOTIFICATION-TYPE NOTIFICATIONS NULL | |
920 | OBJECT OBJECT-GROUP OBJECT-IDENTITY OBJECT-TYPE OBJECTS OCTET OF | |
921 | OPTIONAL ORGANIZATION Opaque PLUS-INFINITY PRESENT PRIVATE | |
922 | PRODUCT-RELEASE REAL REFERENCE REVISION SEQUENCE SET SIZE STATUS | |
923 | STRING SUPPORTS SYNTAX TAGS TEXTUAL-CONVENTION TRAP-TYPE TRUE | |
924 | TimeTicks UNITS UNIVERSAL Unsigned32 VARIABLES VARIATION WITH | |
925 | WRITE-SYNTAX | |
926 | ||
927 | 4. Naming Hierarchy | |
928 | ||
929 | The root of the subtree administered by the Internet Assigned Numbers | |
930 | Authority (IANA) for the Internet is: | |
931 | ||
932 | internet OBJECT IDENTIFIER ::= { iso 3 6 1 } | |
933 | ||
934 | That is, the Internet subtree of OBJECT IDENTIFIERs starts with the | |
935 | prefix: | |
936 | ||
937 | 1.3.6.1. | |
938 | ||
939 | Several branches underneath this subtree are used for network | |
940 | management: | |
941 | ||
942 | ||
943 | McCloghrie, et al. Standards Track [Page 16] | |
944 | \f | |
945 | ||
946 | ||
947 | ||
948 | ||
949 | RFC 2578 SMIv2 April 1999 | |
950 | ||
951 | ||
952 | mgmt OBJECT IDENTIFIER ::= { internet 2 } | |
953 | experimental OBJECT IDENTIFIER ::= { internet 3 } | |
954 | private OBJECT IDENTIFIER ::= { internet 4 } | |
955 | enterprises OBJECT IDENTIFIER ::= { private 1 } | |
956 | ||
957 | However, the SMI does not prohibit the definition of objects in other | |
958 | portions of the object tree. | |
959 | ||
960 | The mgmt(2) subtree is used to identify "standard" objects. | |
961 | ||
962 | The experimental(3) subtree is used to identify objects being | |
963 | designed by working groups of the IETF. If an information module | |
964 | produced by a working group becomes a "standard" information module, | |
965 | then at the very beginning of its entry onto the Internet standards | |
966 | track, the objects are moved under the mgmt(2) subtree. | |
967 | ||
968 | The private(4) subtree is used to identify objects defined | |
969 | unilaterally. The enterprises(1) subtree beneath private is used, | |
970 | among other things, to permit providers of networking subsystems to | |
971 | register models of their products. | |
972 | ||
973 | 5. Mapping of the MODULE-IDENTITY macro | |
974 | ||
975 | The MODULE-IDENTITY macro is used to provide contact and revision | |
976 | history for each information module. It must appear exactly once in | |
977 | every information module. It should be noted that the expansion of | |
978 | the MODULE-IDENTITY macro is something which conceptually happens | |
979 | during implementation and not during run-time. | |
980 | ||
981 | Note that reference in an IMPORTS clause or in clauses of SMIv2 | |
982 | macros to an information module is NOT through the use of the | |
983 | 'descriptor' of a MODULE-IDENTITY macro; rather, an information | |
984 | module is referenced through specifying its module name. | |
985 | ||
986 | 5.1. Mapping of the LAST-UPDATED clause | |
987 | ||
988 | The LAST-UPDATED clause, which must be present, contains the date and | |
989 | time that this information module was last edited. | |
990 | ||
991 | 5.2. Mapping of the ORGANIZATION clause | |
992 | ||
993 | The ORGANIZATION clause, which must be present, contains a textual | |
994 | description of the organization under whose auspices this information | |
995 | module was developed. | |
996 | ||
997 | ||
998 | ||
999 | ||
1000 | ||
1001 | ||
1002 | McCloghrie, et al. Standards Track [Page 17] | |
1003 | \f | |
1004 | ||
1005 | ||
1006 | ||
1007 | ||
1008 | RFC 2578 SMIv2 April 1999 | |
1009 | ||
1010 | ||
1011 | 5.3. Mapping of the CONTACT-INFO clause | |
1012 | ||
1013 | The CONTACT-INFO clause, which must be present, contains the name, | |
1014 | postal address, telephone number, and electronic mail address of the | |
1015 | person to whom technical queries concerning this information module | |
1016 | should be sent. | |
1017 | ||
1018 | 5.4. Mapping of the DESCRIPTION clause | |
1019 | ||
1020 | The DESCRIPTION clause, which must be present, contains a high-level | |
1021 | textual description of the contents of this information module. | |
1022 | ||
1023 | 5.5. Mapping of the REVISION clause | |
1024 | ||
1025 | The REVISION clause, which need not be present, is repeatedly used to | |
1026 | describe the revisions (including the initial version) made to this | |
1027 | information module, in reverse chronological order (i.e., most recent | |
1028 | first). Each instance of this clause contains the date and time of | |
1029 | the revision. | |
1030 | ||
1031 | 5.5.1. Mapping of the DESCRIPTION sub-clause | |
1032 | ||
1033 | The DESCRIPTION sub-clause, which must be present for each REVISION | |
1034 | clause, contains a high-level textual description of the revision | |
1035 | identified in that REVISION clause. | |
1036 | ||
1037 | 5.6. Mapping of the MODULE-IDENTITY value | |
1038 | ||
1039 | The value of an invocation of the MODULE-IDENTITY macro is an OBJECT | |
1040 | IDENTIFIER. As such, this value may be authoritatively used when | |
1041 | specifying an OBJECT IDENTIFIER value to refer to the information | |
1042 | module containing the invocation. | |
1043 | ||
1044 | Note that it is a common practice to use the value of the MODULE- | |
1045 | IDENTITY macro as a subtree under which other OBJECT IDENTIFIER | |
1046 | values assigned within the module are defined. However, it is legal | |
1047 | (and occasionally necessary) for the other OBJECT IDENTIFIER values | |
1048 | assigned within the module to be unrelated to the OBJECT IDENTIFIER | |
1049 | value of the MODULE-IDENTITY macro. | |
1050 | ||
1051 | 5.7. Usage Example | |
1052 | ||
1053 | Consider how a skeletal MIB module might be constructed: e.g., | |
1054 | ||
1055 | FIZBIN-MIB DEFINITIONS ::= BEGIN | |
1056 | ||
1057 | IMPORTS | |
1058 | MODULE-IDENTITY, OBJECT-TYPE, experimental | |
1059 | ||
1060 | ||
1061 | McCloghrie, et al. Standards Track [Page 18] | |
1062 | \f | |
1063 | ||
1064 | ||
1065 | ||
1066 | ||
1067 | RFC 2578 SMIv2 April 1999 | |
1068 | ||
1069 | ||
1070 | FROM SNMPv2-SMI; | |
1071 | ||
1072 | ||
1073 | fizbin MODULE-IDENTITY | |
1074 | LAST-UPDATED "199505241811Z" | |
1075 | ORGANIZATION "IETF SNMPv2 Working Group" | |
1076 | CONTACT-INFO | |
1077 | " Marshall T. Rose | |
1078 | ||
1079 | Postal: Dover Beach Consulting, Inc. | |
1080 | 420 Whisman Court | |
1081 | Mountain View, CA 94043-2186 | |
1082 | US | |
1083 | ||
1084 | Tel: +1 415 968 1052 | |
1085 | Fax: +1 415 968 2510 | |
1086 | ||
1087 | E-mail: mrose@dbc.mtview.ca.us" | |
1088 | ||
1089 | DESCRIPTION | |
1090 | "The MIB module for entities implementing the xxxx | |
1091 | protocol." | |
1092 | REVISION "9505241811Z" | |
1093 | DESCRIPTION | |
1094 | "The latest version of this MIB module." | |
1095 | REVISION "9210070433Z" | |
1096 | DESCRIPTION | |
1097 | "The initial version of this MIB module, published in | |
1098 | RFC yyyy." | |
1099 | -- contact IANA for actual number | |
1100 | ::= { experimental xx } | |
1101 | ||
1102 | END | |
1103 | ||
1104 | 6. Mapping of the OBJECT-IDENTITY macro | |
1105 | ||
1106 | The OBJECT-IDENTITY macro is used to define information about an | |
1107 | OBJECT IDENTIFIER assignment. All administrative OBJECT IDENTIFIER | |
1108 | assignments which define a type identification value (see | |
1109 | AutonomousType, a textual convention defined in [3]) should be | |
1110 | defined via the OBJECT-IDENTITY macro. It should be noted that the | |
1111 | expansion of the OBJECT-IDENTITY macro is something which | |
1112 | conceptually happens during implementation and not during run-time. | |
1113 | ||
1114 | 6.1. Mapping of the STATUS clause | |
1115 | ||
1116 | The STATUS clause, which must be present, indicates whether this | |
1117 | definition is current or historic. | |
1118 | ||
1119 | ||
1120 | McCloghrie, et al. Standards Track [Page 19] | |
1121 | \f | |
1122 | ||
1123 | ||
1124 | ||
1125 | ||
1126 | RFC 2578 SMIv2 April 1999 | |
1127 | ||
1128 | ||
1129 | The value "current" means that the definition is current and valid. | |
1130 | The value "obsolete" means the definition is obsolete and should not | |
1131 | be implemented and/or can be removed if previously implemented. | |
1132 | While the value "deprecated" also indicates an obsolete definition, | |
1133 | it permits new/continued implementation in order to foster | |
1134 | interoperability with older/existing implementations. | |
1135 | ||
1136 | 6.2. Mapping of the DESCRIPTION clause | |
1137 | ||
1138 | The DESCRIPTION clause, which must be present, contains a textual | |
1139 | description of the object assignment. | |
1140 | ||
1141 | 6.3. Mapping of the REFERENCE clause | |
1142 | ||
1143 | The REFERENCE clause, which need not be present, contains a textual | |
1144 | cross-reference to some other document, either another information | |
1145 | module which defines a related assignment, or some other document | |
1146 | which provides additional information relevant to this definition. | |
1147 | ||
1148 | 6.4. Mapping of the OBJECT-IDENTITY value | |
1149 | ||
1150 | The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT | |
1151 | IDENTIFIER. | |
1152 | ||
1153 | 6.5. Usage Example | |
1154 | ||
1155 | Consider how an OBJECT IDENTIFIER assignment might be made: e.g., | |
1156 | ||
1157 | fizbin69 OBJECT-IDENTITY | |
1158 | STATUS current | |
1159 | DESCRIPTION | |
1160 | "The authoritative identity of the Fizbin 69 chipset." | |
1161 | ::= { fizbinChipSets 1 } | |
1162 | ||
1163 | 7. Mapping of the OBJECT-TYPE macro | |
1164 | ||
1165 | The OBJECT-TYPE macro is used to define a type of managed object. It | |
1166 | should be noted that the expansion of the OBJECT-TYPE macro is | |
1167 | something which conceptually happens during implementation and not | |
1168 | during run-time. | |
1169 | ||
1170 | For leaf objects which are not columnar objects (i.e., not contained | |
1171 | within a conceptual table), instances of the object are identified by | |
1172 | appending a sub-identifier of zero to the name of that object. | |
1173 | Otherwise, the INDEX clause of the conceptual row object superior to | |
1174 | a columnar object defines instance identification information. | |
1175 | ||
1176 | ||
1177 | ||
1178 | ||
1179 | McCloghrie, et al. Standards Track [Page 20] | |
1180 | \f | |
1181 | ||
1182 | ||
1183 | ||
1184 | ||
1185 | RFC 2578 SMIv2 April 1999 | |
1186 | ||
1187 | ||
1188 | 7.1. Mapping of the SYNTAX clause | |
1189 | ||
1190 | The SYNTAX clause, which must be present, defines the abstract data | |
1191 | structure corresponding to that object. The data structure must be | |
1192 | one of the following: a base type, the BITS construct, or a textual | |
1193 | convention. (SEQUENCE OF and SEQUENCE are also possible for | |
1194 | conceptual tables, see section 7.1.12). The base types are those | |
1195 | defined in the ObjectSyntax CHOICE. A textual convention is a | |
1196 | newly-defined type defined as a sub-type of a base type [3]. | |
1197 | ||
1198 | An extended subset of the full capabilities of ASN.1 (1988) sub- | |
1199 | typing is allowed, as appropriate to the underlying ASN.1 type. Any | |
1200 | such restriction on size, range or enumerations specified in this | |
1201 | clause represents the maximal level of support which makes "protocol | |
1202 | sense". Restrictions on sub-typing are specified in detail in | |
1203 | Section 9 and Appendix A of this memo. | |
1204 | ||
1205 | The semantics of ObjectSyntax are now described. | |
1206 | ||
1207 | 7.1.1. Integer32 and INTEGER | |
1208 | ||
1209 | The Integer32 type represents integer-valued information between | |
1210 | -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This | |
1211 | type is indistinguishable from the INTEGER type. Both the INTEGER | |
1212 | and Integer32 types may be sub-typed to be more constrained than the | |
1213 | Integer32 type. | |
1214 | ||
1215 | The INTEGER type (but not the Integer32 type) may also be used to | |
1216 | represent integer-valued information as named-number enumerations. | |
1217 | In this case, only those named-numbers so enumerated may be present | |
1218 | as a value. Note that although it is recommended that enumerated | |
1219 | values start at 1 and be numbered contiguously, any valid value for | |
1220 | Integer32 is allowed for an enumerated value and, further, enumerated | |
1221 | values needn't be contiguously assigned. | |
1222 | ||
1223 | Finally, a label for a named-number enumeration must consist of one | |
1224 | or more letters or digits, up to a maximum of 64 characters, and the | |
1225 | initial character must be a lower-case letter. (However, labels | |
1226 | longer than 32 characters are not recommended.) Note that hyphens | |
1227 | are not allowed by this specification (except for use by information | |
1228 | modules converted from SMIv1 which did allow hyphens). | |
1229 | ||
1230 | 7.1.2. OCTET STRING | |
1231 | ||
1232 | The OCTET STRING type represents arbitrary binary or textual data. | |
1233 | Although the SMI-specified size limitation for this type is 65535 | |
1234 | octets, MIB designers should realize that there may be implementation | |
1235 | and interoperability limitations for sizes in excess of 255 octets. | |
1236 | ||
1237 | ||
1238 | McCloghrie, et al. Standards Track [Page 21] | |
1239 | \f | |
1240 | ||
1241 | ||
1242 | ||
1243 | ||
1244 | RFC 2578 SMIv2 April 1999 | |
1245 | ||
1246 | ||
1247 | 7.1.3. OBJECT IDENTIFIER | |
1248 | ||
1249 | The OBJECT IDENTIFIER type represents administratively assigned | |
1250 | names. Any instance of this type may have at most 128 sub- | |
1251 | identifiers. Further, each sub-identifier must not exceed the value | |
1252 | 2^32-1 (4294967295 decimal). | |
1253 | ||
1254 | 7.1.4. The BITS construct | |
1255 | ||
1256 | The BITS construct represents an enumeration of named bits. This | |
1257 | collection is assigned non-negative, contiguous (but see below) | |
1258 | values, starting at zero. Only those named-bits so enumerated may be | |
1259 | present in a value. (Thus, enumerations must be assigned to | |
1260 | consecutive bits; however, see Section 9 for refinements of an object | |
1261 | with this syntax.) | |
1262 | ||
1263 | As part of updating an information module, for an object defined | |
1264 | using the BITS construct, new enumerations can be added or existing | |
1265 | enumerations can have new labels assigned to them. After an | |
1266 | enumeration is added, it might not be possible to distinguish between | |
1267 | an implementation of the updated object for which the new enumeration | |
1268 | is not asserted, and an implementation of the object prior to the | |
1269 | addition. Depending on the circumstances, such an ambiguity could | |
1270 | either be desirable or could be undesirable. The means to avoid such | |
1271 | an ambiguity is dependent on the encoding of values on the wire; | |
1272 | however, one possibility is to define new enumerations starting at | |
1273 | the next multiple of eight bits. (Of course, this can also result in | |
1274 | the enumerations no longer being contiguous.) | |
1275 | ||
1276 | Although there is no SMI-specified limitation on the number of | |
1277 | enumerations (and therefore on the length of a value), except as may | |
1278 | be imposed by the limit on the length of an OCTET STRING, MIB | |
1279 | designers should realize that there may be implementation and | |
1280 | interoperability limitations for sizes in excess of 128 bits. | |
1281 | ||
1282 | Finally, a label for a named-number enumeration must consist of one | |
1283 | or more letters or digits, up to a maximum of 64 characters, and the | |
1284 | initial character must be a lower-case letter. (However, labels | |
1285 | longer than 32 characters are not recommended.) Note that hyphens | |
1286 | are not allowed by this specification. | |
1287 | ||
1288 | 7.1.5. IpAddress | |
1289 | ||
1290 | The IpAddress type represents a 32-bit internet address. It is | |
1291 | represented as an OCTET STRING of length 4, in network byte-order. | |
1292 | ||
1293 | ||
1294 | ||
1295 | ||
1296 | ||
1297 | McCloghrie, et al. Standards Track [Page 22] | |
1298 | \f | |
1299 | ||
1300 | ||
1301 | ||
1302 | ||
1303 | RFC 2578 SMIv2 April 1999 | |
1304 | ||
1305 | ||
1306 | Note that the IpAddress type is a tagged type for historical reasons. | |
1307 | Network addresses should be represented using an invocation of the | |
1308 | TEXTUAL-CONVENTION macro [3]. | |
1309 | ||
1310 | 7.1.6. Counter32 | |
1311 | ||
1312 | The Counter32 type represents a non-negative integer which | |
1313 | monotonically increases until it reaches a maximum value of 2^32-1 | |
1314 | (4294967295 decimal), when it wraps around and starts increasing | |
1315 | again from zero. | |
1316 | ||
1317 | Counters have no defined "initial" value, and thus, a single value of | |
1318 | a Counter has (in general) no information content. Discontinuities | |
1319 | in the monotonically increasing value normally occur at re- | |
1320 | initialization of the management system, and at other times as | |
1321 | specified in the description of an object-type using this ASN.1 type. | |
1322 | If such other times can occur, for example, the creation of an object | |
1323 | instance at times other than re-initialization, then a corresponding | |
1324 | object should be defined, with an appropriate SYNTAX clause, to | |
1325 | indicate the last discontinuity. Examples of appropriate SYNTAX | |
1326 | clause include: TimeStamp (a textual convention defined in [3]), | |
1327 | DateAndTime (another textual convention from [3]) or TimeTicks. | |
1328 | ||
1329 | The value of the MAX-ACCESS clause for objects with a SYNTAX clause | |
1330 | value of Counter32 is either "read-only" or "accessible-for-notify". | |
1331 | ||
1332 | A DEFVAL clause is not allowed for objects with a SYNTAX clause value | |
1333 | of Counter32. | |
1334 | ||
1335 | 7.1.7. Gauge32 | |
1336 | ||
1337 | The Gauge32 type represents a non-negative integer, which may | |
1338 | increase or decrease, but shall never exceed a maximum value, nor | |
1339 | fall below a minimum value. The maximum value can not be greater | |
1340 | than 2^32-1 (4294967295 decimal), and the minimum value can not be | |
1341 | smaller than 0. The value of a Gauge32 has its maximum value | |
1342 | whenever the information being modeled is greater than or equal to | |
1343 | its maximum value, and has its minimum value whenever the information | |
1344 | being modeled is smaller than or equal to its minimum value. If the | |
1345 | information being modeled subsequently decreases below (increases | |
1346 | above) the maximum (minimum) value, the Gauge32 also decreases | |
1347 | (increases). (Note that despite of the use of the term "latched" in | |
1348 | the original definition of this type, it does not become "stuck" at | |
1349 | its maximum or minimum value.) | |
1350 | ||
1351 | ||
1352 | ||
1353 | ||
1354 | ||
1355 | ||
1356 | McCloghrie, et al. Standards Track [Page 23] | |
1357 | \f | |
1358 | ||
1359 | ||
1360 | ||
1361 | ||
1362 | RFC 2578 SMIv2 April 1999 | |
1363 | ||
1364 | ||
1365 | 7.1.8. TimeTicks | |
1366 | ||
1367 | The TimeTicks type represents a non-negative integer which represents | |
1368 | the time, modulo 2^32 (4294967296 decimal), in hundredths of a second | |
1369 | between two epochs. When objects are defined which use this ASN.1 | |
1370 | type, the description of the object identifies both of the reference | |
1371 | epochs. | |
1372 | ||
1373 | For example, [3] defines the TimeStamp textual convention which is | |
1374 | based on the TimeTicks type. With a TimeStamp, the first reference | |
1375 | epoch is defined as the time when sysUpTime [5] was zero, and the | |
1376 | second reference epoch is defined as the current value of sysUpTime. | |
1377 | ||
1378 | The TimeTicks type may not be sub-typed. | |
1379 | ||
1380 | 7.1.9. Opaque | |
1381 | ||
1382 | The Opaque type is provided solely for backward-compatibility, and | |
1383 | shall not be used for newly-defined object types. | |
1384 | ||
1385 | The Opaque type supports the capability to pass arbitrary ASN.1 | |
1386 | syntax. A value is encoded using the ASN.1 Basic Encoding Rules [4] | |
1387 | into a string of octets. This, in turn, is encoded as an OCTET | |
1388 | STRING, in effect "double-wrapping" the original ASN.1 value. | |
1389 | ||
1390 | Note that a conforming implementation need only be able to accept and | |
1391 | recognize opaquely-encoded data. It need not be able to unwrap the | |
1392 | data and then interpret its contents. | |
1393 | ||
1394 | A requirement on "standard" MIB modules is that no object may have a | |
1395 | SYNTAX clause value of Opaque. | |
1396 | ||
1397 | 7.1.10. Counter64 | |
1398 | ||
1399 | The Counter64 type represents a non-negative integer which | |
1400 | monotonically increases until it reaches a maximum value of 2^64-1 | |
1401 | (18446744073709551615 decimal), when it wraps around and starts | |
1402 | increasing again from zero. | |
1403 | ||
1404 | Counters have no defined "initial" value, and thus, a single value of | |
1405 | a Counter has (in general) no information content. Discontinuities | |
1406 | in the monotonically increasing value normally occur at re- | |
1407 | initialization of the management system, and at other times as | |
1408 | specified in the description of an object-type using this ASN.1 type. | |
1409 | If such other times can occur, for example, the creation of an object | |
1410 | instance at times other than re-initialization, then a corresponding | |
1411 | object should be defined, with an appropriate SYNTAX clause, to | |
1412 | indicate the last discontinuity. Examples of appropriate SYNTAX | |
1413 | ||
1414 | ||
1415 | McCloghrie, et al. Standards Track [Page 24] | |
1416 | \f | |
1417 | ||
1418 | ||
1419 | ||
1420 | ||
1421 | RFC 2578 SMIv2 April 1999 | |
1422 | ||
1423 | ||
1424 | clause are: TimeStamp (a textual convention defined in [3]), | |
1425 | DateAndTime (another textual convention from [3]) or TimeTicks. | |
1426 | ||
1427 | The value of the MAX-ACCESS clause for objects with a SYNTAX clause | |
1428 | value of Counter64 is either "read-only" or "accessible-for-notify". | |
1429 | ||
1430 | A requirement on "standard" MIB modules is that the Counter64 type | |
1431 | may be used only if the information being modeled would wrap in less | |
1432 | than one hour if the Counter32 type was used instead. | |
1433 | ||
1434 | A DEFVAL clause is not allowed for objects with a SYNTAX clause value | |
1435 | of Counter64. | |
1436 | ||
1437 | 7.1.11. Unsigned32 | |
1438 | ||
1439 | The Unsigned32 type represents integer-valued information between 0 | |
1440 | and 2^32-1 inclusive (0 to 4294967295 decimal). | |
1441 | ||
1442 | 7.1.12. Conceptual Tables | |
1443 | ||
1444 | Management operations apply exclusively to scalar objects. However, | |
1445 | it is sometimes convenient for developers of management applications | |
1446 | to impose an imaginary, tabular structure on an ordered collection of | |
1447 | objects within the MIB. Each such conceptual table contains zero or | |
1448 | more rows, and each row may contain one or more scalar objects, | |
1449 | termed columnar objects. This conceptualization is formalized by | |
1450 | using the OBJECT-TYPE macro to define both an object which | |
1451 | corresponds to a table and an object which corresponds to a row in | |
1452 | that table. A conceptual table has SYNTAX of the form: | |
1453 | ||
1454 | SEQUENCE OF <EntryType> | |
1455 | ||
1456 | where <EntryType> refers to the SEQUENCE type of its subordinate | |
1457 | conceptual row. A conceptual row has SYNTAX of the form: | |
1458 | ||
1459 | <EntryType> | |
1460 | ||
1461 | where <EntryType> is a SEQUENCE type defined as follows: | |
1462 | ||
1463 | <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> } | |
1464 | ||
1465 | where there is one <type> for each subordinate object, and each | |
1466 | <type> is of the form: | |
1467 | ||
1468 | <descriptor> <syntax> | |
1469 | ||
1470 | where <descriptor> is the descriptor naming a subordinate object, and | |
1471 | <syntax> has the value of that subordinate object's SYNTAX clause, | |
1472 | ||
1473 | ||
1474 | McCloghrie, et al. Standards Track [Page 25] | |
1475 | \f | |
1476 | ||
1477 | ||
1478 | ||
1479 | ||
1480 | RFC 2578 SMIv2 April 1999 | |
1481 | ||
1482 | ||
1483 | except that both sub-typing information and the named values for | |
1484 | enumerated integers or the named bits for the BITS construct, are | |
1485 | omitted from <syntax>. | |
1486 | ||
1487 | Further, a <type> is always present for every subordinate object. | |
1488 | (The ASN.1 DEFAULT and OPTIONAL clauses are disallowed in the | |
1489 | SEQUENCE definition.) The MAX-ACCESS clause for conceptual tables | |
1490 | and rows is "not-accessible". | |
1491 | ||
1492 | 7.1.12.1. Creation and Deletion of Conceptual Rows | |
1493 | ||
1494 | For newly-defined conceptual rows which allow the creation of new | |
1495 | object instances and/or the deletion of existing object instances, | |
1496 | there should be one columnar object with a SYNTAX clause value of | |
1497 | RowStatus (a textual convention defined in [3]) and a MAX-ACCESS | |
1498 | clause value of read-create. By convention, this is termed the | |
1499 | status column for the conceptual row. | |
1500 | ||
1501 | 7.2. Mapping of the UNITS clause | |
1502 | ||
1503 | This UNITS clause, which need not be present, contains a textual | |
1504 | definition of the units associated with that object. | |
1505 | ||
1506 | 7.3. Mapping of the MAX-ACCESS clause | |
1507 | ||
1508 | The MAX-ACCESS clause, which must be present, defines whether it | |
1509 | makes "protocol sense" to read, write and/or create an instance of | |
1510 | the object, or to include its value in a notification. This is the | |
1511 | maximal level of access for the object. (This maximal level of | |
1512 | access is independent of any administrative authorization policy.) | |
1513 | ||
1514 | The value "read-write" indicates that read and write access make | |
1515 | "protocol sense", but create does not. The value "read-create" | |
1516 | indicates that read, write and create access make "protocol sense". | |
1517 | The value "not-accessible" indicates an auxiliary object (see Section | |
1518 | 7.7). The value "accessible-for-notify" indicates an object which is | |
1519 | accessible only via a notification (e.g., snmpTrapOID [5]). | |
1520 | ||
1521 | These values are ordered, from least to greatest: "not-accessible", | |
1522 | "accessible-for-notify", "read-only", "read-write", "read-create". | |
1523 | ||
1524 | If any columnar object in a conceptual row has "read-create" as its | |
1525 | maximal level of access, then no other columnar object of the same | |
1526 | conceptual row may have a maximal access of "read-write". (Note that | |
1527 | "read-create" is a superset of "read-write".) | |
1528 | ||
1529 | ||
1530 | ||
1531 | ||
1532 | ||
1533 | McCloghrie, et al. Standards Track [Page 26] | |
1534 | \f | |
1535 | ||
1536 | ||
1537 | ||
1538 | ||
1539 | RFC 2578 SMIv2 April 1999 | |
1540 | ||
1541 | ||
1542 | 7.4. Mapping of the STATUS clause | |
1543 | ||
1544 | The STATUS clause, which must be present, indicates whether this | |
1545 | definition is current or historic. | |
1546 | ||
1547 | The value "current" means that the definition is current and valid. | |
1548 | The value "obsolete" means the definition is obsolete and should not | |
1549 | be implemented and/or can be removed if previously implemented. | |
1550 | While the value "deprecated" also indicates an obsolete definition, | |
1551 | it permits new/continued implementation in order to foster | |
1552 | interoperability with older/existing implementations. | |
1553 | ||
1554 | 7.5. Mapping of the DESCRIPTION clause | |
1555 | ||
1556 | The DESCRIPTION clause, which must be present, contains a textual | |
1557 | definition of that object which provides all semantic definitions | |
1558 | necessary for implementation, and should embody any information which | |
1559 | would otherwise be communicated in any ASN.1 commentary annotations | |
1560 | associated with the object. | |
1561 | ||
1562 | 7.6. Mapping of the REFERENCE clause | |
1563 | ||
1564 | The REFERENCE clause, which need not be present, contains a textual | |
1565 | cross-reference to some other document, either another information | |
1566 | module which defines a related assignment, or some other document | |
1567 | which provides additional information relevant to this definition. | |
1568 | ||
1569 | 7.7. Mapping of the INDEX clause | |
1570 | ||
1571 | The INDEX clause, which must be present if that object corresponds to | |
1572 | a conceptual row (unless an AUGMENTS clause is present instead), and | |
1573 | must be absent otherwise, defines instance identification information | |
1574 | for the columnar objects subordinate to that object. | |
1575 | ||
1576 | The instance identification information in an INDEX clause must | |
1577 | specify object(s) such that value(s) of those object(s) will | |
1578 | unambiguously distinguish a conceptual row. The objects can be | |
1579 | columnar objects from the same and/or another conceptual table, but | |
1580 | must not be scalar objects. Multiple occurrences of the same object | |
1581 | in a single INDEX clause is strongly discouraged. | |
1582 | ||
1583 | The syntax of the objects in the INDEX clause indicate how to form | |
1584 | the instance-identifier: | |
1585 | ||
1586 | (1) integer-valued (i.e., having INTEGER as its underlying primitive | |
1587 | type): a single sub-identifier taking the integer value (this | |
1588 | works only for non-negative integers); | |
1589 | ||
1590 | ||
1591 | ||
1592 | McCloghrie, et al. Standards Track [Page 27] | |
1593 | \f | |
1594 | ||
1595 | ||
1596 | ||
1597 | ||
1598 | RFC 2578 SMIv2 April 1999 | |
1599 | ||
1600 | ||
1601 | (2) string-valued, fixed-length strings (or variable-length preceded by | |
1602 | the IMPLIED keyword): `n' sub-identifiers, where `n' is the length | |
1603 | of the string (each octet of the string is encoded in a separate | |
1604 | sub-identifier); | |
1605 | ||
1606 | (3) string-valued, variable-length strings (not preceded by the IMPLIED | |
1607 | keyword): `n+1' sub-identifiers, where `n' is the length of the | |
1608 | string (the first sub-identifier is `n' itself, following this, | |
1609 | each octet of the string is encoded in a separate sub-identifier); | |
1610 | ||
1611 | (4) object identifier-valued (when preceded by the IMPLIED keyword): | |
1612 | `n' sub-identifiers, where `n' is the number of sub-identifiers in | |
1613 | the value (each sub-identifier of the value is copied into a | |
1614 | separate sub-identifier); | |
1615 | ||
1616 | (5) object identifier-valued (when not preceded by the IMPLIED | |
1617 | keyword): `n+1' sub-identifiers, where `n' is the number of sub- | |
1618 | identifiers in the value (the first sub-identifier is `n' itself, | |
1619 | following this, each sub-identifier in the value is copied); | |
1620 | ||
1621 | (6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d | |
1622 | notation. | |
1623 | ||
1624 | Note that the IMPLIED keyword can only be present for an object | |
1625 | having a variable-length syntax (e.g., variable-length strings or | |
1626 | object identifier-valued objects), Further, the IMPLIED keyword can | |
1627 | only be associated with the last object in the INDEX clause. | |
1628 | Finally, the IMPLIED keyword may not be used on a variable-length | |
1629 | string object if that string might have a value of zero-length. | |
1630 | ||
1631 | Since a single value of a Counter has (in general) no information | |
1632 | content (see section 7.1.6 and 7.1.10), objects defined using the | |
1633 | syntax, Counter32 or Counter64, must not be specified in an INDEX | |
1634 | ||
1635 | clause. If an object defined using the BITS construct is used in an | |
1636 | INDEX clause, it is considered a variable-length string. | |
1637 | ||
1638 | Instances identified by use of integer-valued objects should be | |
1639 | numbered starting from one (i.e., not from zero). The use of zero as | |
1640 | a value for an integer-valued index object should be avoided, except | |
1641 | in special cases. | |
1642 | ||
1643 | Objects which are both specified in the INDEX clause of a conceptual | |
1644 | row and also columnar objects of the same conceptual row are termed | |
1645 | auxiliary objects. The MAX-ACCESS clause for auxiliary objects is | |
1646 | "not-accessible", except in the following circumstances: | |
1647 | ||
1648 | ||
1649 | ||
1650 | ||
1651 | McCloghrie, et al. Standards Track [Page 28] | |
1652 | \f | |
1653 | ||
1654 | ||
1655 | ||
1656 | ||
1657 | RFC 2578 SMIv2 April 1999 | |
1658 | ||
1659 | ||
1660 | (1) within a MIB module originally written to conform to SMIv1, and | |
1661 | later converted to conform to SMIv2; or | |
1662 | ||
1663 | (2) a conceptual row must contain at least one columnar object which is | |
1664 | not an auxiliary object. In the event that all of a conceptual | |
1665 | row's columnar objects are also specified in its INDEX clause, then | |
1666 | one of them must be accessible, i.e., have a MAX-ACCESS clause of | |
1667 | "read-only". (Note that this situation does not arise for a | |
1668 | conceptual row allowing create access, since such a row will have a | |
1669 | status column which will not be an auxiliary object.) | |
1670 | ||
1671 | Note that objects specified in a conceptual row's INDEX clause need | |
1672 | not be columnar objects of that conceptual row. In this situation, | |
1673 | the DESCRIPTION clause of the conceptual row must include a textual | |
1674 | explanation of how the objects which are included in the INDEX clause | |
1675 | but not columnar objects of that conceptual row, are used in uniquely | |
1676 | identifying instances of the conceptual row's columnar objects. | |
1677 | ||
1678 | 7.8. Mapping of the AUGMENTS clause | |
1679 | ||
1680 | The AUGMENTS clause, which must not be present unless the object | |
1681 | corresponds to a conceptual row, is an alternative to the INDEX | |
1682 | clause. Every object corresponding to a conceptual row has either an | |
1683 | INDEX clause or an AUGMENTS clause. | |
1684 | ||
1685 | If an object corresponding to a conceptual row has an INDEX clause, | |
1686 | that row is termed a base conceptual row; alternatively, if the | |
1687 | object has an AUGMENTS clause, the row is said to be a conceptual row | |
1688 | augmentation, where the AUGMENTS clause names the object | |
1689 | corresponding to the base conceptual row which is augmented by this | |
1690 | conceptual row augmentation. (Thus, a conceptual row augmentation | |
1691 | cannot itself be augmented.) Instances of subordinate columnar | |
1692 | objects of a conceptual row augmentation are identified according to | |
1693 | the INDEX clause of the base conceptual row corresponding to the | |
1694 | object named in the AUGMENTS clause. Further, instances of | |
1695 | subordinate columnar objects of a conceptual row augmentation exist | |
1696 | according to the same semantics as instances of subordinate columnar | |
1697 | objects of the base conceptual row being augmented. As such, note | |
1698 | that creation of a base conceptual row implies the correspondent | |
1699 | creation of any conceptual row augmentations. | |
1700 | ||
1701 | For example, a MIB designer might wish to define additional columns | |
1702 | in an "enterprise-specific" MIB which logically extend a conceptual | |
1703 | row in a "standard" MIB. The "standard" MIB definition of the | |
1704 | conceptual row would include the INDEX clause and the "enterprise- | |
1705 | specific" MIB would contain the definition of a conceptual row using | |
1706 | the AUGMENTS clause. On the other hand, it would be incorrect to use | |
1707 | the AUGMENTS clause for the relationship between RFC 2233's ifTable | |
1708 | ||
1709 | ||
1710 | McCloghrie, et al. Standards Track [Page 29] | |
1711 | \f | |
1712 | ||
1713 | ||
1714 | ||
1715 | ||
1716 | RFC 2578 SMIv2 April 1999 | |
1717 | ||
1718 | ||
1719 | and the many media-specific MIBs which extend it for specific media | |
1720 | (e.g., the dot3Table in RFC 2358), since not all interfaces are of | |
1721 | the same media. | |
1722 | ||
1723 | Note that a base conceptual row may be augmented by multiple | |
1724 | conceptual row augmentations. | |
1725 | ||
1726 | 7.8.1. Relation between INDEX and AUGMENTS clauses | |
1727 | ||
1728 | When defining instance identification information for a conceptual | |
1729 | table: | |
1730 | ||
1731 | (1) If there is a one-to-one correspondence between the conceptual rows | |
1732 | of this table and an existing table, then the AUGMENTS clause | |
1733 | should be used. | |
1734 | ||
1735 | (2) Otherwise, if there is a sparse relationship between the conceptual | |
1736 | rows of this table and an existing table, then an INDEX clause | |
1737 | should be used which is identical to that in the existing table. | |
1738 | For example, the relationship between RFC 2233's ifTable and a | |
1739 | media-specific MIB which extends the ifTable for a specific media | |
1740 | (e.g., the dot3Table in RFC 2358), is a sparse relationship. | |
1741 | ||
1742 | (3) Otherwise, if no existing objects have the required syntax and | |
1743 | semantics, then auxiliary objects should be defined within the | |
1744 | conceptual row for the new table, and those objects should be used | |
1745 | within the INDEX clause for the conceptual row. | |
1746 | ||
1747 | 7.9. Mapping of the DEFVAL clause | |
1748 | ||
1749 | The DEFVAL clause, which need not be present, defines an acceptable | |
1750 | default value which may be used at the discretion of an agent when an | |
1751 | object instance is created. That is, the value is a "hint" to | |
1752 | implementors. | |
1753 | ||
1754 | During conceptual row creation, if an instance of a columnar object | |
1755 | is not present as one of the operands in the correspondent management | |
1756 | protocol set operation, then the value of the DEFVAL clause, if | |
1757 | present, indicates an acceptable default value that an agent might | |
1758 | use (especially for a read-only object). | |
1759 | ||
1760 | Note that with this definition of the DEFVAL clause, it is | |
1761 | appropriate to use it for any columnar object of a read-create table. | |
1762 | It is also permitted to use it for scalar objects dynamically created | |
1763 | by an agent, or for columnar objects of a read-write table | |
1764 | dynamically created by an agent. | |
1765 | ||
1766 | ||
1767 | ||
1768 | ||
1769 | McCloghrie, et al. Standards Track [Page 30] | |
1770 | \f | |
1771 | ||
1772 | ||
1773 | ||
1774 | ||
1775 | RFC 2578 SMIv2 April 1999 | |
1776 | ||
1777 | ||
1778 | The value of the DEFVAL clause must, of course, correspond to the | |
1779 | SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER, | |
1780 | then it must be expressed as a single ASN.1 identifier, and not as a | |
1781 | collection of sub-identifiers. | |
1782 | ||
1783 | Note that if an operand to the management protocol set operation is | |
1784 | an instance of a read-only object, then the error `notWritable' [6] | |
1785 | will be returned. As such, the DEFVAL clause can be used to provide | |
1786 | an acceptable default value that an agent might use. | |
1787 | ||
1788 | By way of example, consider the following possible DEFVAL clauses: | |
1789 | ||
1790 | ObjectSyntax DEFVAL clause | |
1791 | ---------------- ------------ | |
1792 | Integer32 DEFVAL { 1 } | |
1793 | -- same for Gauge32, TimeTicks, Unsigned32 | |
1794 | INTEGER DEFVAL { valid } -- enumerated value | |
1795 | OCTET STRING DEFVAL { 'ffffffffffff'H } | |
1796 | DisplayString DEFVAL { "SNMP agent" } | |
1797 | IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21 | |
1798 | OBJECT IDENTIFIER DEFVAL { sysDescr } | |
1799 | BITS DEFVAL { { primary, secondary } } | |
1800 | -- enumerated values that are set | |
1801 | BITS DEFVAL { { } } | |
1802 | -- no enumerated values are set | |
1803 | ||
1804 | A binary string used in a DEFVAL clause for an OCTET STRING must be | |
1805 | either an integral multiple of eight or zero bits in length; | |
1806 | similarly, a hexadecimal string must be an even number of hexadecimal | |
1807 | digits. The value of a character string used in a DEFVAL clause must | |
1808 | not contain tab characters or line terminator characters. | |
1809 | ||
1810 | Object types with SYNTAX of Counter32 and Counter64 may not have | |
1811 | DEFVAL clauses, since they do not have defined initial values. | |
1812 | However, it is recommended that they be initialized to zero. | |
1813 | ||
1814 | 7.10. Mapping of the OBJECT-TYPE value | |
1815 | ||
1816 | The value of an invocation of the OBJECT-TYPE macro is the name of | |
1817 | the object, which is an OBJECT IDENTIFIER, an administratively | |
1818 | assigned name. | |
1819 | ||
1820 | When an OBJECT IDENTIFIER is assigned to an object: | |
1821 | ||
1822 | (1) If the object corresponds to a conceptual table, then only a single | |
1823 | assignment, that for a conceptual row, is present immediately | |
1824 | beneath that object. The administratively assigned name for the | |
1825 | conceptual row object is derived by appending a sub-identifier of | |
1826 | ||
1827 | ||
1828 | McCloghrie, et al. Standards Track [Page 31] | |
1829 | \f | |
1830 | ||
1831 | ||
1832 | ||
1833 | ||
1834 | RFC 2578 SMIv2 April 1999 | |
1835 | ||
1836 | ||
1837 | "1" to the administratively assigned name for the conceptual table. | |
1838 | ||
1839 | (2) If the object corresponds to a conceptual row, then at least one | |
1840 | assignment, one for each column in the conceptual row, is present | |
1841 | beneath that object. The administratively assigned name for each | |
1842 | column is derived by appending a unique, positive sub-identifier to | |
1843 | the administratively assigned name for the conceptual row. | |
1844 | ||
1845 | (3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the | |
1846 | object may be assigned. | |
1847 | ||
1848 | Note that the final sub-identifier of any administratively assigned | |
1849 | name for an object shall be positive. A zero-valued final sub- | |
1850 | identifier is reserved for future use. | |
1851 | ||
1852 | 7.11. Usage Example | |
1853 | ||
1854 | Consider how one might define a conceptual table and its | |
1855 | subordinates. (This example uses the RowStatus textual convention | |
1856 | defined in [3].) | |
1857 | ||
1858 | evalSlot OBJECT-TYPE | |
1859 | SYNTAX Integer32 (0..2147483647) | |
1860 | MAX-ACCESS read-only | |
1861 | STATUS current | |
1862 | DESCRIPTION | |
1863 | "The index number of the first unassigned entry in the | |
1864 | evaluation table, or the value of zero indicating that | |
1865 | all entries are assigned. | |
1866 | ||
1867 | A management station should create new entries in the | |
1868 | evaluation table using this algorithm: first, issue a | |
1869 | management protocol retrieval operation to determine the | |
1870 | value of evalSlot; and, second, issue a management | |
1871 | protocol set operation to create an instance of the | |
1872 | evalStatus object setting its value to createAndGo(4) or | |
1873 | createAndWait(5). If this latter operation succeeds, | |
1874 | then the management station may continue modifying the | |
1875 | instances corresponding to the newly created conceptual | |
1876 | row, without fear of collision with other management | |
1877 | stations." | |
1878 | ::= { eval 1 } | |
1879 | ||
1880 | evalTable OBJECT-TYPE | |
1881 | SYNTAX SEQUENCE OF EvalEntry | |
1882 | MAX-ACCESS not-accessible | |
1883 | STATUS current | |
1884 | DESCRIPTION | |
1885 | ||
1886 | ||
1887 | McCloghrie, et al. Standards Track [Page 32] | |
1888 | \f | |
1889 | ||
1890 | ||
1891 | ||
1892 | ||
1893 | RFC 2578 SMIv2 April 1999 | |
1894 | ||
1895 | ||
1896 | "The (conceptual) evaluation table." | |
1897 | ::= { eval 2 } | |
1898 | ||
1899 | evalEntry OBJECT-TYPE | |
1900 | SYNTAX EvalEntry | |
1901 | MAX-ACCESS not-accessible | |
1902 | STATUS current | |
1903 | DESCRIPTION | |
1904 | "An entry (conceptual row) in the evaluation table." | |
1905 | INDEX { evalIndex } | |
1906 | ::= { evalTable 1 } | |
1907 | ||
1908 | EvalEntry ::= | |
1909 | SEQUENCE { | |
1910 | evalIndex Integer32, | |
1911 | evalString DisplayString, | |
1912 | evalValue Integer32, | |
1913 | evalStatus RowStatus | |
1914 | } | |
1915 | ||
1916 | evalIndex OBJECT-TYPE | |
1917 | SYNTAX Integer32 (1..2147483647) | |
1918 | MAX-ACCESS not-accessible | |
1919 | STATUS current | |
1920 | DESCRIPTION | |
1921 | "The auxiliary variable used for identifying instances of | |
1922 | the columnar objects in the evaluation table." | |
1923 | ::= { evalEntry 1 } | |
1924 | ||
1925 | evalString OBJECT-TYPE | |
1926 | SYNTAX DisplayString | |
1927 | MAX-ACCESS read-create | |
1928 | STATUS current | |
1929 | DESCRIPTION | |
1930 | "The string to evaluate." | |
1931 | ::= { evalEntry 2 } | |
1932 | ||
1933 | evalValue OBJECT-TYPE | |
1934 | SYNTAX Integer32 | |
1935 | MAX-ACCESS read-only | |
1936 | STATUS current | |
1937 | DESCRIPTION | |
1938 | "The value when evalString was last evaluated, or zero if | |
1939 | no such value is available." | |
1940 | DEFVAL { 0 } | |
1941 | ::= { evalEntry 3 } | |
1942 | ||
1943 | evalStatus OBJECT-TYPE | |
1944 | ||
1945 | ||
1946 | McCloghrie, et al. Standards Track [Page 33] | |
1947 | \f | |
1948 | ||
1949 | ||
1950 | ||
1951 | ||
1952 | RFC 2578 SMIv2 April 1999 | |
1953 | ||
1954 | ||
1955 | SYNTAX RowStatus | |
1956 | MAX-ACCESS read-create | |
1957 | STATUS current | |
1958 | DESCRIPTION | |
1959 | "The status column used for creating, modifying, and | |
1960 | deleting instances of the columnar objects in the | |
1961 | evaluation table." | |
1962 | DEFVAL { active } | |
1963 | ::= { evalEntry 4 } | |
1964 | ||
1965 | 8. Mapping of the NOTIFICATION-TYPE macro | |
1966 | ||
1967 | The NOTIFICATION-TYPE macro is used to define the information | |
1968 | contained within an unsolicited transmission of management | |
1969 | information (i.e., within either a SNMPv2-Trap-PDU or InformRequest- | |
1970 | PDU). It should be noted that the expansion of the NOTIFICATION-TYPE | |
1971 | macro is something which conceptually happens during implementation | |
1972 | and not during run-time. | |
1973 | ||
1974 | 8.1. Mapping of the OBJECTS clause | |
1975 | ||
1976 | The OBJECTS clause, which need not be present, defines an ordered | |
1977 | sequence of MIB object types. One and only one object instance for | |
1978 | each occurrence of each object type must be present, and in the | |
1979 | specified order, in every instance of the notification. If the same | |
1980 | object type occurs multiple times in a notification's ordered | |
1981 | sequence, then an object instance is present for each of them. An | |
1982 | object type specified in this clause must not have an MAX-ACCESS | |
1983 | clause of "not-accessible". The notification's DESCRIPTION clause | |
1984 | must specify the information/meaning conveyed by each occurrence of | |
1985 | each object type in the sequence. The DESCRIPTION clause must also | |
1986 | specify which object instance is present for each object type in the | |
1987 | notification. | |
1988 | ||
1989 | Note that an agent is allowed, at its own discretion, to append as | |
1990 | many additional objects as it considers useful to the end of the | |
1991 | notification (i.e., after the objects defined by the OBJECTS clause). | |
1992 | ||
1993 | 8.2. Mapping of the STATUS clause | |
1994 | ||
1995 | The STATUS clause, which must be present, indicates whether this | |
1996 | definition is current or historic. | |
1997 | ||
1998 | The value "current" means that the definition is current and valid. | |
1999 | The value "obsolete" means the definition is obsolete and should not | |
2000 | be implemented and/or can be removed if previously implemented. | |
2001 | While the value "deprecated" also indicates an obsolete definition, | |
2002 | it permits new/continued implementation in order to foster | |
2003 | ||
2004 | ||
2005 | McCloghrie, et al. Standards Track [Page 34] | |
2006 | \f | |
2007 | ||
2008 | ||
2009 | ||
2010 | ||
2011 | RFC 2578 SMIv2 April 1999 | |
2012 | ||
2013 | ||
2014 | interoperability with older/existing implementations. | |
2015 | ||
2016 | 8.3. Mapping of the DESCRIPTION clause | |
2017 | ||
2018 | The DESCRIPTION clause, which must be present, contains a textual | |
2019 | definition of the notification which provides all semantic | |
2020 | definitions necessary for implementation, and should embody any | |
2021 | information which would otherwise be communicated in any ASN.1 | |
2022 | commentary annotations associated with the notification. In | |
2023 | particular, the DESCRIPTION clause should document which instances of | |
2024 | the objects mentioned in the OBJECTS clause should be contained | |
2025 | within notifications of this type. | |
2026 | ||
2027 | 8.4. Mapping of the REFERENCE clause | |
2028 | ||
2029 | The REFERENCE clause, which need not be present, contains a textual | |
2030 | cross-reference to some other document, either another information | |
2031 | module which defines a related assignment, or some other document | |
2032 | which provides additional information relevant to this definition. | |
2033 | ||
2034 | 8.5. Mapping of the NOTIFICATION-TYPE value | |
2035 | ||
2036 | The value of an invocation of the NOTIFICATION-TYPE macro is the name | |
2037 | of the notification, which is an OBJECT IDENTIFIER, an | |
2038 | administratively assigned name. In order to achieve compatibility | |
2039 | with SNMPv1 traps, both when converting SMIv1 information modules | |
2040 | to/from this SMI, and in the procedures employed by multi-lingual | |
2041 | systems and proxy forwarding applications, the next to last sub- | |
2042 | identifier in the name of any newly-defined notification must have | |
2043 | the value zero. | |
2044 | ||
2045 | Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE | |
2046 | macro is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU, | |
2047 | respectively. | |
2048 | ||
2049 | 8.6. Usage Example | |
2050 | ||
2051 | Consider how a configuration change notification might be described: | |
2052 | ||
2053 | entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } | |
2054 | entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } | |
2055 | ||
2056 | entConfigChange NOTIFICATION-TYPE | |
2057 | STATUS current | |
2058 | DESCRIPTION | |
2059 | "An entConfigChange trap is sent when the value of | |
2060 | entLastChangeTime changes. It can be utilized by an NMS to | |
2061 | trigger logical/physical entity table maintenance polls. | |
2062 | ||
2063 | ||
2064 | McCloghrie, et al. Standards Track [Page 35] | |
2065 | \f | |
2066 | ||
2067 | ||
2068 | ||
2069 | ||
2070 | RFC 2578 SMIv2 April 1999 | |
2071 | ||
2072 | ||
2073 | ||
2074 | An agent must not generate more than one entConfigChange | |
2075 | 'trap-event' in a five second period, where a 'trap-event' | |
2076 | is the transmission of a single trap PDU to a list of | |
2077 | trap destinations. If additional configuration changes | |
2078 | occur within the five second 'throttling' period, then | |
2079 | these trap-events should be suppressed by the agent. An | |
2080 | NMS should periodically check the value of | |
2081 | entLastChangeTime to detect any missed entConfigChange | |
2082 | trap-events, e.g. due to throttling or transmission loss." | |
2083 | ::= { entityMIBTrapPrefix 1 } | |
2084 | ||
2085 | According to this invocation, the notification authoritatively | |
2086 | identified as | |
2087 | ||
2088 | { entityMIBTrapPrefix 1 } | |
2089 | ||
2090 | is used to report a particular type of configuration change. | |
2091 | ||
2092 | 9. Refined Syntax | |
2093 | ||
2094 | Some macros have clauses which allows syntax to be refined, | |
2095 | specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the | |
2096 | SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT- | |
2097 | CAPABILITIES macros [2]. However, not all refinements of syntax are | |
2098 | appropriate. In particular, the object's primitive or application | |
2099 | type must not be changed. | |
2100 | ||
2101 | Further, the following restrictions apply: | |
2102 | ||
2103 | Restrictions to Refinement of | |
2104 | object syntax range enumeration size | |
2105 | ----------------- ----- ----------- ---- | |
2106 | INTEGER (1) (2) - | |
2107 | Integer32 (1) - - | |
2108 | Unsigned32 (1) - - | |
2109 | OCTET STRING - - (3) | |
2110 | OBJECT IDENTIFIER - - - | |
2111 | BITS - (2) - | |
2112 | IpAddress - - - | |
2113 | Counter32 - - - | |
2114 | Counter64 - - - | |
2115 | Gauge32 (1) - - | |
2116 | TimeTicks - - - | |
2117 | ||
2118 | where: | |
2119 | ||
2120 | ||
2121 | ||
2122 | ||
2123 | McCloghrie, et al. Standards Track [Page 36] | |
2124 | \f | |
2125 | ||
2126 | ||
2127 | ||
2128 | ||
2129 | RFC 2578 SMIv2 April 1999 | |
2130 | ||
2131 | ||
2132 | (1) the range of permitted values may be refined by raising the lower- | |
2133 | bounds, by reducing the upper-bounds, and/or by reducing the | |
2134 | alternative value/range choices; | |
2135 | ||
2136 | (2) the enumeration of named-values may be refined by removing one or | |
2137 | more named-values (note that for BITS, a refinement may cause the | |
2138 | enumerations to no longer be contiguous); or, | |
2139 | ||
2140 | (3) the size in octets of the value may be refined by raising the | |
2141 | lower-bounds, by reducing the upper-bounds, and/or by reducing the | |
2142 | alternative size choices. | |
2143 | ||
2144 | No other types of refinements can be specified in the SYNTAX clause. | |
2145 | However, the DESCRIPTION clause is available to specify additional | |
2146 | restrictions which can not be expressed in the SYNTAX clause. | |
2147 | Further details on (and examples of) sub-typing are provided in | |
2148 | Appendix A. | |
2149 | ||
2150 | 10. Extending an Information Module | |
2151 | ||
2152 | As experience is gained with an information module, it may be | |
2153 | desirable to revise that information module. However, changes are | |
2154 | not allowed if they have any potential to cause interoperability | |
2155 | problems "over the wire" between an implementation using an original | |
2156 | specification and an implementation using an updated | |
2157 | specification(s). | |
2158 | ||
2159 | For any change, the invocation of the MODULE-IDENTITY macro must be | |
2160 | updated to include information about the revision: specifically, | |
2161 | updating the LAST-UPDATED clause, adding a pair of REVISION and | |
2162 | DESCRIPTION clauses (see section 5.5), and making any necessary | |
2163 | changes to existing clauses, including the ORGANIZATION and CONTACT- | |
2164 | INFO clauses. | |
2165 | ||
2166 | Note that any definition contained in an information module is | |
2167 | available to be IMPORT-ed by any other information module, and is | |
2168 | referenced in an IMPORTS clause via the module name. Thus, a module | |
2169 | name should not be changed. Specifically, the module name (e.g., | |
2170 | "FIZBIN-MIB" in the example of Section 5.7) should not be changed | |
2171 | when revising an information module (except to correct typographical | |
2172 | errors), and definitions should not be moved from one information | |
2173 | module to another. | |
2174 | ||
2175 | Also note that obsolete definitions must not be removed from MIB | |
2176 | modules since their descriptors may still be referenced by other | |
2177 | information modules, and the OBJECT IDENTIFIERs used to name them | |
2178 | must never be re-assigned. | |
2179 | ||
2180 | ||
2181 | ||
2182 | McCloghrie, et al. Standards Track [Page 37] | |
2183 | \f | |
2184 | ||
2185 | ||
2186 | ||
2187 | ||
2188 | RFC 2578 SMIv2 April 1999 | |
2189 | ||
2190 | ||
2191 | 10.1. Object Assignments | |
2192 | ||
2193 | If any non-editorial change is made to any clause of a object | |
2194 | assignment, then the OBJECT IDENTIFIER value associated with that | |
2195 | object assignment must also be changed, along with its associated | |
2196 | descriptor. | |
2197 | ||
2198 | 10.2. Object Definitions | |
2199 | ||
2200 | An object definition may be revised in any of the following ways: | |
2201 | ||
2202 | (1) A SYNTAX clause containing an enumerated INTEGER may have new | |
2203 | enumerations added or existing labels changed. Similarly, named | |
2204 | bits may be added or existing labels changed for the BITS | |
2205 | construct. | |
2206 | ||
2207 | (2) The value of a SYNTAX clause may be replaced by a textual | |
2208 | convention, providing the textual convention is defined to use the | |
2209 | same primitive ASN.1 type, has the same set of values, and has | |
2210 | identical semantics. | |
2211 | ||
2212 | (3) A STATUS clause value of "current" may be revised as "deprecated" | |
2213 | or "obsolete". Similarly, a STATUS clause value of "deprecated" | |
2214 | may be revised as "obsolete". When making such a change, the | |
2215 | DESCRIPTION clause should be updated to explain the rationale. | |
2216 | ||
2217 | (4) A DEFVAL clause may be added or updated. | |
2218 | ||
2219 | (5) A REFERENCE clause may be added or updated. | |
2220 | ||
2221 | (6) A UNITS clause may be added. | |
2222 | ||
2223 | (7) A conceptual row may be augmented by adding new columnar objects at | |
2224 | the end of the row, and making the corresponding update to the | |
2225 | SEQUENCE definition. | |
2226 | ||
2227 | (8) Clarifications and additional information may be included in the | |
2228 | DESCRIPTION clause. | |
2229 | ||
2230 | (9) Entirely new objects may be defined, named with previously | |
2231 | unassigned OBJECT IDENTIFIER values. | |
2232 | ||
2233 | Otherwise, if the semantics of any previously defined object are | |
2234 | changed (i.e., if a non-editorial change is made to any clause other | |
2235 | than those specifically allowed above), then the OBJECT IDENTIFIER | |
2236 | value associated with that object must also be changed. | |
2237 | ||
2238 | ||
2239 | ||
2240 | ||
2241 | McCloghrie, et al. Standards Track [Page 38] | |
2242 | \f | |
2243 | ||
2244 | ||
2245 | ||
2246 | ||
2247 | RFC 2578 SMIv2 April 1999 | |
2248 | ||
2249 | ||
2250 | Note that changing the descriptor associated with an existing object | |
2251 | is considered a semantic change, as these strings may be used in an | |
2252 | IMPORTS statement. | |
2253 | ||
2254 | 10.3. Notification Definitions | |
2255 | ||
2256 | A notification definition may be revised in any of the following | |
2257 | ways: | |
2258 | ||
2259 | (1) A REFERENCE clause may be added or updated. | |
2260 | ||
2261 | (2) A STATUS clause value of "current" may be revised as "deprecated" | |
2262 | or "obsolete". Similarly, a STATUS clause value of "deprecated" | |
2263 | may be revised as "obsolete". When making such a change, the | |
2264 | DESCRIPTION clause should be updated to explain the rationale. | |
2265 | ||
2266 | (3) A DESCRIPTION clause may be clarified. | |
2267 | ||
2268 | Otherwise, if the semantics of any previously defined notification | |
2269 | are changed (i.e., if a non-editorial change is made to any clause | |
2270 | other those specifically allowed above), then the OBJECT IDENTIFIER | |
2271 | value associated with that notification must also be changed. | |
2272 | ||
2273 | Note that changing the descriptor associated with an existing | |
2274 | notification is considered a semantic change, as these strings may be | |
2275 | used in an IMPORTS statement. | |
2276 | ||
2277 | ||
2278 | ||
2279 | ||
2280 | ||
2281 | ||
2282 | ||
2283 | ||
2284 | ||
2285 | ||
2286 | ||
2287 | ||
2288 | ||
2289 | ||
2290 | ||
2291 | ||
2292 | ||
2293 | ||
2294 | ||
2295 | ||
2296 | ||
2297 | ||
2298 | ||
2299 | ||
2300 | McCloghrie, et al. Standards Track [Page 39] | |
2301 | \f | |
2302 | ||
2303 | ||
2304 | ||
2305 | ||
2306 | RFC 2578 SMIv2 April 1999 | |
2307 | ||
2308 | ||
2309 | 11. Appendix A: Detailed Sub-typing Rules | |
2310 | ||
2311 | ||
2312 | 11.1. Syntax Rules | |
2313 | ||
2314 | The syntax rules for sub-typing are given below. Note that while | |
2315 | this syntax is based on ASN.1, it includes some extensions beyond | |
2316 | what is allowed in ASN.1, and a number of ASN.1 constructs are not | |
2317 | allowed by this syntax. | |
2318 | ||
2319 | <integerSubType> | |
2320 | ::= <empty> | |
2321 | | "(" <range> ["|" <range>]... ")" | |
2322 | ||
2323 | <octetStringSubType> | |
2324 | ::= <empty> | |
2325 | | "(" "SIZE" "(" <range> ["|" <range>]... ")" ")" | |
2326 | ||
2327 | <range> | |
2328 | ::= <value> | |
2329 | | <value> ".." <value> | |
2330 | ||
2331 | <value> | |
2332 | ::= "-" <number> | |
2333 | | <number> | |
2334 | | <hexString> | |
2335 | | <binString> | |
2336 | ||
2337 | where: | |
2338 | <empty> is the empty string | |
2339 | <number> is a non-negative integer | |
2340 | <hexString> is a hexadecimal string (e.g., '0F0F'H) | |
2341 | <binString> is a binary string (e.g, '1010'B) | |
2342 | ||
2343 | <range> is further restricted as follows: | |
2344 | - any <value> used in a SIZE clause must be non-negative. | |
2345 | - when a pair of values is specified, the first value | |
2346 | must be less than the second value. | |
2347 | - when multiple ranges are specified, the ranges may | |
2348 | not overlap but may touch. For example, (1..4 | 4..9) | |
2349 | is invalid, and (1..4 | 5..9) is valid. | |
2350 | - the ranges must be a subset of the maximum range of the | |
2351 | base type. | |
2352 | ||
2353 | ||
2354 | ||
2355 | ||
2356 | ||
2357 | ||
2358 | ||
2359 | McCloghrie, et al. Standards Track [Page 40] | |
2360 | \f | |
2361 | ||
2362 | ||
2363 | ||
2364 | ||
2365 | RFC 2578 SMIv2 April 1999 | |
2366 | ||
2367 | ||
2368 | 11.2. Examples | |
2369 | ||
2370 | Some examples of legal sub-typing: | |
2371 | ||
2372 | Integer32 (-20..100) | |
2373 | Integer32 (0..100 | 300..500) | |
2374 | Integer32 (300..500 | 0..100) | |
2375 | Integer32 (0 | 2 | 4 | 6 | 8 | 10) | |
2376 | OCTET STRING (SIZE(0..100)) | |
2377 | OCTET STRING (SIZE(0..100 | 300..500)) | |
2378 | OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10)) | |
2379 | SYNTAX TimeInterval (0..100) | |
2380 | SYNTAX DisplayString (SIZE(0..32)) | |
2381 | ||
2382 | (Note the last two examples above are not valid in a TEXTUAL | |
2383 | CONVENTION, see [3].) | |
2384 | ||
2385 | Some examples of illegal sub-typing: | |
2386 | ||
2387 | Integer32 (150..100) -- first greater than second | |
2388 | Integer32 (0..100 | 50..500) -- ranges overlap | |
2389 | Integer32 (0 | 2 | 0 ) -- value duplicated | |
2390 | Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed | |
2391 | Integer32 (SIZE (0..34)) -- must not use SIZE | |
2392 | OCTET STRING (0..100) -- must use SIZE | |
2393 | OCTET STRING (SIZE(-10..100)) -- negative SIZE | |
2394 | ||
2395 | 12. Security Considerations | |
2396 | ||
2397 | This document defines a language with which to write and read | |
2398 | descriptions of management information. The language itself has no | |
2399 | security impact on the Internet. | |
2400 | ||
2401 | ||
2402 | ||
2403 | 13. Editors' Addresses | |
2404 | ||
2405 | Keith McCloghrie | |
2406 | Cisco Systems, Inc. | |
2407 | 170 West Tasman Drive | |
2408 | San Jose, CA 95134-1706 | |
2409 | USA | |
2410 | Phone: +1 408 526 5260 | |
2411 | EMail: kzm@cisco.com | |
2412 | ||
2413 | ||
2414 | ||
2415 | ||
2416 | ||
2417 | ||
2418 | McCloghrie, et al. Standards Track [Page 41] | |
2419 | \f | |
2420 | ||
2421 | ||
2422 | ||
2423 | ||
2424 | RFC 2578 SMIv2 April 1999 | |
2425 | ||
2426 | ||
2427 | David Perkins | |
2428 | SNMPinfo | |
2429 | 3763 Benton Street | |
2430 | Santa Clara, CA 95051 | |
2431 | USA | |
2432 | Phone: +1 408 221-8702 | |
2433 | EMail: dperkins@snmpinfo.com | |
2434 | ||
2435 | Juergen Schoenwaelder | |
2436 | TU Braunschweig | |
2437 | Bueltenweg 74/75 | |
2438 | 38106 Braunschweig | |
2439 | Germany | |
2440 | Phone: +49 531 391-3283 | |
2441 | EMail: schoenw@ibr.cs.tu-bs.de | |
2442 | ||
2443 | ||
2444 | 14. References | |
2445 | ||
2446 | [1] Information processing systems - Open Systems Interconnection - | |
2447 | Specification of Abstract Syntax Notation One (ASN.1), | |
2448 | International Organization for Standardization. International | |
2449 | Standard 8824, (December, 1987). | |
2450 | ||
2451 | [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. | |
2452 | and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, | |
2453 | RFC 2580, April 1999. | |
2454 | ||
2455 | [3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. | |
2456 | and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, | |
2457 | RFC 2579, April 1999. | |
2458 | ||
2459 | [4] Information processing systems - Open Systems Interconnection - | |
2460 | Specification of Basic Encoding Rules for Abstract Syntax Notation | |
2461 | One (ASN.1), International Organization for Standardization. | |
2462 | International Standard 8825, (December, 1987). | |
2463 | ||
2464 | [5] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and | |
2465 | S. Waldbusser, "Management Information Base for Version 2 of the | |
2466 | Simple Network Management Protocol (SNMPv2)", RFC 1907, January | |
2467 | 1996. | |
2468 | ||
2469 | [6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and | |
2470 | S. Waldbusser, "Protocol Operations for Version 2 of the Simple | |
2471 | Network Management Protocol (SNMPv2)", RFC 1905, January 1996. | |
2472 | ||
2473 | ||
2474 | ||
2475 | ||
2476 | ||
2477 | McCloghrie, et al. Standards Track [Page 42] | |
2478 | \f | |
2479 | ||
2480 | ||
2481 | ||
2482 | ||
2483 | RFC 2578 SMIv2 April 1999 | |
2484 | ||
2485 | ||
2486 | 15. Full Copyright Statement | |
2487 | ||
2488 | Copyright (C) The Internet Society (1999). All Rights Reserved. | |
2489 | ||
2490 | This document and translations of it may be copied and furnished to | |
2491 | others, and derivative works that comment on or otherwise explain it | |
2492 | or assist in its implementation may be prepared, copied, published | |
2493 | and distributed, in whole or in part, without restriction of any | |
2494 | kind, provided that the above copyright notice and this paragraph are | |
2495 | included on all such copies and derivative works. However, this | |
2496 | document itself may not be modified in any way, such as by removing | |
2497 | the copyright notice or references to the Internet Society or other | |
2498 | Internet organizations, except as needed for the purpose of | |
2499 | developing Internet standards in which case the procedures for | |
2500 | copyrights defined in the Internet Standards process must be | |
2501 | followed, or as required to translate it into languages other than | |
2502 | English. | |
2503 | ||
2504 | The limited permissions granted above are perpetual and will not be | |
2505 | revoked by the Internet Society or its successors or assigns. | |
2506 | ||
2507 | This document and the information contained herein is provided on an | |
2508 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
2509 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
2510 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
2511 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
2512 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." | |
2513 | ||
2514 | ||
2515 | ||
2516 | ||
2517 | ||
2518 | ||
2519 | ||
2520 | ||
2521 | ||
2522 | ||
2523 | ||
2524 | ||
2525 | ||
2526 | ||
2527 | ||
2528 | ||
2529 | ||
2530 | ||
2531 | ||
2532 | ||
2533 | ||
2534 | ||
2535 | ||
2536 | McCloghrie, et al. Standards Track [Page 43] | |
2537 | ||
2538 | ||
2539 | ||
2540 | ||
2541 |