net-snmp 1.2.4 → 1.2.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (27) hide show
  1. package/README.md +1296 -1296
  2. package/example/cisco-device-inventory.js +140 -140
  3. package/example/snmp-get-bulk.js +53 -53
  4. package/example/snmp-get-next.js +30 -30
  5. package/example/snmp-get.js +30 -30
  6. package/example/snmp-inform.js +32 -32
  7. package/example/snmp-set.js +31 -31
  8. package/example/snmp-subtree.js +37 -37
  9. package/example/snmp-table-columns.js +61 -61
  10. package/example/snmp-table.js +56 -56
  11. package/example/snmp-tail.js +34 -34
  12. package/example/snmp-trap.js +32 -32
  13. package/example/snmp-walk.js +37 -37
  14. package/example/specify-source-address-and-port.js +41 -41
  15. package/example/specify-sysuptime-to-inform.js +34 -34
  16. package/example/specify-sysuptime-to-trap.js +35 -35
  17. package/index.js +1464 -1464
  18. package/package.json +43 -39
  19. package/ref/rfc/v1/rfc1065.txt +1178 -1178
  20. package/ref/rfc/v1/rfc1066.txt +5042 -5042
  21. package/ref/rfc/v1/rfc1067.txt +1850 -1850
  22. package/ref/rfc/v1/rfc1098.txt +1906 -1906
  23. package/ref/rfc/v1/rfc1155.txt +1234 -1234
  24. package/ref/rfc/v2c/rfc1908.txt +563 -563
  25. package/ref/rfc/v2c/rfc2578.txt +2541 -2541
  26. package/ref/rfc/v2c/rfc3416.txt +1739 -1739
  27. package/test/varbinds.js +42 -42
package/ref/rfc/v2c/rfc2578.txt CHANGED
@@ -1,2541 +1,2541 @@
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+
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
+