3 Network Working Group F. Strauss
4 Internet-Draft TU Braunschweig
5 Expires: August 15, 2000 February 15, 2000
8 SMIng - A new Structure of Management Information
9 draft-irtf-nmrg-sming-02
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026.
16 Internet-Drafts are working documents of the Internet Engineering
17 Task Force (IETF), its areas, and its working groups. Note that
18 other groups may also distribute working documents as
21 Internet-Drafts are draft documents valid for a maximum of six
22 months and may be updated, replaced, or obsoleted by other documents
23 at any time. It is inappropriate to use Internet-Drafts as reference
24 material or to cite them other than as "work in progress."
26 To view the entire list of Internet-Draft Shadow Directories, see
27 http://www.ietf.org/shadow.html.
29 This Internet-Draft will expire on August 15, 2000.
33 This memo presents a language for management information
34 specifications. It eliminates known problems present in the current
35 SMIv2 as specified in [2], [3], and [4]. Language extensibility
36 features and a more efficient and programmer-friendly notation are
37 introduced. Conversions from SMIv2 to SMIng and vice versa are also
38 considered by this document.
42 Copyright (C) The Internet Society (2000). All Rights Reserved.
55 Strauss Expires August 15, 2000 [Page 1]
57 Internet-Draft SMIng February 2000
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6
63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 6
64 1.2 Relation to SNMP . . . . . . . . . . . . . . . . . . . . 6
65 2. The Information Model . . . . . . . . . . . . . . . . . 8
66 2.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . 9
67 2.2 Object Identifier Hierarchy . . . . . . . . . . . . . . 10
68 2.3 Kinds of Nodes . . . . . . . . . . . . . . . . . . . . . 11
69 2.4 Scalar and Columnar Objects' Instances . . . . . . . . . 12
70 3. Base Types and Derived Types . . . . . . . . . . . . . . 15
71 3.1 OctetString . . . . . . . . . . . . . . . . . . . . . . 15
72 3.2 ObjectIdentifier . . . . . . . . . . . . . . . . . . . . 16
73 3.3 Integer32 . . . . . . . . . . . . . . . . . . . . . . . 17
74 3.4 Integer64 . . . . . . . . . . . . . . . . . . . . . . . 18
75 3.5 Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . 18
76 3.6 Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . 19
77 3.7 Float32 . . . . . . . . . . . . . . . . . . . . . . . . 20
78 3.8 Float64 . . . . . . . . . . . . . . . . . . . . . . . . 21
79 3.9 Float128 . . . . . . . . . . . . . . . . . . . . . . . . 22
80 3.10 Enumeration . . . . . . . . . . . . . . . . . . . . . . 23
81 3.11 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 23
82 3.12 Display Formats . . . . . . . . . . . . . . . . . . . . 24
83 4. The SMIng File Structure . . . . . . . . . . . . . . . . 27
84 4.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . 27
85 4.2 Statements and Arguments . . . . . . . . . . . . . . . . 27
86 5. The module Statement . . . . . . . . . . . . . . . . . . 28
87 5.1 The module's import Statement . . . . . . . . . . . . . 28
88 5.2 The module's organization Statement . . . . . . . . . . 29
89 5.3 The module's contact Statement . . . . . . . . . . . . . 29
90 5.4 The module's description Statement . . . . . . . . . . . 29
91 5.5 The module's reference Statement . . . . . . . . . . . . 29
92 5.6 The module's revision Statement . . . . . . . . . . . . 29
93 5.6.1 The revision's date Statement . . . . . . . . . . . . . 30
94 5.6.2 The revision's description Statement . . . . . . . . . . 30
95 5.7 The module's identity Statement . . . . . . . . . . . . 30
96 5.8 Usage Example . . . . . . . . . . . . . . . . . . . . . 30
97 6. The extension Statement . . . . . . . . . . . . . . . . 32
98 6.1 The extension's status Statement . . . . . . . . . . . . 32
99 6.2 The extension's description Statement . . . . . . . . . 32
100 6.3 The extension's reference Statement . . . . . . . . . . 32
101 6.4 The extension's abnf Statement . . . . . . . . . . . . . 33
102 7. The typedef Statement . . . . . . . . . . . . . . . . . 34
103 7.1 The typedef's type Statement . . . . . . . . . . . . . . 34
104 7.2 The typedef's default Statement . . . . . . . . . . . . 34
105 7.3 The typedef's format Statement . . . . . . . . . . . . . 34
106 7.4 The typedef's units Statement . . . . . . . . . . . . . 35
107 7.5 The typedef's status Statement . . . . . . . . . . . . . 35
108 7.6 The typedef's description Statement . . . . . . . . . . 36
111 Strauss Expires August 15, 2000 [Page 2]
113 Internet-Draft SMIng February 2000
116 7.7 The typedef's reference Statement . . . . . . . . . . . 36
117 7.8 Usage Examples . . . . . . . . . . . . . . . . . . . . . 36
118 8. The node Statement . . . . . . . . . . . . . . . . . . . 38
119 8.1 The node's oid Statement . . . . . . . . . . . . . . . . 38
120 8.2 The node's status Statement . . . . . . . . . . . . . . 38
121 8.3 The node's description Statement . . . . . . . . . . . . 38
122 8.4 The node's reference Statement . . . . . . . . . . . . . 38
123 8.5 Usage Examples . . . . . . . . . . . . . . . . . . . . . 39
124 9. The scalar Statement . . . . . . . . . . . . . . . . . . 40
125 9.1 The scalar's oid Statement . . . . . . . . . . . . . . . 40
126 9.2 The scalar's type Statement . . . . . . . . . . . . . . 40
127 9.3 The scalar's access Statement . . . . . . . . . . . . . 40
128 9.4 The scalar's default Statement . . . . . . . . . . . . . 40
129 9.5 The scalar's format Statement . . . . . . . . . . . . . 41
130 9.6 The scalar's units Statement . . . . . . . . . . . . . . 41
131 9.7 The scalar's status Statement . . . . . . . . . . . . . 41
132 9.8 The scalar's description Statement . . . . . . . . . . . 42
133 9.9 The scalar's reference Statement . . . . . . . . . . . . 42
134 9.10 Usage Examples . . . . . . . . . . . . . . . . . . . . . 42
135 10. The table Statement . . . . . . . . . . . . . . . . . . 43
136 10.1 The table's oid Statement . . . . . . . . . . . . . . . 43
137 10.2 The table's status Statement . . . . . . . . . . . . . . 43
138 10.3 The table's description Statement . . . . . . . . . . . 43
139 10.4 The table's reference Statement . . . . . . . . . . . . 43
140 10.5 The table's row Statement . . . . . . . . . . . . . . . 44
141 10.5.1 The row's oid Statement . . . . . . . . . . . . . . . . 44
142 10.5.2 Table Indexing Statements . . . . . . . . . . . . . . . 44
143 10.5.2.1 The row's index Statement for Table Indexing . . . . . . 44
144 10.5.2.2 The row's augments Statement for Table Indexing . . . . 44
145 10.5.2.3 The row's sparse Statement for Table Indexing . . . . . 45
146 10.5.2.4 The row's reorders Statement for Table Indexing . . . . 45
147 10.5.2.5 The row's expands Statement for Table Indexing . . . . . 46
148 10.5.3 The row's create Statement . . . . . . . . . . . . . . . 46
149 10.5.4 The row's status Statement . . . . . . . . . . . . . . . 46
150 10.5.5 The row's description Statement . . . . . . . . . . . . 46
151 10.5.6 The row's reference Statement . . . . . . . . . . . . . 47
152 10.6 The table row's column Statement . . . . . . . . . . . . 47
153 10.6.1 The column's oid Statement . . . . . . . . . . . . . . . 47
154 10.6.2 The column's type Statement . . . . . . . . . . . . . . 47
155 10.6.3 The column's access Statement . . . . . . . . . . . . . 47
156 10.6.4 The column's default Statement . . . . . . . . . . . . . 48
157 10.6.5 The column's format Statement . . . . . . . . . . . . . 48
158 10.6.6 The column's units Statement . . . . . . . . . . . . . . 48
159 10.6.7 The column's status Statement . . . . . . . . . . . . . 49
160 10.6.8 The column's description Statement . . . . . . . . . . . 49
161 10.6.9 The column's reference Statement . . . . . . . . . . . . 49
162 10.7 Usage Example . . . . . . . . . . . . . . . . . . . . . 49
163 11. The notification Statement . . . . . . . . . . . . . . . 52
164 11.1 The notification's oid Statement . . . . . . . . . . . . 52
167 Strauss Expires August 15, 2000 [Page 3]
169 Internet-Draft SMIng February 2000
172 11.2 The notification's objects Statement . . . . . . . . . . 52
173 11.3 The notification's status Statement . . . . . . . . . . 52
174 11.4 The notification's description Statement . . . . . . . . 53
175 11.5 The notification's reference Statement . . . . . . . . . 53
176 11.6 Usage Example . . . . . . . . . . . . . . . . . . . . . 53
177 12. The group Statement . . . . . . . . . . . . . . . . . . 54
178 12.1 The group's oid Statement . . . . . . . . . . . . . . . 54
179 12.2 The group's members Statement . . . . . . . . . . . . . 54
180 12.3 The group's status Statement . . . . . . . . . . . . . . 54
181 12.4 The group's description Statement . . . . . . . . . . . 54
182 12.5 The group's reference Statement . . . . . . . . . . . . 55
183 12.6 Usage Example . . . . . . . . . . . . . . . . . . . . . 55
184 13. The compliance Statement . . . . . . . . . . . . . . . . 56
185 13.1 The compliance's oid Statement . . . . . . . . . . . . . 56
186 13.2 The compliance's status Statement . . . . . . . . . . . 56
187 13.3 The compliance's description Statement . . . . . . . . . 56
188 13.4 The compliance's reference Statement . . . . . . . . . . 56
189 13.5 The compliance's mandatory Statement . . . . . . . . . . 56
190 13.6 The compliance's optional Statement . . . . . . . . . . 57
191 13.6.1 The optional's description Statement . . . . . . . . . . 57
192 13.7 The compliance's refine Statement . . . . . . . . . . . 57
193 13.7.1 The refine's type Statement . . . . . . . . . . . . . . 58
194 13.7.2 The refine's writetype Statement . . . . . . . . . . . . 58
195 13.7.3 The refine's access Statement . . . . . . . . . . . . . 58
196 13.7.4 The refine's description Statement . . . . . . . . . . . 58
197 13.8 Usage Example . . . . . . . . . . . . . . . . . . . . . 58
198 14. SMIng Core Modules . . . . . . . . . . . . . . . . . . . 60
199 14.1 IRTF-NMRG-SMING . . . . . . . . . . . . . . . . . . . . 60
200 14.2 IRTF-NMRG-SMING-TYPES . . . . . . . . . . . . . . . . . 61
201 14.3 IRTF-NMRG-SMING-EXTENSIONS . . . . . . . . . . . . . . . 80
202 15. Extending a Module . . . . . . . . . . . . . . . . . . . 83
203 16. SMIng Language Extensibility . . . . . . . . . . . . . . 85
204 17. Module Conversions . . . . . . . . . . . . . . . . . . . 87
205 17.1 Converting SMIv2 to SMIng . . . . . . . . . . . . . . . 87
206 17.2 Converting SMIng to SMIv2 . . . . . . . . . . . . . . . 87
207 17.3 SMIv1 . . . . . . . . . . . . . . . . . . . . . . . . . 87
208 18. Security Considerations . . . . . . . . . . . . . . . . 88
209 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . 89
210 References . . . . . . . . . . . . . . . . . . . . . . . 90
211 Author's Address . . . . . . . . . . . . . . . . . . . . 91
212 A. The SMIng ABNF grammar . . . . . . . . . . . . . . . . . 92
213 B. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 104
223 Strauss Expires August 15, 2000 [Page 4]
225 Internet-Draft SMIng February 2000
230 Management information is viewed as a collection of managed objects,
231 residing in a virtual information store, termed the Management
232 Information Base (MIB). Collections of related objects are defined
233 in MIB modules. These modules are written conforming to a
234 specification language, the Structure of Management Information
235 (SMI). There are different versions of the SMI. SMIv1 [5], [6], [7]
236 and SMIv2 [2], [3], [4] are based on adapted subsets of OSI's
237 Abstract Syntax Notation One, ASN.1 [9]. It is the purpose of this
238 document to define a successor of SMIv1 and SMIv2, the SMIng, in a
239 self-contained way independent from other standardization bodies'
242 Section 2 gives an overview of some basic concepts of the
243 information model while the subsequent sections present the concepts
244 of SMIng: the base types, the SMIng file structure, and all SMIng
245 statements in detail. Section 14 contains three core modules that
246 are part of the SMIng specification. Section 15 lists rules to
247 follow when changes are applied to a module. One flexible feature of
248 SMIng is its extensibility which is described in Section 16.
249 Finally, Section 17 discusses conversions of SMIv2 modules to SMIng
250 and vice versa. Appendix A contains the grammar of SMIng in ABNF
255 Many terms in SMIv1 and SMIv2 are derived from ASN.1. In some cases,
256 SMIv1/v2 uses different terms for equal or similar language items
257 without precise definitions. Appendix B presents a glossary of terms
258 used throughout this document and in related SMIng documents. Also
259 refer to the glossary and Appendix A to get detailed information on
260 the syntax of single language items where not explained in place.
262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
264 document are to be interpreted as described in [1].
268 Although SMIng is primarily intended to be applied to the SNMP
269 management framework [10], SMIng is designed to have as few
270 relations to a specific management protocol as possible. However,
271 there are some implications of SNMP on SMIv2 that have to be
274 o In SNMP the last item on a list of objects used to identify a
275 table row can be encoded without an explicit length encoding.
276 This has to be expressed by the SMIng `implied' keyword. See
279 Strauss Expires August 15, 2000 [Page 5]
281 Internet-Draft SMIng February 2000
284 Section 10.5 for details.
286 o SNMP allows to distinguish several related types "on the wire"
287 while SMIng has a minimal but complete set of base types. To
288 keep SMIng compatible with the SNMP framework, additional types
289 derived from SMIng base types are defined in the standard SMIng
290 module IRTF-NMRG-SMING-TYPES (Section 14.2).
292 o The encoding of values of type `Bits' in SNMP is dependent on
293 their named number values. It is RECOMMENDED that they start at 0
294 and be numbered contiguously to allow a compact encoding for use
297 o SNMP implies some restrictions on indexing columnar objects:
298 Those columns that are used for indexing have to be defined as
299 non-accessible auxiliary objects, with two exceptions. Hence, the
300 access level `noaccess' has to be retained in SMIng.
302 o In order to achieve compatibility with SNMPv1 traps, the next to
303 last sub-identifier of notification object identifiers SHOULD
335 Strauss Expires August 15, 2000 [Page 6]
337 Internet-Draft SMIng February 2000
340 2. The Information Model
342 Internet management is based on the model of "managed objects". A
343 managed object represents a class of any real or synthesized
344 variable of systems that are to be managed. Those objects are
345 organized hierarchically in an "object identifier tree", where only
346 leaf nodes may represent objects.
348 Nodes may also identify tables, row definitions of tables,
349 notifications, groups of objects and/or notifications, compliance
350 statements, modules or other information. Each node is identified
351 by an unique "object identifier" value which is an ordered list of
352 non-negative numbers, named "sub-identifiers", where the left-most
353 sub-identifier refers to the node next to the root of the tree and
354 the right-most sub-identifier refers to the node that is identified
355 by the complete object identifier.
357 The SMI in general, and SMIng in particular, is the information
358 model used to define and organize the structure of managed objects
359 and related information. Thus, SMIng describes a language designed
360 to specify management information in a way readable to computer
361 programs, named MIB compilers, as well as to human readers.
363 Related management information is defined in MIB modules. A module
364 may refer to definitions from other modules by importing identifiers
365 from those modules. Each module may serve one or multiple purposes:
367 o the definition of inter-related managed objects, notifications
370 o the definition of (restricted) types for use in the local module
373 o the definition of compliance statements for groups of objects and
374 notifications to guide agent implementors in what they have to
375 serve or implementors of management applications in what they can
378 o the definition of SMIng extensions to allow the local module or
379 other modules to specify information beyond the scope of the base
380 SMIng in a machine readable notation,
382 o the definition of information beyond the scope of the base SMIng
383 statements, based on locally defined or imported SMIng
384 extensions, like capability statements for agent implementations.
386 This classification scheme does not imply a rigid taxonomy. For
387 example, a "standard" module will normally include definitions of
388 managed objects and a compliance statement. Similarly, an
391 Strauss Expires August 15, 2000 [Page 7]
393 Internet-Draft SMIng February 2000
396 "enterprise-specific" module might include definitions of managed
397 objects and a capability statement based on an extension. Of course,
398 a "standard" module may not contain capability statements.
400 Each module is identified by an upper-case identifier. The names of
401 all standard modules must be unique (but different versions of the
402 same module should have the same name). Developers of enterprise
403 modules are encouraged to choose names for their modules that will
404 have a low probability of colliding with standard or other
405 enterprise modules, e.g. by using the enterprise or organization
410 Identifiers are used to identify different kinds of SMIng items by
411 name. These names are valid in a namespace which is dependent on the
412 SMIng item. Those items are
414 o modules (Section 5), whose namespace is the global range of all
417 o defined data types (Section 7), whose namespace is the local
418 module where the type is defined,
420 o elements of enumeration and bitset types (Section 3.10, Section
421 3.11), whose namespace is the related type definition construct
422 and all constructs using that type,
424 o object identifier tree nodes of different kinds (Section 5, and
425 Section 8 through Section 13), whose namespace is the local
426 module where the node is defined, and
428 o SMIng extension statements (Section 6), whose namespace is the
429 local module where the extension is defined.
431 Each identifier starts with an upper-case or lower-case character,
432 dependent on the kind of SMIng item, followed by zero or more
433 letters, digits, and hyphens.
435 For all identifiers of a single kind of item defined in a namespace,
436 the identifier MUST be unique and SHOULD NOT only differ in case.
437 Identifiers MUST NOT exceed 64 characters in length. Furthermore,
438 the set of all identifiers defined in all modules of a single
439 standardization body or organization SHOULD be unique and mnemonic.
440 This promotes a common language for humans to use when discussing a
443 To reference an item that is defined in the local module, its
444 definition MUST sequentially precede the reference. Thus, there MUST
447 Strauss Expires August 15, 2000 [Page 8]
449 Internet-Draft SMIng February 2000
452 NOT be any forward references, except in two cases:
454 1. The optional module's `identity' statement, which is located
455 near the head of a module, specifies an identity node, which is
456 defined in a subsequent section of the local module.
458 2. The specification of table indexing objects in a table row may
459 include objects that cannot be defined without the definition of
460 the current table row. Hence table indexing statements are
461 allowed to include forward references.
463 To reference an item, that is defined in an external module it MUST
464 be imported into the local module's namespace (Section 5.1).
465 Identifiers that are neither defined nor imported MUST NOT be
466 visible in the local module. On the other hand, all items defined in
467 a module are implicitly exported.
469 Note when identifiers from external modules are referenced, there is
470 the possibility of name collisions. As such, if different items with
471 the same identifier are imported or if imported identifiers collide
472 with identifiers of locally defined items, then this ambiguity is
473 resolved by prefixing those identifiers with the names of their
474 modules and the namespace operator `::', i.e. `Module::item'. Of
475 course, this notation can be used to refer to identifiers even when
476 there is no name collision.
478 Note that SMIng language keywords MUST NOT be imported. The main set
479 of keywords are SMIng statements and base types. See the
480 `...Keyword' rules of the SMIng ABNF grammar in Appendix A for a
481 list of those keywords.
483 Finally, by convention, if the identifier refers to an object with a
484 counter type (Counter32 or Counter64, derived from Unsigned32 and
485 Unsigned64) then the identifier used for the object SHOULD denote
488 2.2 Object Identifier Hierarchy
490 The layers of the object identifier tree near the root are well
491 defined and organized by standardization bodies. The first level
492 next to the root has three nodes:
500 Note that the renaming of the Commite Consultatif International de
503 Strauss Expires August 15, 2000 [Page 9]
505 Internet-Draft SMIng February 2000
508 Telegraphique et Telephonique (CCITT) to International
509 Telecommunications Union (ITU) had no consequence on the names used
510 in the object identifier tree.
512 The root of the subtree administered by the Internet Assigned
513 Numbers Authority (IANA) for the Internet is `1.3.6.1' which is
514 assigned with the identifier `internet'. That is, the Internet
515 subtree of object identifiers starts with the prefix `1.3.6.1.'.
517 Several branches underneath this subtree are used for network
520 The `mgmt' (internet.2) subtree is used to identify "standard"
523 The `experimental' (internet.3) subtree is used to identify
524 information being designed by working groups of the IETF or IRTF. If
525 a module produced by a working group becomes a "standard" module
526 then at the very beginning of its entry onto the Internet standards
527 track, the information is moved under the mgmt subtree.
529 The `private' (internet.4) subtree is used to identify information
530 defined unilaterally. The `enterprises' (private.1) subtree beneath
531 private is used, among other things, to permit providers of
532 networking subsystems to register models of their products.
534 These and some other nodes are defined in the SMIng standard module
535 IRTF-NMRG-SMING (Section 14.1).
539 Each node in the object identifier tree may be of a single kind
540 which may represent management information or not:
542 o simple nodes, that do not represent management information, but
543 may be used for grouping nodes in a subtree,
545 o nodes representing the identity of a module to allow references
546 to a module in other objects of type `ObjectIdentifier',
548 o scalar objects, which have zero or one object instance and no
549 child nodes. See Section 2.4 for scalar objects' instances,
551 o tables, which represent the root node of a collection of
552 information structured in table rows. A table node SHOULD have no
553 more child nodes than the single row node of this table,
555 o rows, which belong to a table (that is, the table's full object
556 identifier is a prefix of the row's object identifier) and
559 Strauss Expires August 15, 2000 [Page 10]
561 Internet-Draft SMIng February 2000
564 represent a sequence of one or more columnar objects. Those
565 columnar objects MUST be the only child nodes of a table row. A
566 row's object identifier MUST be constructed by appending a `1'
567 sub-identifier to the table's object identifier,
569 o columnar objects, which belong to a row (that is, the row's full
570 object identifier is a prefix of the columnar objects' object
571 identifier) and have zero or more object instances and no child
572 nodes. Each columnar object's object identifier MUST be
573 constructed by appending a single sub-identifier to the row's
574 object identifier. See Section 2.4 for columnar objects'
577 o notifications, which represent information that is sent by agents
578 within unsolicited transmissions. A notification's object
579 identifier SHOULD not have any child node,
581 o groups of objects and notifications, which may be used for
582 compliance statements or other purposes,
584 o compliance statements which define requirements for MIB module
587 o other nodes, that may be used to identify arbitrary information.
589 2.4 Scalar and Columnar Objects' Instances
591 Instances of managed objects are identified by appending an
592 instance-identifier to the object's object identifier. Scalar
593 objects and columnar objects use different ways to construct the
596 Scalar objects have zero or one object instance. If it exists, it is
597 identified by appending a single `0' sub-identifier to the object
598 identifier of the scalar object.
600 Within tables, different instances of the same columnar object are
601 identified by appending a sequence of one or more sub-identifiers to
602 the object identifier of the columnar object which consists of the
603 values of object instances that unambiguously distinguish a table
604 row. These indexing objects can be columnar objects of the same
605 and/or another table, but MUST NOT be scalar objects. Multiple
606 applications of the same object in a single table indexing
607 specification are strongly discouraged.
609 The base types (Section 3) of the indexing objects indicate how to
610 form the instance-identifier:
612 o integer-valued or enumeration-valued: a single sub-identifier
615 Strauss Expires August 15, 2000 [Page 11]
617 Internet-Draft SMIng February 2000
620 taking the integer value (this works only for non-negative
621 integers and integers of a size of up to 32 bits),
623 o string-valued, fixed-length strings (or variable-length with
624 compact encoding): `n' sub-identifiers, where `n' is the length
625 of the string (each octet of the string is encoded in a separate
628 o string-valued, variable-length strings or bits-valued: `n+1'
629 sub-identifiers, where `n' is the length of the string or bits
630 encoding (the first sub-identifier is `n' itself, following this,
631 each octet of the string or bits is encoded in a separate
634 o object identifier-valued (with compact encoding): `n'
635 sub-identifiers, where `n' is the number of sub-identifiers in
636 the value (each sub-identifier of the value is copied into a
637 separate sub-identifier),
639 o object identifier-valued: `n+1' sub-identifiers, where `n' is the
640 number of sub-identifiers in the value (the first sub-identifier
641 is `n' itself, following this, each sub-identifier in the value
644 Note that compact encoding can only be applied to an object having a
645 variable-length syntax (e.g., variable-length strings, bits objects
646 or object identifier-valued objects). Further, compact encoding can
647 only be associated with the last object in a list of indexing
648 objects. Finally, compact encoding MUST NOT be used on a
649 variable-length string object if that string might have a value of
652 Instances identified by use of integer-valued or enumeration-valued
653 objects are RECOMMENDED to be numbered starting from one (i.e., not
654 from zero). Integer objects that allow negative values, Unsigned64
655 objects, Integer64 objects and floating point objects MUST NOT be
656 used for table indexing.
658 Objects which are both specified for indexing in a row and also
659 columnar objects of the same row are termed auxiliary objects.
660 Auxiliary objects SHOULD be non-accessible, except in the following
663 o within a MIB module originally written to conform to SMIv1, or
665 o a row must contain at least one columnar object which is not an
666 auxiliary object. In the event that all of a row's columnar
667 objects are also specified to be indexing objects then one of
668 them MUST be accessible. (Note that this situation does not arise
671 Strauss Expires August 15, 2000 [Page 12]
673 Internet-Draft SMIng February 2000
676 for a row allowing create access, since such a row will have a
677 status column which will not be an auxiliary object.)
727 Strauss Expires August 15, 2000 [Page 13]
729 Internet-Draft SMIng February 2000
732 3. Base Types and Derived Types
734 SMIng has a minimal but complete set of base types, similar to those
735 of many programming languages, but with some differences due to
736 special requirements from the management information model described
739 Additional types may be defined, derived from those base types and
740 even from other derived types. Derived types may use subtyping to
741 formally restrict the possible values. A set of derived types
742 commonly used in the SNMP framework is defined in the SMIng standard
743 module IRTF-NMRG-SMING-TYPES (Section 14.2).
745 Note that types can also be restricted "inline" in object
746 definitions (Section 9, Section 10.6) or in refinements of
747 compliance statements (Section 13) without referring an explicitly
750 The different base types and its derived types allow different kinds
751 of subtyping, namely size restrictions and range restrictions. See
752 the following sections on base types (Section 3.1 through Section
757 The OctetString base type represents arbitrary binary or textual
758 data. Although SMIng has a theoretical size limitation of 2^32-1
759 (4294967295) octets for this base type, MIB designers should realize
760 that there may be implementation and interoperability limitations
761 for sizes in excess of 255 octets.
763 Values of octet strings may be denoted as textual data enclosed in
764 double quotes or as arbitrary binary data denoted as a `0x'-prefixed
765 hexadecimal value of arbitrary but even length, where each pair of
766 hexadecimal digits represents a single octet. Letters in hexadecimal
767 values MAY be upper-case but lower-case characters are RECOMMENDED.
768 Textual data may contain any number (possibly zero) of any 7-bit
769 displayable ASCII characters except double quote `"', including tab
770 characters, spaces and line terminator characters (nl or cr & nl).
771 Textual data may span multiple lines, where each subsequent line
772 prefix containing only white space up to the column where the first
773 line's data starts SHOULD be skipped by parsers for a better text
776 When defining a type derived (directly or indirectly) from the
777 OctetString base type, the size in octets may be restricted by
778 appending a list of size ranges or explicit size values, separated
779 by pipe `|' characters and the whole list enclosed in parenthesis. A
780 size range consists of a lower bound, two consecutive dots `..' and
783 Strauss Expires August 15, 2000 [Page 14]
785 Internet-Draft SMIng February 2000
788 an upper bound. Each value can be given in decimal or `0x'-prefixed
789 hexadecimal notation. Of course, size restricting values MUST NOT be
790 negative. If multiple values or ranges are given, they all MUST be
791 disjunct and SHOULD be in ascending order. If a size restriction is
792 applied to an already size restricted octet string the new
793 restriction MUST be more limiting, that is raising the lower bounds,
794 reducing the upper bounds, reducing the alternative size choices, or
795 splitting ranges into multiple ranges with intermediate gaps.
800 textual data example." // legal
801 "This is "illegally" quoted." // illegal quotes
802 "But this is 'ok'." // legal apostrophe quoting
803 "" // legal zero length
804 0x123 // illegal odd hex length
805 0x534d496e670a // legal octet string
807 Restriction Examples:
809 OctetString (0 | 4..255) // legal size spec
810 OctetString (4) // legal exact size
811 OctetString (-1 | 1) // illegal negative size
812 OctetString (1 | 1..10) // illegal overlapping
816 The ObjectIdentifier base type represents any object identifier
817 value, which is a list of up to 128 numbers, named sub-identifiers.
818 Each sub-identifier has a value between 0 and 2^32-1 (4294967295).
820 Values of object identifiers may be denoted as a sequence of
821 numerical sub-identifier values (decimal or `0x'-prefixed
822 hexadecimal) separated by single dots and without any intermediate
823 white space. Alternatively (and preferred in most cases), the first
824 element may be a previously defined or imported lower-case
825 identifier, representing a static object identifier prefix while the
826 total number of sub-identifiers MUST NOT exceed 128 including the
829 Object identifier derived types cannot be restricted in any way.
839 Strauss Expires August 15, 2000 [Page 15]
841 Internet-Draft SMIng February 2000
844 0 // legal single subid
845 1.3.6.1 // legal numerical oid
846 mib-2.1 // legal oid with identifier prefix
847 internet.4.1.0x0627.0x01 // legal oid with hex subids
848 iso.-1 // illegal negative subid
849 iso.org.6 // illegal non-heading identifier
850 IF-MIB::ifNumber.0 // legel fully quallified instance oid
854 The Integer32 base type represents integer values between -2^31
855 (-2147483648) and 2^31-1 (2147483647).
857 Values of type Integer32 may be denoted as decimal or hexadecimal
858 numbers, where only decimal numbers can be negative. Other decimal
859 numbers than zero MUST NOT have leading zero digits. Hexadecimal
860 numbers are prefixed by `0x' and MUST have an even number of
861 hexadecimal digits, where letters MAY be upper-case but lower-case
862 characters are RECOMMENDED.
864 When defining a type derived (directly or indirectly) from the
865 Integer32 base type, the set of possible values may be restricted by
866 appending a list of ranges or explicit values, separated by pipe `|'
867 characters and the whole list enclosed in parenthesis. A range
868 consists of a lower bound, two consecutive dots `..' and an upper
869 bound. Each value can be given in decimal or `0x'-prefixed
870 hexadecimal notation. If multiple values or ranges are given they
871 all MUST be disjunct and SHOULD be in ascending order. If a value
872 restriction is applied to an already restricted type the new
873 restriction MUST be more limiting, that is raising the lower bounds,
874 reducing the upper bounds, reducing the alternative choices, or
875 splitting ranges into multiple ranges with intermediate gaps.
879 015 // illegal leading zero
880 -123 // legal negative value
881 - 1 // illegal intermediate space
882 0xabc // illegal hexadecimal value length
883 -0xff // illegal sign on hex value
884 0x80000000 // illegal value, too large
885 0xf00f // legal hexadecimal value
887 Restriction Examples:
889 Integer32 (0 | 5..10) // legal range spec
890 Integer32 (4..8 | 5..10) // illegal overlapping
895 Strauss Expires August 15, 2000 [Page 16]
897 Internet-Draft SMIng February 2000
902 The Integer64 base type represents integer values between -2^63
903 (-9223372036854775808) and 2^63-1 (9223372036854775807).
905 Values of type Integer64 may be denoted as decimal or hexadecimal
906 numbers, where only decimal numbers can be negative. Other decimal
907 numbers than zero MUST NOT have leading zero digits. Hexadecimal
908 numbers are prefixed by `0x' and MUST have an even number of
909 hexadecimal digits, where letters MAY be upper-case but lower-case
910 characters are RECOMMENDED.
912 When defining a type derived (directly or indirectly) from the
913 Integer64 base type, the set of possible values may be restricted by
914 appending a list of ranges or explicit values, separated by pipe `|'
915 characters and the whole list enclosed in parenthesis. A range
916 consists of a lower bound, two consecutive dots `..' and an upper
917 bound. Each value can be given in decimal or `0x'-prefixed
918 hexadecimal notation. If multiple values or ranges are given they
919 all MUST be disjunct and SHOULD be in ascending order. If a value
920 restriction is applied to an already restricted type the new
921 restriction MUST be more limiting, that is raising the lower bounds,
922 reducing the upper bounds, reducing the alternative choices, or
923 splitting ranges into multiple ranges with intermediate gaps.
927 015 // illegal leading zero
928 -123 // legal negative value
929 - 1 // illegal intermediate space
930 0xabc // illegal hexadecimal value length
931 -0xff // illegal sign on hex value
932 0x80000000 // legal value
934 Restriction Examples:
936 Integer64 (0 | 5..10) // legal range spec
937 Integer64 (4..8 | 5..10) // illegal overlapping
941 The Unsigned32 base type represents positive integer values between
942 0 and 2^32-1 (4294967295).
944 Values of type Unsigned32 may be denoted as decimal or hexadecimal
945 numbers. Other decimal numbers than zero MUST NOT have leading zero
946 digits. Hexadecimal numbers are prefixed by `0x' and MUST have an
947 even number of hexadecimal digits, where letters MAY be upper-case
948 but lower-case characters are RECOMMENDED.
951 Strauss Expires August 15, 2000 [Page 17]
953 Internet-Draft SMIng February 2000
956 When defining a type derived (directly or indirectly) from the
957 Unsigned32 base type, the set of possible values may be restricted
958 by appending a list of ranges or explicit values, separated by pipe
959 `|' characters and the whole list enclosed in parenthesis. A range
960 consists of a lower bound, two consecutive dots `..' and an upper
961 bound. Each value can be given in decimal or `0x'-prefixed
962 hexadecimal notation. If multiple values or ranges are given they
963 all MUST be disjunct and SHOULD be in ascending order. If a value
964 restriction is applied to an already restricted type the new
965 restriction MUST be more limiting, that is raising the lower bounds,
966 reducing the upper bounds, reducing the alternative choices, or
967 splitting ranges into multiple ranges with intermediate gaps.
971 015 // illegal leading zero
972 -123 // illegal negative value
973 0xabc // illegal hexadecimal value length
974 0x80000000 // legal hexadecimal value
975 0x8080000000 // illegal value, too large]]>
977 Restriction Examples:
979 Unsigned32 (0 | 5..10) // legal range spec
980 Unsigned32 (4..8 | 5..10) // illegal overlapping
984 The Unsigned64 base type represents positive integer values between
985 0 and 2^64-1 (18446744073709551615).
987 Values of type Unsigned64 may be denoted as decimal or hexadecimal
988 numbers. Other decimal numbers than zero MUST NOT have leading zero
989 digits. Hexadecimal numbers are prefixed by `0x' and MUST have an
990 even number of hexadecimal digits, where letters MAY be upper-case
991 but lower-case characters are RECOMMENDED.
993 When defining a type derived (directly or indirectly) from the
994 Unsigned64 base type, the set of possible values may be restricted
995 by appending a list of ranges or explicit values, separated by pipe
996 `|' characters and the whole list enclosed in parenthesis. A range
997 consists of a lower bound, two consecutive dots `..' and an upper
998 bound. Each value can be given in decimal or `0x'-prefixed
999 hexadecimal notation. If multiple values or ranges are given they
1000 all MUST be disjunct and SHOULD be in ascending order. If a value
1001 restriction is applied to an already restricted type the new
1002 restriction MUST be more limiting, that is raising the lower bounds,
1003 reducing the upper bounds, reducing the alternative choices, or
1004 splitting ranges into multiple ranges with intermediate gaps.
1007 Strauss Expires August 15, 2000 [Page 18]
1009 Internet-Draft SMIng February 2000
1014 015 // illegal leading zero
1015 -123 // illegal negative value
1016 0xabc // illegal hexadecimal value length
1017 0x8080000000 // legal hexadecimal value
1019 Restriction Examples:
1021 Unsigned64 (1..10000000000) // legal range spec
1025 The Float32 base type represents floating point values of single
1026 precision as described by [11].
1028 Values of type Float32 may be denoted as a decimal fraction with an
1029 optional exponent as known from many programming languages. See the
1030 grammar rule `floatValue' of Appendix A for the detailed syntax.
1031 Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
1032 Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
1033 infinity). Note that -0.0 and +0.0 are different floating point
1034 values. 0.0 is equal to +0.0.
1036 When defining a type derived (directly or indirectly) from the
1037 Float32 base type, the set of possible values may be restricted by
1038 appending a list of ranges or explicit values, separated by pipe `|'
1039 characters and the whole list enclosed in parenthesis. A range
1040 consists of a lower bound, two consecutive dots `..' and an upper
1041 bound. If multiple values or ranges are given they all MUST be
1042 disjunct and SHOULD be in ascending order. If a value restriction
1043 is applied to an already restricted type the new restriction MUST be
1044 more limiting, that is raising the lower bounds, reducing the upper
1045 bounds, reducing the alternative choices, or splitting ranges into
1046 multiple ranges with intermediate gaps. The special values `snan',
1047 `qnan', `neginf', and `posinf' must be explicitly listed in
1048 restrictions if they shall be included, where `snan' and `qnan'
1049 cannot be used in ranges.
1051 Note that encoding is not subject to this specification. It has to
1052 be described by protocols that transport objects of type Float32.
1053 Note also that most floating point encodings disallow the
1054 representation of many values that can be written as decimal
1055 fractions as used in SMIng for human readability. Therefore,
1056 explicit values in floating point type restrictions should be
1063 Strauss Expires August 15, 2000 [Page 19]
1065 Internet-Draft SMIng February 2000
1068 00.1 // illegal leading zero
1069 3.1415 // legal value
1070 -2.5E+3 // legal negative exponential value
1072 Restriction Examples:
1074 Float32 (-1.0..1.0) // legal range spec
1075 Float32 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
1076 Float32 (-10.0..10.0 | 0) // illegal overlapping
1080 The Float64 base type represents floating point values of double
1081 precision as described by [11].
1083 Values of type Float64 may be denoted as a decimal fraction with an
1084 optional exponent as known from many programming languages. See the
1085 grammar rule `floatValue' of Appendix A for the detailed syntax.
1086 Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
1087 Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
1088 infinity). Note that -0.0 and +0.0 are different floating point
1089 values. 0.0 is equal to +0.0.
1091 When defining a type derived (directly or indirectly) from the
1092 Float64 base type, the set of possible values may be restricted by
1093 appending a list of ranges or explicit values, separated by pipe `|'
1094 characters and the whole list enclosed in parenthesis. A range
1095 consists of a lower bound, two consecutive dots `..' and an upper
1096 bound. If multiple values or ranges are given they all MUST be
1097 disjunct and SHOULD be in ascending order. If a value restriction
1098 is applied to an already restricted type the new restriction MUST be
1099 more limiting, that is raising the lower bounds, reducing the upper
1100 bounds, reducing the alternative choices, or splitting ranges into
1101 multiple ranges with intermediate gaps. The special values `snan',
1102 `qnan', `neginf', and `posinf' must be explicitly listed in
1103 restrictions if they shall be included, where `snan' and `qnan'
1104 cannot be used in ranges. If 0.0 is included, -0.0 will also be.
1106 Note that encoding is not subject to this specification. It has to
1107 be described by protocols that transport objects of type Float64.
1108 Note also that most floating point encodings disallow the
1109 representation of many values that can be written as decimal
1110 fractions as used in SMIng for human readability. Therefore,
1111 explicit values in floating point type restrictions should be
1119 Strauss Expires August 15, 2000 [Page 20]
1121 Internet-Draft SMIng February 2000
1124 00.1 // illegal leading zero
1125 3.1415 // legal value
1126 -2.5E+3 // legal negative exponential value
1128 Restriction Examples:
1130 Float64 (-1.0..1.0) // legal range spec
1131 Float64 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
1132 Float64 (-10.0..10.0 | 0) // illegal overlapping
1136 The Float128 base type represents floating point values of quadruple
1137 precision as described by [11].
1139 Values of type Float128 may be denoted as a decimal fraction with an
1140 optional exponent as known from many programming languages. See the
1141 grammar rule `floatValue' of Appendix A for the detailed syntax.
1142 Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
1143 Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
1144 infinity). Note that -0.0 and +0.0 are different floating point
1145 values. 0.0 is equal to +0.0.
1147 When defining a type derived (directly or indirectly) from the
1148 Float128 base type, the set of possible values may be restricted by
1149 appending a list of ranges or explicit values, separated by pipe `|'
1150 characters and the whole list enclosed in parenthesis. A range
1151 consists of a lower bound, two consecutive dots `..' and an upper
1152 bound. If multiple values or ranges are given they all MUST be
1153 disjunct and SHOULD be in ascending order. If a value restriction
1154 is applied to an already restricted type the new restriction MUST be
1155 more limiting, that is raising the lower bounds, reducing the upper
1156 bounds, reducing the alternative choices, or splitting ranges into
1157 multiple ranges with intermediate gaps. The special values `snan',
1158 `qnan', `neginf', and `posinf' must be explicitly listed in
1159 restrictions if they shall be included, where `snan' and `qnan'
1160 cannot be used in ranges. If 0.0 is included, -0.0 will also be.
1162 Note that encoding is not subject to this specification. It has to
1163 be described by protocols that transport objects of type Float128.
1164 Note also that most floating point encodings disallow the
1165 representation of many values that can be written as decimal
1166 fractions as used in SMIng for human readability. Therefore,
1167 explicit values in floating point type restrictions should be
1175 Strauss Expires August 15, 2000 [Page 21]
1177 Internet-Draft SMIng February 2000
1180 00.1 // illegal leading zero
1181 3.1415 // legal value
1182 -2.5E+3 // legal negative exponential value
1184 Restriction Examples:
1186 Float128 (-1.0..1.0) // legal range spec
1187 Float128 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
1188 Float128 (-10.0..10.0 | 0) // illegal overlapping
1192 The Enumeration base type represents values from a set of integers
1193 in the range between -2^31 (-2147483648) and 2^31-1 (2147483647),
1194 where each value has an assigned name. The list of those named
1195 numbers has to be comma-separated, enclosed in parenthesis and
1196 appended to the `Enumeration' keyword. Each named number is denoted
1197 by its lower-case identifier followed by the assigned integer value,
1198 denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed
1199 in parenthesis. Every name and every number in an enumeration type
1200 MUST be unique. It is RECOMMENDED that values start at 1 and be
1201 numbered contiguously.
1203 Values of enumeration types may be denoted as decimal or
1204 `0x'-prefixed hexadecimal numbers or preferably as their assigned
1207 When defining a type derived (directly or indirectly) from an
1208 enumeration type, the set of named numbers may be restricted by
1209 removing one or more named numbers. But no named numbers may be
1210 added or changed regarding its name, value, or both.
1212 Type and Value Examples:
1214 Enumeration (up(1), down(2), testing(3))
1216 0 // illegal, value 0 out of range
1217 up // legal value given by name
1218 2 // legal value given by number
1222 The Bits base type represents bit sets. That is, a Bits value is a
1223 set of flags identified by small integer numbers starting at 0.
1224 Each bit number has an assigned name. The list of those named
1225 numbers has to be comma-separated, enclosed in parenthesis and
1226 appended to the `Bits' keyword. Each named number is denoted by its
1227 lower-case identifier followed by the assigned integer value,
1228 denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed
1231 Strauss Expires August 15, 2000 [Page 22]
1233 Internet-Draft SMIng February 2000
1236 in parenthesis. Every name and every number in a bits type MUST be
1237 unique. It is RECOMMENDED that numbers start at 0 and be numbered
1240 Values of bits types may be denoted as a comma-separated list of
1241 decimal or `0x'-prefixed hexadecimal numbers or preferably their
1242 assigned names enclosed in parenthesis. There MUST NOT be any
1243 element (by name or number) listed more than once. It is RECOMMENDED
1244 to list elements in ascending order, although the order is
1245 semantically irrelevant.
1247 When defining a type derived (directly or indirectly) from a bits
1248 type, the set of named numbers may be restricted by removing one or
1249 more named numbers. But no named numbers may be added or changed
1250 regarding its name, value, or both.
1252 Type and Value Examples:
1254 Bits (readable(0), writeable(1), executable(2))
1256 () // legal empty value
1257 (readable, writeable, 2) // legal value
1258 (0, readable, executable) // illegal, readable(0) appears twice
1259 (writeable, 4) // illegal, element 4 out of range
1261 3.12 Display Formats
1263 Some SMIng definitions, namely scalar and columnar object
1264 definitions and type definitions, allow the specification of a
1265 format to be used, when a value of that object or an object of that
1266 type is displayed. Format specifications are represented as textual
1269 When the object or type has an underlying base type of Integer32,
1270 Integer64, Unsigned32, or Unsigned64, the format consists of an
1271 integer-format specification, containing two parts. The first part
1272 is a single character suggesting a display format, either: `x' for
1273 hexadecimal, or `d' for decimal, or `o' for octal, or `b' for
1274 binary. For all types, when rendering the value, leading zeros are
1275 omitted, and for negative values, a minus sign is rendered
1276 immediately before the digits. The second part is always omitted
1277 for `x', `o' and `b', and need not be present for `d'. If present,
1278 the second part starts with a hyphen and is followed by a decimal
1279 number, which defines the implied decimal point when rendering the
1280 value. For example `d-2' suggests that a value of 1234 be rendered
1283 When the object or type has an underlying base type of OctetString,
1284 the format consists of one or more octet-format specifications.
1287 Strauss Expires August 15, 2000 [Page 23]
1289 Internet-Draft SMIng February 2000
1292 Each specification consists of five parts, with each part using and
1293 removing zero or more of the next octets from the value and
1294 producing the next zero or more characters to be displayed. The
1295 octets within the value are processed in order of significance, most
1298 The five parts of a octet-format specification are:
1300 1. the (optional) repeat indicator; if present, this part is a `*',
1301 and indicates that the current octet of the value is to be used
1302 as the repeat count. The repeat count is an unsigned integer
1303 (which may be zero) which specifies how many times the remainder
1304 of this octet-format specification should be successively
1305 applied. If the repeat indicator is not present, the repeat
1308 2. the octet length: one or more decimal digits specifying the
1309 number of octets of the value to be used and formatted by this
1310 octet-specification. Note that the octet length can be zero.
1311 If less than this number of octets remain in the value, then the
1312 lesser number of octets are used.
1314 3. the display format, either: `x' for hexadecimal, `d' for
1315 decimal, `o' for octal, `a' for ASCII, or `t' for UTF-8 [12]. If
1316 the octet length part is greater than one, and the display
1317 format part refers to a numeric format, then network
1318 byte-ordering (big-endian encoding) is used interpreting the
1319 octets in the value. The octets processed by the `t' display
1320 format do not necessarily form an integral number of UTF-8
1321 characters. Trailing octets which do not form a valid UTF-8
1322 encoded character are discarded.
1324 4. the (optional) display separator character; if present, this
1325 part is a single character which is produced for display after
1326 each application of this octet-specification; however, this
1327 character is not produced for display if it would be immediately
1328 followed by the display of the repeat terminator character for
1329 this octet specification. This character can be any character
1330 other than a decimal digit and a `*'.
1332 5. the (optional) repeat terminator character, which can be present
1333 only if the display separator character is present and this
1334 octet specification begins with a repeat indicator; if present,
1335 this part is a single character which is produced after all the
1336 zero or more repeated applications (as given by the repeat
1337 count) of this octet specification. This character can be any
1338 character other than a decimal digit and a `*'.
1340 Output of a display separator character or a repeat terminator
1343 Strauss Expires August 15, 2000 [Page 24]
1345 Internet-Draft SMIng February 2000
1348 character is suppressed if it would occur as the last character of
1351 If the octets of the value are exhausted before all the octet format
1352 specification have been used, then the excess specifications are
1353 ignored. If additional octets remain in the value after
1354 interpreting all the octet format specifications, then the last
1355 octet format specification is re-interpreted to process the
1356 additional octets, until no octets remain in the value.
1358 Note that for some types (e.g. ObjectIdentifier) no format
1359 specifications are defined and SHOULD be omitted. Implementations
1360 MUST ignore format specifications they cannot interpret. Also note
1361 that the SMIng grammar (Appendix A) does not specify the syntax of
1362 format specifications.
1364 Display Format Examples:
1366 Base Type Format Example Value Rendered Value
1367 ----------- ------------------- ---------------- -----------------
1368 OctetString 255a "Hello World." Hello World.
1369 OctetString 1x: "Hello!" 48:65:6c:6c:6f:21
1370 OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0
1371 OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024
1372 OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee
1373 Integer32 d-2 1234 12.34
1399 Strauss Expires August 15, 2000 [Page 25]
1401 Internet-Draft SMIng February 2000
1404 4. The SMIng File Structure
1406 The topmost container of SMIng information is a file. An SMIng file
1407 may contain zero, one or more modules. It is RECOMMENDED to separate
1408 modules into files named by their modules, where possible. Though,
1409 for dedicated purposes it may be reasonable to collect several
1410 modules in a single file.
1412 The top level SMIng construct is the `module' statement (Section 5)
1413 that defines a single MIB module. A module contains a sequence of
1414 sections in an obligatory order with different kinds of definitions.
1415 Whether these sections contain statements or remain empty mainly
1416 depends on the purpose of the module (see Section 2).
1420 Comments can be included at any position in an SMIng file, except in
1421 between the characters of a single token like those of a quoted
1422 strings. However, it is RECOMMENDED that all substantive
1423 descriptions be placed within an appropriate description clause.
1425 Comments commence with a pair of adjacent slashes `//' and end at
1426 the end of the line.
1428 4.2 Statements and Arguments
1430 SMIng has a very small set of basic grammar rules based on the
1431 concept of statements. Each statement starts with a lower-case
1432 keyword identifying the statement followed by a number (possibly
1433 zero) of arguments. An argument may be quoted text, an identifier, a
1434 value of any base type, a list of identifiers enclosed in
1435 parenthesis `( )' or a statement block enclosed in curly braces `{
1436 }'. Since statement blocks are valid arguments, it is possible to
1437 nest statement sequences. Each statement is terminated by a
1440 The core set of statements may be extended using the SMIng
1441 `extension' statement. See Section 6 and Section 16 for details.
1443 At places where a statement is expected, but an unknown lower-case
1444 word is read, those statements MUST be skipped up to the proper
1445 semicolon, including nested statement blocks.
1455 Strauss Expires August 15, 2000 [Page 26]
1457 Internet-Draft SMIng February 2000
1460 5. The module Statement
1462 The `module' statement is used as a container of all definitions of
1463 a single SMIng MIB module. It gets two arguments: an upper-case
1464 module name and a statement block that contains mandatory and
1465 optional statements and sections of statements in an obligatory
1468 module <MODULE-NAME> {
1470 <optional import statements>
1471 <organization statement>
1473 <description statement>
1474 <optional reference statement>
1475 <at least one revision statement>
1476 <optional identity statement>
1478 <optional extension statements>
1480 <optional typedef statements>
1482 <optional node/scalar/table statements>
1484 <optional notification statements>
1486 <optional group statements>
1488 <optional compliance statements>
1492 The optional `import' statements are followed by the mandatory
1493 `organization', `contact', and `description' statements and the
1494 optional `reference' statement, which in turn are followed by the
1495 mandatory `revision' statements. This part defines the module's meta
1496 information while the following sections contain its main
1499 See the `moduleStatement' rule of the SMIng grammar (Appendix A) for
1500 the formal syntax of the `module' statement.
1502 5.1 The module's import Statement
1504 The optional module's `import' statement is used to import
1505 descriptors from external modules into the local module's namespace.
1506 It gets two arguments: the name of the external module and a
1507 comma-separated list of one or more identifiers to be imported
1508 enclosed in parenthesis.
1511 Strauss Expires August 15, 2000 [Page 27]
1513 Internet-Draft SMIng February 2000
1516 Multiple `import' statements for the same module but with disjunct
1517 lists of identifiers are allowed, though NOT RECOMMENDED. Anyhow,
1518 the same identifier from the same module MUST NOT be imported
1519 multiple times. To import identifiers with the same name from
1520 different modules might be necessary and is allowed. To distinguish
1521 them in the local module, they have to be referred by qualified
1522 names. It is NOT RECOMMENDED to import identifiers not used in the
1525 See the `importStatement' rule of the SMIng grammar (Appendix A) for
1526 the formal syntax of the `import' statement.
1528 5.2 The module's organization Statement
1530 The module's `organization' statement, which must be present, gets
1531 one argument which is used to specify a textual description of the
1532 organization(s) under whose auspices this module was developed.
1534 5.3 The module's contact Statement
1536 The module's `contact' statement, which must be present, gets one
1537 argument which is used to specify the name, postal address,
1538 telephone number, and electronic mail address of the person to whom
1539 technical queries concerning this revision of this module should be
1542 5.4 The module's description Statement
1544 The module's `description' statement, which must be present, gets
1545 one argument which is used to specify a high-level textual
1546 description of the contents of this module.
1548 5.5 The module's reference Statement
1550 The module's `reference' statement, which need not be present, gets
1551 one argument which is used to specify a textual cross-reference to
1552 some other document, either another module which defines related
1553 management information, or some other document which provides
1554 additional information relevant to this module.
1556 5.6 The module's revision Statement
1558 The module's `revision' statement is repeatedly used to specify the
1559 editorial revisions of the module, including the initial revision.
1560 It gets one argument which is a statement block that holds detailed
1561 information in an obligatory order. A module MUST have at least one
1562 initial `revision' statement. For every editorial change, a new one
1563 MUST be added in front of the revisions sequence, so that all
1564 revisions are in reverse chronological order.
1567 Strauss Expires August 15, 2000 [Page 28]
1569 Internet-Draft SMIng February 2000
1572 See the `revisionStatement' rule of the SMIng grammar (Appendix A)
1573 for the formal syntax of the `revision' statement.
1575 5.6.1 The revision's date Statement
1577 The revision's `date' statement, which must be present, gets one
1578 argument which is used to specify the date and time of the revision
1579 in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the
1580 time `00:00'. The time is always given in UTC.
1582 See the `date' rule of the SMIng grammar (Appendix A) for the formal
1583 syntax of the revision's `date' statement.
1585 5.6.2 The revision's description Statement
1587 The revision's `description' statement, which must be present, gets
1588 one argument which is used to specify a high-level textual
1589 description of the revision.
1591 5.7 The module's identity Statement
1593 The module's `identity' statement, which need not be present, gets
1594 one argument which specifies a node identifier within the local
1595 module, so that the object identifier of this node can be used to
1596 identify the module.
1600 Consider how a skeletal MIB module might be constructed: e.g.,
1604 import IRTF-NMRG-SMING (experimental);
1607 "IETF SNMPv2 Working Group,
1608 IRTF Network Management Research Group (NMRG)";
1613 Postal: TU Braunschweig
1618 Phone: +49 531 391-3266
1619 EMail: strauss@ibr.cs.tu-bs.de";
1623 Strauss Expires August 15, 2000 [Page 29]
1625 Internet-Draft SMIng February 2000
1629 "The MIB module for entities implementing
1630 the xxxx protocol.";
1633 "RFC 2578, Section 5.7.";
1638 "Conversion from SMIv2 to SMIng.";
1641 date "1995-05-24 18:11";
1643 "Revision for RFC 1902.";
1646 date "1992-10-07 04:33";
1648 "The initial version of this MIB module,
1649 published in RFC 1442.";
1654 // ... further definitions ...
1656 }; // end of module FIZBIN-MIB.
1679 Strauss Expires August 15, 2000 [Page 30]
1681 Internet-Draft SMIng February 2000
1684 6. The extension Statement
1686 The `extension' statement is used to define new statements to be
1687 used in the local module following this extension statement
1688 definition or in external modules that may import this extension
1689 statement definition. The `extension' statement gets two arguments:
1690 a lower-case extension statement identifier and a statement block
1691 that holds detailed extension information in an obligatory order.
1693 Extension statement identifiers SHOULD NOT contain any upper-case
1694 characters or hyphens.
1696 Note that the SMIng extension feature does not allow to formally
1697 specify the context, argument syntax and semantics of an extension.
1698 Its only purpose is to declare the existence of an extension and to
1699 allow a unique reference to an extension. See Section 16 for
1700 detailed information on extensions and Section 14.3 for a common
1701 example, the `agentcaps' extension.
1703 See the `extensionStatement' rule of the SMIng grammar (Appendix A)
1704 for the formal syntax of the `extension' statement.
1706 6.1 The extension's status Statement
1708 The extension's `status' statement, which need not be present, gets
1709 one argument which is used to specify whether this extension
1710 definition is current or historic. The value `current' means that
1711 the definition is current and valid. The value `obsolete' means the
1712 definition is obsolete and should not be implemented and/or can be
1713 removed if previously implemented. While the value `deprecated'
1714 also indicates an obsolete definition, it permits new/continued
1715 implementation in order to foster interoperability with
1716 older/existing implementations.
1718 If the `status' statement is omitted, the status value `current' is
1721 6.2 The extension's description Statement
1723 The extension's `description' statement, which must be present, gets
1724 one argument which is used to specify a high-level textual
1725 description of the extension statement.
1727 It is RECOMMENDED to include information on the extension's context,
1728 its semantics, and implementation conditions. See also Section 16.
1730 6.3 The extension's reference Statement
1732 The extension's `reference' statement, which need not be present,
1735 Strauss Expires August 15, 2000 [Page 31]
1737 Internet-Draft SMIng February 2000
1740 gets one argument which is used to specify a textual cross-reference
1741 to some other document, either another module which defines related
1742 extension definitions, or some other document which provides
1743 additional information relevant to this extension.
1745 6.4 The extension's abnf Statement
1747 The extension's `abnf' statement, which need not be present, gets
1748 one argument which is used to specify a formal ABNF [8] grammar
1749 definition of the extension.
1751 Note that the `abnf' statement should contain only pure ABNF and no
1752 additional text, though comments prefixed by semicolon are allowed
1753 but should probably be moved to the description statement. Note also
1754 that double quotes are not allowed inside textual descriptions which
1755 are itself enclosed in double quotes. So they have to be replaced by
1791 Strauss Expires August 15, 2000 [Page 32]
1793 Internet-Draft SMIng February 2000
1796 7. The typedef Statement
1798 The `typedef' statement is used to define new data types to be used
1799 in the local module or in external modules. It gets two arguments:
1800 an upper-case type identifier and a statement block that holds
1801 detailed type information in an obligatory order.
1803 Type identifiers SHOULD NOT consist of all upper-case characters and
1804 SHOULD NOT contain hyphens.
1806 See the `typedefStatement' rule of the SMIng grammar (Appendix A)
1807 for the formal syntax of the `typedef' statement.
1809 7.1 The typedef's type Statement
1811 The typedef's `type' statement, which must be present, gets one
1812 argument which is used to specify the type from which this type is
1813 derived. Optionally, type restrictions may be applied to the new
1814 type by appending subtyping information according to the rules of
1815 the base type. See Section 3 for SMIng base types and their type
1818 7.2 The typedef's default Statement
1820 The typedef's `default' statement, which need not be present, gets
1821 one argument which is used to specify an acceptable default value
1822 for objects of this type. A default value may be used at the
1823 discretion of an agent when an object instance is created. That is,
1824 the value is a "hint" to implementors.
1826 The value of the `default' statement must, of course, correspond to
1827 the (probably restricted) type specified in the typedef's `type'
1830 The default value of a type may be overwritten by a default value of
1831 an object of this type.
1833 Note that for some types, default values make no sense, e.g.
1834 IRTF-NMRG-SMING-TYPES::Counter32.
1836 7.3 The typedef's format Statement
1838 The typedef's `format' statement, which need not be present, gets
1839 one argument which is used to give a hint as to how the value of an
1840 instance of an object of this type might be displayed. See Section
1841 3.12 for a description of format specifications.
1843 If no format is specified, it is inherited from the type given in
1844 the `type' statement. On the other hand, the format specification
1847 Strauss Expires August 15, 2000 [Page 33]
1849 Internet-Draft SMIng February 2000
1852 of a type may be overwritten by a format specification of an object
1855 7.4 The typedef's units Statement
1857 The typedef's `units' statement, which need not be present, gets one
1858 argument which is used to specify a textual definition of the units
1859 associated with objects of this type.
1861 If no units are specified, they are inherited from the type given in
1862 the `type' statement. On the other hand, the units specification of
1863 a type may be overwritten by a units specification of an object of
1866 The units specification has to be appropriate for values displayed
1867 according to the typedef's format specification, if present. E.g.,
1868 if the type defines frequency values of type Unsigned64 measured in
1869 thousands of Hertz, the format specification should be `d-3' and the
1870 units specification should be `Hertz' or `Hz'. If the format
1871 specification would be omitted, the units specification should be
1872 `Milli-Hertz' or `mHz'. MIB Authors should pay attention to keep
1873 format and units specifications of type and object definitions
1874 synced. Application implementors MUST NOT implement units
1875 specifications without implementing format specifications.
1877 7.5 The typedef's status Statement
1879 The typedef's `status' statement, which need not be present, gets
1880 one argument which is used to specify whether this type definition
1881 is current or historic. The value `current' means that the
1882 definition is current and valid. The value `obsolete' means the
1883 definition is obsolete and should not be implemented and/or can be
1884 removed if previously implemented. While the value `deprecated'
1885 also indicates an obsolete definition, it permits new/continued
1886 implementation in order to foster interoperability with
1887 older/existing implementations.
1889 Derived types SHOULD NOT be defined as `current' if their underlying
1890 type is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be
1891 defined as `deprecated' if their underlying type is `obsolete'.
1892 Nevertheless, subsequent revisions of the underlying type cannot be
1893 avoided, but SHOULD be taken into account in subsequent revisions of
1896 If the `status' statement is omitted, the status value `current' is
1903 Strauss Expires August 15, 2000 [Page 34]
1905 Internet-Draft SMIng February 2000
1908 7.6 The typedef's description Statement
1910 The typedef's `description' statement, which must be present, gets
1911 one argument which is used to specify a high-level textual
1912 description of the newly defined type.
1914 It is RECOMMENDED to include all semantic definitions necessary for
1915 implementation, and to embody any information which would otherwise
1916 be communicated in any commentary annotations associated with this
1919 7.7 The typedef's reference Statement
1921 The typedef's `reference' statement, which need not be present, gets
1922 one argument which is used to specify a textual cross-reference to
1923 some other document, either another module which defines related
1924 type definitions, or some other document which provides additional
1925 information relevant to this type definition.
1959 Strauss Expires August 15, 2000 [Page 35]
1961 Internet-Draft SMIng February 2000
1964 typedef RptrOperStatus {
1965 type Enumeration (other(1), ok(2), rptrFailure(3),
1966 groupFailure(4), portFailure(5),
1968 default other; // undefined by default.
1971 "A type to indicate the operational state
1974 "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState.";
1977 typedef DateAndTime {
1978 type OctetString (8 | 11);
1979 format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
1980 status current; // could be omitted
1982 "A date-time specification.
1984 Note that if only local time is known, then timezone
1985 information (fields 8-10) is not present.";
1987 "RFC 2579, SNMPv2-TC.DateAndTime.";
1995 "A wide-range frequency specification measured
1996 in thousands of Hertz.";
2015 Strauss Expires August 15, 2000 [Page 36]
2017 Internet-Draft SMIng February 2000
2020 8. The node Statement
2022 The `node' statement is used to name and describe a node in the
2023 object identifier tree, without associating object information with
2024 this node. This may be useful to group definitions in a subtree of
2025 related management information, or to uniquely define an identity of
2026 arbitrary kind to be referenced in objects of type ObjectIdentifier.
2027 The `node' statement gets two arguments: a lower-case node
2028 identifier and a statement block that holds detailed node
2029 information in an obligatory order.
2031 See the `nodeStatement' rule of the SMIng grammar (Appendix A) for
2032 the formal syntax of the `node' statement.
2034 8.1 The node's oid Statement
2036 The node's `oid' statement, which must be present, gets one argument
2037 which specifies the object identifier value that is assigned to this
2040 8.2 The node's status Statement
2042 The node's `status' statement, which need not be present, gets one
2043 argument which is used to specify whether this node definition is
2044 current or historic. The value `current' means that the definition
2045 is current and valid. The value `obsolete' means the definition is
2046 obsolete and should not be implemented and/or can be removed if
2047 previously implemented. While the value `deprecated' also indicates
2048 an obsolete definition, it permits new/continued implementation in
2049 order to foster interoperability with older/existing
2052 If the `status' statement is omitted, the status value `current' is
2055 8.3 The node's description Statement
2057 The node's `description' statement, which must be present, gets one
2058 argument which is used to specify a high-level textual description
2061 It is RECOMMENDED to include all semantics and purposes of this
2064 8.4 The node's reference Statement
2066 The node's `reference' statement, which need not be present, gets
2067 one argument which is used to specify a textual cross-reference to
2068 some other document, either another module which defines related
2071 Strauss Expires August 15, 2000 [Page 37]
2073 Internet-Draft SMIng February 2000
2076 nodes, or some other document which provides additional information
2077 relevant to this node.
2081 node iso { oid 1; };
2082 node org { oid iso.3; };
2083 node dod { oid org.6; };
2084 node internet { oid dod.1; };
2088 description "A value used for null identifiers.";
2089 reference "RFC 2578, 2. Definitions.";
2127 Strauss Expires August 15, 2000 [Page 38]
2129 Internet-Draft SMIng February 2000
2132 9. The scalar Statement
2134 The `scalar' statement is used to define a scalar managed object.
2135 The `scalar' statement gets two arguments: a lower-case scalar
2136 identifier and a statement block that holds detailed object
2137 information in an obligatory order.
2139 See the `scalarStatement' rule of the SMIng grammar (Appendix A) for
2140 the formal syntax of the `scalar' statement.
2142 9.1 The scalar's oid Statement
2144 The scalar's `oid' statement, which must be present, gets one
2145 argument which specifies the object identifier value that is
2146 assigned to this scalar object.
2148 9.2 The scalar's type Statement
2150 The scalar's `type' statement, which must be present, gets one
2151 argument which is used to specify the data type of this scalar
2152 object. Optionally, type restrictions may be applied to the type by
2153 appending subtyping information according to the rules of the base
2154 type. See Section 3 for SMIng base types and their type
2157 9.3 The scalar's access Statement
2159 The scalar's `access' statement, which must be present, gets one
2160 argument which is used to specify whether it makes sense to read
2161 and/or write an instance of the object, or to include its value in a
2162 notification. This is the maximal level of access for the object.
2163 This maximal level of access is independent of any administrative
2164 authorization policy.
2166 The value `readwrite' indicates that read and write access makes
2167 sense. The value `readonly' indicates that read access makes sense,
2168 but write access is never possible. The value `notifyonly' indicates
2169 an object which is accessible only via a notification.
2171 These values are ordered, from least to greatest access level:
2172 `notifyonly', `readonly', `readwrite'.
2174 9.4 The scalar's default Statement
2176 The scalar's `default' statement, which need not be present, gets
2177 one argument which is used to specify an acceptable default value
2178 for this scalar object. A default value may be used at the
2179 discretion of an agent when an object instance is created. That is,
2180 the value is a "hint" to implementors.
2183 Strauss Expires August 15, 2000 [Page 39]
2185 Internet-Draft SMIng February 2000
2188 The value of the `default' statement must, of course, correspond to
2189 the (probably restricted) type specified in the scalar's `type'
2192 The scalar's default value overrides the default value of the
2193 underlying type definition, if both are present.
2195 Note that for objects of some types, default values make no sense,
2196 e.g. IRTF-NMRG-SMING-TYPES::Counter32.
2198 9.5 The scalar's format Statement
2200 The scalar's `format' statement, which need not be present, gets one
2201 argument which is used to give a hint as to how the value of an
2202 instance of this object might be displayed. See Section 3.12 for a
2203 description of format specifications.
2205 The scalar's format specification overrides the format specification
2206 of the underlying type definition if both are present.
2208 9.6 The scalar's units Statement
2210 The scalar's `units' statement, which need not be present, gets one
2211 argument which is used to specify a textual definition of the units
2212 associated with this scalar object.
2214 The scalar's units specification overrides the units specification
2215 of the underlying type definition if both are present.
2217 The units specification has to be appropriate for values displayed
2218 according to the scalar's format specification if present. E.g., if
2219 the scalar object represents a frequency value of type Unsigned64
2220 measured in thousands of Hertz, the format specification should be
2221 `d-3' and the units specification should be `Hertz' or `Hz'. If the
2222 format specification would be omitted, the units specification
2223 should be `Milli-Hertz' or `mHz'. MIB Authors should pay attention
2224 to keep format and units specifications of type and object
2225 definitions synced. Application implementors MUST NOT implement
2226 units specifications without implementing format specifications.
2228 9.7 The scalar's status Statement
2230 The scalar's `status' statement, which need not be present, gets one
2231 argument which is used to specify whether this scalar object
2232 definition is current or historic. The value `current' means that
2233 the definition is current and valid. The value `obsolete' means the
2234 definition is obsolete and should not be implemented and/or can be
2235 removed if previously implemented. While the value `deprecated'
2236 also indicates an obsolete definition, it permits new/continued
2239 Strauss Expires August 15, 2000 [Page 40]
2241 Internet-Draft SMIng February 2000
2244 implementation in order to foster interoperability with
2245 older/existing implementations.
2247 Scalar objects SHOULD NOT be defined as `current' if their type is
2248 `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as
2249 `deprecated' if their type is `obsolete'. Nevertheless, subsequent
2250 revisions of used type definition cannot be avoided, but SHOULD be
2251 taken into account in subsequent revisions of the local module.
2253 If the `status' statement is omitted the status value `current' is
2256 9.8 The scalar's description Statement
2258 The scalar's `description' statement, which must be present, gets
2259 one argument which is used to specify a high-level textual
2260 description of this scalar object.
2262 It is RECOMMENDED to include all semantic definitions necessary for
2263 the implementation of this scalar object.
2265 9.9 The scalar's reference Statement
2267 The scalar's `reference' statement, which need not be present, gets
2268 one argument which is used to specify a textual cross-reference to
2269 some other document, either another module which defines related
2270 scalar objects, or some other document which provides additional
2271 information relevant to this scalar object.
2275 scalar dialCtlTrapEnable {
2276 oid dialCtlConfiguration.2;
2277 type Enumeration (enabled(1), disabled(2));
2281 "This object indicates whether dialCtlPeerCallInformation
2282 and dialCtlPeerCallSetup traps should be generated for
2283 all peers. If the value of this object is enabled(1),
2284 traps will be generated for all peers. If the value
2285 of this object is disabled(2), traps will be generated
2286 only for peers having dialCtlPeerCfgTrapEnable set
2295 Strauss Expires August 15, 2000 [Page 41]
2297 Internet-Draft SMIng February 2000
2300 10. The table Statement
2302 The `table' statement is used to define the root node of a table.
2303 The `table' statement gets two arguments: a lower-case table
2304 identifier and a statement block that holds detailed table
2305 information in an obligatory order.
2307 See the `tableStatement' rule of the SMIng grammar (Appendix A) for
2308 the formal syntax of the `table' statement.
2310 10.1 The table's oid Statement
2312 The table's `oid' statement, which must be present, gets one
2313 argument which specifies the object identifier value that is
2314 assigned to this table node.
2316 10.2 The table's status Statement
2318 The table's `status' statement, which need not be present, gets one
2319 argument which is used to specify whether this table definition is
2320 current or historic. The value `current' means that the definition
2321 is current and valid. The value `obsolete' means the definition is
2322 obsolete and should not be implemented and/or can be removed if
2323 previously implemented. While the value `deprecated' also indicates
2324 an obsolete definition, it permits new/continued implementation in
2325 order to foster interoperability with older/existing
2328 If the `status' statement is omitted the status value `current' is
2331 10.3 The table's description Statement
2333 The table's `description' statement, which must be present, gets one
2334 argument which is used to specify a high-level textual description
2337 It is RECOMMENDED to include all semantic definitions necessary for
2338 the implementation of this table.
2340 10.4 The table's reference Statement
2342 The table's `reference' statement, which need not be present, gets
2343 one argument which is used to specify a textual cross-reference to
2344 some other document, either another module which defines related
2345 tables, or some other document which provides additional information
2346 relevant to this table.
2351 Strauss Expires August 15, 2000 [Page 42]
2353 Internet-Draft SMIng February 2000
2356 10.5 The table's row Statement
2358 The table's `row' statement, which must be present, gets two
2359 arguments: a lower-case row identifier and a statement block that
2360 holds detailed row information in an obligatory order.
2362 See the `rowStatement' rule of the SMIng grammar (Appendix A) for
2363 the formal syntax of the `row' statement.
2365 10.5.1 The row's oid Statement
2367 The row's `oid' statement, which must be present, gets one argument
2368 which specifies the object identifier value that is assigned to this
2369 table row. Note that the object identifier of a table row MUST be
2370 built be the table's object identifier followed by a `1'
2373 10.5.2 Table Indexing Statements
2375 SMIng offers five methods to supply table indexing information:
2376 ordinary tables, table augmentations, sparse table augmentations,
2377 table expansions, and reordered tables use different statements to
2378 denote their indexing information. Each table row definition must
2379 contain exactly one of the following indexing statements.
2381 10.5.2.1 The row's index Statement for Table Indexing
2383 The row's `index' statement, which is used to supply table indexing
2384 information of base table rows, gets at least one argument that
2385 specifies a comma-separated list of object identifiers, that are
2386 used for table indexing, enclosed in parenthesis.
2388 Under some circumstances, an optional `implied' keyword may be added
2389 in front of the list to indicate a compact encoding of the last
2390 object in the list. See Section 2.4 for details.
2392 10.5.2.2 The row's augments Statement for Table Indexing
2394 The row's `augments' statement, which is used to supply table
2395 indexing information of table rows that augment a base table row,
2396 gets one argument that specifies the identifier of the table row to
2397 be augmented. Note that a row augmentation cannot itself be
2398 augmented. Anyhow, a base row may be augmented by multiple row
2401 A row augmentation makes instances of subordinate columnar objects
2402 identified according to the index specification of the base row
2403 corresponding to the row named in the `augments' statement.
2404 Further, instances of subordinate columnar objects of a row
2407 Strauss Expires August 15, 2000 [Page 43]
2409 Internet-Draft SMIng February 2000
2412 augmentation exist according to the same semantics as instances of
2413 subordinate columnar objects of the base row being augmented. As
2414 such, note that creation of a base row implies the correspondent
2415 creation of any row augmentations. Row augmentations MUST NOT be
2416 used in row creation and deletion operations.
2418 10.5.2.3 The row's sparse Statement for Table Indexing
2420 The row's `sparse' statement, which is used to supply table indexing
2421 information of table rows that sparsely augment a base table row,
2422 gets one argument that specifies the identifier of the table row to
2423 be sparsely augmented. Note that a sparse row augmentation cannot
2424 itself be augmented. Anyhow, a base row may be augmented by multiple
2425 row augmentations, sparsely or not.
2427 A sparse row augmentation makes instances of subordinate columnar
2428 objects identified, if present, according to the index specification
2429 of the base row corresponding to the row named in the `sparse'
2430 statement. Further, instances of subordinate columnar objects of a
2431 sparse row augmentation exist according to the semantics as
2432 instances of subordinate columnar objects of the base row and the
2433 (non-formal) rules that confine the sparse relationship. As such,
2434 note that creation of a sparse row augmentation may be implied by
2435 the creation of a base row as well as done by an explicit creation.
2436 However, if a base row gets deleted, any dependent sparse row
2437 augmentations get also deleted implicitly.
2439 10.5.2.4 The row's reorders Statement for Table Indexing
2441 The row's `reorders' statement is used to supply table indexing
2442 information of table rows, that contain exactly the same index
2443 objects of a base table row, except in another order. It gets at
2444 least two arguments. The first one specifies the identifier of the
2445 base table row. The second one specifies a comma-separated list of
2446 exactly those object identifiers of the base row's `index'
2447 statement, but in the order to be used in this table. Note that a
2448 reordered table cannot itself be reordered. Anyhow, a base row may
2449 be used for multiple reordered tables.
2451 Under some circumstances, an optional `implied' keyword may be added
2452 in front of the list to indicate a compact encoding of the last
2453 object in the list. See Section 2.4 for details.
2455 Instances of subordinate columnar objects of a reordered table exist
2456 according to the same semantics as instances of subordinate columnar
2457 objects of the base row. As such, note that creation of a base row
2458 implies the correspondent creation of any related reordered table.
2459 Rows or reordered tables MUST NOT be used in row creation and
2460 deletion operations.
2463 Strauss Expires August 15, 2000 [Page 44]
2465 Internet-Draft SMIng February 2000
2468 10.5.2.5 The row's expands Statement for Table Indexing
2470 The row's `expands' statement is used to supply table indexing
2471 information of table row expansions. Table row expansions use
2472 exactly the same index objects of another row together with
2473 additional indexing objects. Thus, the `expands' statement gets at
2474 least two arguments. The first one specifies the identifier of the
2475 related table row. The second one specifies a comma-separated list
2476 of the additional object identifiers used for indexing. Note that an
2477 expanded table may itself be expanded, and related rows may be used
2478 for multiple table expansions.
2480 Under some circumstances, an optional `implied' keyword may be added
2481 in front of the list to indicate a compact encoding of the last
2482 object in the list. See Section 2.4 for details.
2484 10.5.3 The row's create Statement
2486 The row's `create' statement, which need not be present, gets no
2487 argument. If the `create' statement is present, row creation (and
2488 deletion) is possible.
2490 10.5.4 The row's status Statement
2492 The row's `status' statement, which need not be present, gets one
2493 argument which is used to specify whether this row definition is
2494 current or historic. The value `current' means that the definition
2495 is current and valid. The value `obsolete' means the definition is
2496 obsolete and should not be implemented and/or can be removed if
2497 previously implemented. While the value `deprecated' also indicates
2498 an obsolete definition, it permits new/continued implementation in
2499 order to foster interoperability with older/existing
2502 If the `status' statement is omitted the status value `current' is
2505 10.5.5 The row's description Statement
2507 The row's `description' statement, which must be present, gets one
2508 argument which is used to specify a high-level textual description
2511 It is RECOMMENDED to include all semantic definitions necessary for
2512 the implementation of this table row. Especially, if the row's
2513 indexing statement contains objects that are not columnar objects of
2514 the row, it SHOULD be described how these objects are used in
2515 uniquely identifying instances of the row's columnar objects.
2519 Strauss Expires August 15, 2000 [Page 45]
2521 Internet-Draft SMIng February 2000
2524 10.5.6 The row's reference Statement
2526 The row's `reference' statement, which need not be present, gets one
2527 argument which is used to specify a textual cross-reference to some
2528 other document, either another module which defines related table
2529 rows, or some other document which provides additional information
2530 relevant to this table row.
2532 10.6 The table row's column Statement
2534 The row's `column' statement is used to define a columnar managed
2535 object. The `column' statement gets two arguments: a lower-case
2536 column identifier and a statement block that holds detailed object
2537 information in an obligatory order.
2539 See the `columnStatement' rule of the SMIng grammar (Appendix A) for
2540 the formal syntax of the `column' statement.
2542 10.6.1 The column's oid Statement
2544 The column's `oid' statement, which must be present, gets one
2545 argument which specifies the object identifier value that is
2546 assigned to this columnar object.
2548 10.6.2 The column's type Statement
2550 The column's `type' statement, which must be present, gets at least
2551 one argument which is used to specify the data type of this columnar
2552 object. Optionally, type restrictions may be applied to the type by
2553 appending subtyping information according to the rules of the base
2554 type. See Section 3 for SMIng base types and their type
2557 10.6.3 The column's access Statement
2559 The column's `access' statement, which must be present, gets one
2560 argument which is used to specify whether it makes sense to read
2561 and/or write an instance of the object, or to include its value in a
2562 notification. This is the maximal level of access for the object.
2563 This maximal level of access is independent of any administrative
2564 authorization policy.
2566 The value `readwrite' indicates that read and write access makes
2567 sense. The value `readonly' indicates that read access makes sense,
2568 but write access is never possible. The value `noaccess' indicates
2569 an auxiliary object (see Section 2.4). The value `notifyonly'
2570 indicates an object which is accessible only via a notification.
2572 These values are ordered, from least to greatest access level:
2575 Strauss Expires August 15, 2000 [Page 46]
2577 Internet-Draft SMIng February 2000
2580 `noaccess', `notifyonly', `readonly', `readwrite'.
2582 10.6.4 The column's default Statement
2584 The column's `default' statement, which need not be present, gets
2585 one argument which is used to specify an acceptable default value
2586 for this columnar object. A default value may be used at the
2587 discretion of an agent when an object instance is created. That is,
2588 the value is a "hint" to implementors.
2590 The value of the `default' statement must, of course, correspond to
2591 the (probably restricted) type specified in the column's `type'
2594 The column's default value overrides the default value of the
2595 underlying type definition if both are present.
2597 Note that for objects of some types, default values make no sense,
2598 e.g. IRTF-NMRG-SMING-TYPES::Counter32.
2600 10.6.5 The column's format Statement
2602 The column's `format' statement, which need not be present, gets one
2603 argument which is used to give a hint as to how the value of an
2604 instance of this object might be displayed. See Section 3.12 for a
2605 description of format specifications.
2607 The column's format specification overrides the format specification
2608 of the underlying type definition if both are present.
2610 10.6.6 The column's units Statement
2612 The column's `units' statement, which need not be present, gets one
2613 argument which is used to specify a textual definition of the units
2614 associated with this columnar object.
2616 The column's units specification overrides the units specification
2617 of the underlying type definition if both are present.
2619 The units specification has to be appropriate for values displayed
2620 according to the column's format specification if present. E.g., if
2621 the columnar object represents a frequency value of type Unsigned64
2622 measured in thousands of Hertz, the format specification should be
2623 `d-3' and the units specification should be `Hertz' or `Hz'. If the
2624 format specification would be omitted the units specification should
2625 be `Milli-Hertz' or `mHz'. MIB Authors should pay attention to keep
2626 format and units specifications of type and object definitions
2627 synced. Application implementors MUST NOT implement units
2628 specifications without implementing format specifications.
2631 Strauss Expires August 15, 2000 [Page 47]
2633 Internet-Draft SMIng February 2000
2636 10.6.7 The column's status Statement
2638 The column's `status' statement, which need not be present, gets one
2639 argument which is used to specify whether this columnar object
2640 definition is current or historic. The value `current' means that
2641 the definition is current and valid. The value `obsolete' means the
2642 definition is obsolete and should not be implemented and/or can be
2643 removed if previously implemented. While the value `deprecated'
2644 also indicates an obsolete definition, it permits new/continued
2645 implementation in order to foster interoperability with
2646 older/existing implementations.
2648 Columnar objects SHOULD NOT be defined as `current' if their type is
2649 `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as
2650 `deprecated' if their type is `obsolete'. Nevertheless, subsequent
2651 revisions of used type definition cannot be avoided, but SHOULD be
2652 taken into account in subsequent revisions of the local module.
2654 If the `status' statement is omitted the status value `current' is
2657 10.6.8 The column's description Statement
2659 The column's `description' statement, which must be present, gets
2660 one argument which is used to specify a high-level textual
2661 description of this columnar object.
2663 It is RECOMMENDED to include all semantic definitions necessary for
2664 the implementation of this columnar object.
2666 10.6.9 The column's reference Statement
2668 The column's `reference' statement, which need not be present, gets
2669 one argument which is used to specify a textual cross-reference to
2670 some other document, either another module which defines related
2671 columnar objects, or some other document which provides additional
2672 information relevant to this columnar object.
2676 Consider how one might define a table and its subordinates. (This
2677 example uses the RowStatus type defined in Section 14.2.)
2681 type Integer32 (0..2147483647);
2684 "The index number of the first unassigned entry in the
2687 Strauss Expires August 15, 2000 [Page 48]
2689 Internet-Draft SMIng February 2000
2692 evaluation table, or the value of zero indicating that
2693 all entries are assigned.
2695 A management station should create new entries in the
2696 evaluation table using this algorithm: first, issue a
2697 management protocol retrieval operation to determine the
2698 value of evalSlot; and, second, issue a management
2699 protocol set operation to create an instance of the
2700 evalStatus object setting its value to createAndGo(4) or
2701 createAndWait(5). If this latter operation succeeds,
2702 then the management station may continue modifying the
2703 instances corresponding to the newly created conceptual
2704 row, without fear of collision with other management
2711 "The (conceptual) evaluation table.";
2718 create (evalStatus);
2720 "An entry (conceptual row) in the evaluation table.";
2724 type Integer32 (1..2147483647);
2727 "The auxiliary variable used for identifying instances of
2728 the columnar objects in the evaluation table.";
2736 "The string to evaluate.";
2743 Strauss Expires August 15, 2000 [Page 49]
2745 Internet-Draft SMIng February 2000
2752 "The value when evalString was last evaluated, or zero if
2753 no such value is available.";
2762 "The status column used for creating, modifying, and
2763 deleting instances of the columnar objects in the
2799 Strauss Expires August 15, 2000 [Page 50]
2801 Internet-Draft SMIng February 2000
2804 11. The notification Statement
2806 The `notification' statement is used to define a notification. It
2807 gets two arguments: a lower-case notification identifier and a
2808 statement block that holds detailed information in an obligatory
2811 See the `notificationStatement' rule of the SMIng grammar (Appendix
2812 A) for the formal syntax of the `notification' statement.
2814 11.1 The notification's oid Statement
2816 The notification's `oid' statement, which must be present, gets one
2817 argument which specifies the object identifier value that is
2818 assigned to this notification.
2820 11.2 The notification's objects Statement
2822 The notification's `objects' statement, which need not be present,
2823 gets one argument which specifies an ordered sequence of objects by
2824 their identifiers to be emitted within this notification. The list
2825 of objects has to be comma-separated and enclosed in parenthesis.
2827 One and only one object instance for each occurrence of each object
2828 must be present, and in the specified order, in every instance of
2829 the notification. If the same object occurs multiple times in a
2830 notification's `objects' statement, then an object instance is
2831 present for each of them. An object specified in this sequence must
2832 not have an `access' statement argument of `noaccess'.
2834 Note that an agent is allowed, at its own discretion, to append as
2835 many additional objects as it considers useful to the end of the
2836 notification (i.e., after the objects defined by the notification's
2837 `objects' statement if present).
2839 11.3 The notification's status Statement
2841 The notification's `status' statement, which need not be present,
2842 gets one argument which is used to specify whether this notification
2843 definition is current or historic. The value `current' means that
2844 the definition is current and valid. The value `obsolete' means the
2845 definition is obsolete and should not be implemented and/or can be
2846 removed if previously implemented. While the value `deprecated'
2847 also indicates an obsolete definition, it permits new/continued
2848 implementation in order to foster interoperability with
2849 older/existing implementations.
2851 If the `status' statement is omitted the status value `current' is
2855 Strauss Expires August 15, 2000 [Page 51]
2857 Internet-Draft SMIng February 2000
2860 11.4 The notification's description Statement
2862 The notification's `description' statement, which must be present,
2863 gets one argument which is used to specify a high-level textual
2864 description of this notification.
2866 It is RECOMMENDED to include all semantic definitions necessary for
2867 the implementation of this notification. In particular, it SHOULD be
2868 documented which instances of the objects mentioned in the `objects'
2869 statement should be contained within notifications of this type.
2871 11.5 The notification's reference Statement
2873 The notification's `reference' statement, which need not be present,
2874 gets one argument which is used to specify a textual cross-reference
2875 to some other document, either another module which defines related
2876 notifications, or some other document which provides additional
2877 information relevant to this notification.
2881 Consider how a configuration change notification might be described:
2883 node entityMIBTraps { oid entityMIB.2; };
2885 node entityMIBTrapPrefix { oid entityMIBTraps.0; };
2887 notification entConfigChange {
2888 oid entityMIBTrapPrefix.1;
2890 "An entConfigChange trap is sent when the value of
2891 entLastChangeTime changes. It can be utilized by an NMS
2892 to trigger logical/physical entity table maintenance
2893 polls. An agent must not generate more than one
2894 entConfigChange 'trap-event' in a five second period,
2895 where a 'trap-event' is the transmission of a single
2896 trap PDU to a list of trap destinations. If additional
2897 configuration changes occur within the five second
2898 'throttling' period then these trap-events should be
2899 suppressed by the agent. An NMS should periodically
2900 check the value of entLastChangeTime to detect any
2901 missed entConfigChange trap-events, e.g. due to
2902 throttling or transmission loss.";
2911 Strauss Expires August 15, 2000 [Page 52]
2913 Internet-Draft SMIng February 2000
2916 12. The group Statement
2918 The `group' statement is used to define a group of arbitrary nodes
2919 in the object identifier tree. It gets two arguments: a lower-case
2920 group identifier and a statement block that holds detailed group
2921 information in an obligatory order.
2923 Note that the primary application of groups are compliance
2924 statements, although they might be referred in other formal or
2927 See the `groupStatement' rule of the SMIng grammar (Appendix A) for
2928 the formal syntax of the `group' statement.
2930 12.1 The group's oid Statement
2932 The group's `oid' statement, which must be present, gets one
2933 argument which specifies the object identifier value that is
2934 assigned to this group.
2936 12.2 The group's members Statement
2938 The group's `members' statement, which must be present, gets one
2939 argument which specifies the list of nodes by their identifiers to
2940 be contained in this group. The list of nodes has to be
2941 comma-separated and enclosed in parenthesis.
2943 12.3 The group's status Statement
2945 The group's `status' statement, which need not be present, gets one
2946 argument which is used to specify whether this group definition is
2947 current or historic. The value `current' means that the definition
2948 is current and valid. The value `obsolete' means the definition is
2949 obsolete and the group should no longer be used. While the value
2950 `deprecated' also indicates an obsolete definition, it permits
2951 new/continued use of this group.
2953 If the `status' statement is omitted the status value `current' is
2956 12.4 The group's description Statement
2958 The group's `description' statement, which must be present, gets one
2959 argument which is used to specify a high-level textual description
2960 of this group. It is RECOMMENDED to include any relation to other
2967 Strauss Expires August 15, 2000 [Page 53]
2969 Internet-Draft SMIng February 2000
2972 12.5 The group's reference Statement
2974 The group's `reference' statement, which need not be present, gets
2975 one argument which is used to specify a textual cross-reference to
2976 some other document, either another module which defines related
2977 groups, or some other document which provides additional information
2978 relevant to this group.
2982 The snmpGroup, originally defined in [13], may be described as
2986 oid snmpMIBGroups.8;
2987 objects (snmpInPkts, snmpInBadVersions,
2989 snmpSilentDrops, snmpProxyDrops,
2990 snmpEnableAuthenTraps);
2992 "A collection of objects providing basic
2993 instrumentation and control of an agent.";
3023 Strauss Expires August 15, 2000 [Page 54]
3025 Internet-Draft SMIng February 2000
3028 13. The compliance Statement
3030 The `compliance' statement is used to define a set of compliance
3031 requirements, named a `compliance statement'. It gets two arguments:
3032 a lower-case compliance identifier and a statement block that holds
3033 detailed compliance information in an obligatory order.
3035 See the `complianceStatement' rule of the SMIng grammar (Appendix A)
3036 for the formal syntax of the `compliance' statement.
3038 13.1 The compliance's oid Statement
3040 The compliance's `oid' statement, which must be present, gets one
3041 argument which specifies the object identifier value that is
3042 assigned to this compliance statement.
3044 13.2 The compliance's status Statement
3046 The compliance's `status' statement, which need not be present, gets
3047 one argument which is used to specify whether this compliance
3048 statement is current or historic. The value `current' means that the
3049 definition is current and valid. The value `obsolete' means the
3050 definition is obsolete and no longer specifies a valid definition of
3051 conformance. While the value `deprecated' also indicates an
3052 obsolete definition, it permits new/continued use of the compliance
3055 If the `status' statement is omitted the status value `current' is
3058 13.3 The compliance's description Statement
3060 The compliance's `description' statement, which must be present,
3061 gets one argument which is used to specify a high-level textual
3062 description of this compliance statement.
3064 13.4 The compliance's reference Statement
3066 The compliance's `reference' statement, which need not be present,
3067 gets one argument which is used to specify a textual cross-reference
3068 to some other document, either another module which defines related
3069 compliance statements, or some other document which provides
3070 additional information relevant to this compliance statement.
3072 13.5 The compliance's mandatory Statement
3074 The compliance's `mandatory' statement, which need not be present,
3075 gets one argument which is used to specify a comma-separated list of
3076 one or more groups (Section 12) of objects and/or notifications
3079 Strauss Expires August 15, 2000 [Page 55]
3081 Internet-Draft SMIng February 2000
3084 enclosed in parenthesis. These groups are unconditionally mandatory
3087 If an agent claims compliance to a MIB module then it must implement
3088 each and every object and notification within each group listed the
3089 `mandatory' statement(s) of the compliance statement(s) of that
3092 13.6 The compliance's optional Statement
3094 The compliance's `optional' statement, which need not be present, is
3095 repeatedly used to name each group which is conditionally mandatory
3096 for compliance to the module. It can also be used to name
3097 unconditionally optional groups. A group named in an `optional'
3098 statement MUST be absent from the correspondent `mandatory'
3099 statement. The `optional' statement gets two arguments: a lower-case
3100 group identifier and a statement block that holds detailed
3101 compliance information on that group.
3103 Conditionally mandatory groups include those which are mandatory
3104 only if a particular protocol is implemented, or only if another
3105 group is implemented. The `description' statement specifies the
3106 conditions under which the group is conditionally mandatory.
3108 A group which is named in neither a `mandatory' statement nor an
3109 `optional' statement, is unconditionally optional for compliance to
3112 See the `optionalStatement' rule of the SMIng grammar (Appendix A)
3113 for the formal syntax of the `optional' statement.
3115 13.6.1 The optional's description Statement
3117 The optional's `description' statement, which must be present, gets
3118 one argument which is used to specify a high-level textual
3119 description of the conditions under which this group is
3120 conditionally mandatory or unconditionally optional.
3122 13.7 The compliance's refine Statement
3124 The compliance's `refine' statement, which need not be present, is
3125 repeatedly used to specify each object for which compliance has a
3126 refined requirement with respect to the module definition. The
3127 object must be present in one of the conformance groups named in the
3128 correspondent `mandatory' or `optional' statements. The `refine'
3129 statement gets two arguments: a lower-case identifier of a scalar or
3130 columnar object and a statement block that holds detailed refinement
3131 information on that object.
3135 Strauss Expires August 15, 2000 [Page 56]
3137 Internet-Draft SMIng February 2000
3140 See the `refineStatement' rule of the SMIng grammar (Appendix A) for
3141 the formal syntax of the `refine' statement.
3143 13.7.1 The refine's type Statement
3145 The refine's `type' statement, which need not be present, gets one
3146 argument that is used to provide a refined type for the
3147 correspondent object. Type restrictions may be applied by appending
3148 subtyping information according to the rules of the base type. See
3149 Section 3 for SMIng base types and their type restrictions.
3151 Note that if a `type' and a `writetype' statement are both present
3152 then this type only applies when instances of the correspondent
3155 13.7.2 The refine's writetype Statement
3157 The refine's `writetype' statement, which need not be present, gets
3158 one argument that is used to provide a refined type for the
3159 correspondent object, only when instances of that object are
3160 written. Type restrictions may be applied by appending subtyping
3161 information according to the rules of the base type. See Section 3
3162 for SMIng base types and their type restrictions.
3164 13.7.3 The refine's access Statement
3166 The refine's `access' statement, which need not be present, gets one
3167 argument that is used to specify the minimal level of access that
3168 the correspondent object must implement in the sense of its original
3169 `access' statement. Hence, the refine's `access' statement MUST NOT
3170 specify a greater level of access than is specified in the
3171 correspondent object definition.
3173 An implementation is compliant if the level of access it provides is
3174 greater or equal to the minimal level in the refine's `access'
3175 statement and less or equal to the maximal level in the object's
3178 13.7.4 The refine's description Statement
3180 The refine's `description' statement, which must be present, gets
3181 one argument which is used to specify a high-level textual
3182 description of the refined compliance requirement.
3186 The compliance statement contained in the SNMPv2-MIB, converted to
3191 Strauss Expires August 15, 2000 [Page 57]
3193 Internet-Draft SMIng February 2000
3196 compliance snmpBasicCompliance {
3197 oid snmpMIBCompliances.2;
3199 "The compliance statement for SNMPv2 entities which
3200 implement the SNMPv2 MIB.";
3202 mandatory (snmpGroup, snmpSetGroup, systemGroup,
3203 snmpBasicNotificationsGroup);
3205 optional snmpCommunityGroup {
3207 "This group is mandatory for SNMPv2 entities which
3208 support community-based authentication.";
3247 Strauss Expires August 15, 2000 [Page 58]
3249 Internet-Draft SMIng February 2000
3252 14. SMIng Core Modules
3254 MIB modules, either SMIv1, SMIv2 or SMIng, are built on top of some
3255 core definitions. These core definitions are imported from some
3256 "well-defined" core modules. In case of SMIng, there are two core
3259 1. IRTF-NMRG-SMING, which defines a special node, named
3260 `zeroDotZero' that may be used by objects of type
3261 `ObjectIdentifier' as a null value, and a core set of 18 nodes
3262 near the root of the object identifier tree. Only some of those
3263 core nodes are significant for the Internet management and have
3264 been described in Section 2.2.
3266 2. IRTF-NMRG-SMING-TYPES, which defines SMIng data types. Regarding
3267 to their origin, these types can be divided into two groups:
3268 those being ASN.1 application types defined as SMIv2 core types
3269 [2] and those being textual conventions in SMIv2 [3]. For use in
3270 SMIng, there is no need to care about these differences, though
3271 it might be useful in SNMP applications, to know that some types
3272 are distinguishable "on the wire" and others are not.
3274 3. IRTF-NMRG-SMING-EXTENSIONS, which defines proposed SMIng
3275 extensions. At this moment, there is only one extension, the
3276 `agentcaps' statement. See Section 16 for details on extensions.
3278 14.1 IRTF-NMRG-SMING
3280 module IRTF-NMRG-SMING {
3283 // $RCSfile: IRTF-NMRG-SMING,v $
3285 // $Author: strauss $
3286 // $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $
3289 organization "IRTF Network Management Research Group (NMRG),
3290 Network Management Group, TU Braunschweig";
3292 contact " Frank Strauss
3294 Postal: TU Braunschweig
3299 Phone: +49 531 391-3266
3300 EMail: strauss@ibr.cs.tu-bs.de";
3303 Strauss Expires August 15, 2000 [Page 59]
3305 Internet-Draft SMIng February 2000
3308 description "Core node definitions for SMIng.";
3312 description "SMIng grammar dropped module identity objects.";
3317 description "Initial Revision.";
3320 node ccitt { oid 0; };
3324 description "A value used for null identifiers.";
3327 node iso { oid 1; };
3328 node org { oid iso.3; };
3329 node dod { oid org.6; };
3330 node internet { oid dod.1; };
3331 node directory { oid internet.1; };
3332 node mgmt { oid internet.2; };
3333 node mib-2 { oid mgmt.1; };
3334 node transmission { oid mib-2.10; };
3335 node experimental { oid internet.3; };
3336 node private { oid internet.4; };
3337 node enterprises { oid private.1; };
3338 node security { oid internet.5; };
3339 node snmpV2 { oid internet.6; };
3340 node snmpDomains { oid snmpV2.1; };
3341 node snmpProxys { oid snmpV2.2; };
3342 node snmpModules { oid snmpV2.3; };
3344 node joint-iso-ccitt { oid 2; };
3348 14.2 IRTF-NMRG-SMING-TYPES
3350 module IRTF-NMRG-SMING-TYPES {
3353 // $RCSfile: IRTF-NMRG-SMING-TYPES,v $
3355 // $Author: strauss $
3356 // $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $
3359 Strauss Expires August 15, 2000 [Page 60]
3361 Internet-Draft SMIng February 2000
3366 organization "IRTF Network Management Research Group (NMRG),
3367 Network Management Group, TU Braunschweig";
3369 contact " Frank Strauss
3371 Postal: TU Braunschweig
3376 Phone: +49 531 391-3266
3377 EMail: strauss@ibr.cs.tu-bs.de";
3379 description "Core type definitions for SMIng.";
3383 description "SMIng grammar dropped module identity objects.";
3388 description "Initial Revision.";
3394 "The Gauge32 type represents a non-negative integer,
3395 which may increase or decrease, but shall never
3396 exceed a maximum value, nor fall below a minimum
3397 value. The maximum value can not be greater than
3398 2^32-1 (4294967295 decimal), and the minimum value
3399 can not be smaller than 0. The value of a Gauge32
3400 has its maximum value whenever the information
3401 being modeled is greater than or equal to its
3402 maximum value, and has its minimum value whenever
3403 the information being modeled is smaller than or
3404 equal to its minimum value. If the information
3405 being modeled subsequently decreases below
3406 (increases above) the maximum (minimum) value, the
3407 Gauge32 also decreases (increases). (Note that
3408 despite of the use of the term `latched' in the
3409 original definition of this type, it does not
3410 become `stuck' at its maximum or minimum value.)";
3412 "RFC 2578, Sections 2. and 7.1.7.";
3415 Strauss Expires August 15, 2000 [Page 61]
3417 Internet-Draft SMIng February 2000
3425 "The Counter32 type represents a non-negative integer
3426 which monotonically increases until it reaches a
3427 maximum value of 2^32-1 (4294967295 decimal), when it
3428 wraps around and starts increasing again from zero.
3430 Counters have no defined `initial' value, and thus, a
3431 single value of a Counter has (in general) no
3432 information content. Discontinuities in the
3433 monotonically increasing value normally occur at
3434 re-initialization of the management system, and at
3435 other times as specified in the description of an
3436 object using this type. If such other times can
3437 occur, for example, the creation of an object
3438 instance at times other than re-initialization, then
3439 a corresponding object should be defined, with an
3440 appropriate type, to indicate the last discontinuity.
3441 Examples of appropriate types include: TimeStamp,
3442 DateAndTime or TimeTicks (other types defined in this
3445 The value of the access statement for objects with a
3446 type value of Counter32 should be either `readonly'
3449 A default statement should not be used for objects
3450 with a type value of Counter32.";
3452 "RFC 2578, Sections 2. and 7.1.6.";
3458 "The Gauge64 type represents a non-negative integer,
3459 which may increase or decrease, but shall never
3460 exceed a maximum value, nor fall below a minimum
3461 value. The maximum value can not be greater than
3462 2^64-1 (18446744073709551615), and the minimum value
3463 can not be smaller than 0. The value of a Gauge64
3464 has its maximum value whenever the information
3465 being modeled is greater than or equal to its
3466 maximum value, and has its minimum value whenever
3467 the information being modeled is smaller than or
3468 equal to its minimum value. If the information
3471 Strauss Expires August 15, 2000 [Page 62]
3473 Internet-Draft SMIng February 2000
3476 being modeled subsequently decreases below
3477 (increases above) the maximum (minimum) value, the
3478 Gauge64 also decreases (increases). (Note that
3479 despite of the use of the term `latched' in the
3480 original definition of this type, it does not
3481 become `stuck' at its maximum or minimum value.)";
3487 "The Counter64 type represents a non-negative integer
3488 which monotonically increases until it reaches a
3489 maximum value of 2^64-1 (18446744073709551615), when
3490 it wraps around and starts increasing again from zero.
3492 Counters have no defined `initial' value, and thus, a
3493 single value of a Counter has (in general) no
3494 information content. Discontinuities in the
3495 monotonically increasing value normally occur at
3496 re-initialization of the management system, and at
3497 other times as specified in the description of an
3498 object using this type. If such other times can
3499 occur, for example, the creation of an object
3500 instance at times other than re-initialization, then
3501 a corresponding object should be defined, with an
3502 appropriate type, to indicate the last discontinuity.
3503 Examples of appropriate types include: TimeStamp,
3504 DateAndTime or TimeTicks (other types defined in this
3507 The value of the access statement for objects with a
3508 type value of Counter64 should be either `readonly'
3511 A default statement should not be used for objects
3512 with a type value of Counter64.";
3514 "RFC 2578, Sections 2. and 7.1.10.";
3520 "The Opaque type is provided solely for
3521 backward-compatibility, and shall not be used for
3522 newly-defined object types.
3524 The Opaque type supports the capability to pass
3527 Strauss Expires August 15, 2000 [Page 63]
3529 Internet-Draft SMIng February 2000
3532 arbitrary ASN.1 syntax. A value is encoded using
3533 the ASN.1 Basic Encoding Rules into a string of
3534 octets. This, in turn, is encoded as an
3535 OctetString, in effect `double-wrapping' the
3536 original ASN.1 value.
3538 Note that a conforming implementation need only be
3539 able to accept and recognize opaquely-encoded data.
3540 It need not be able to unwrap the data and then
3541 interpret its contents.
3543 A requirement on `standard' MIB modules is that no
3544 object may have a type value of Opaque.";
3546 "RFC 2578, Sections 2. and 7.1.9.";
3550 type OctetString (4);
3553 "******* THIS TYPE DEFINITION IS DEPRECATED *******
3555 The IpAddress type represents a 32-bit internet
3556 IPv4 address. It is represented as an OctetString
3557 of length 4, in network byte-order.
3559 Note that the IpAddress type is present for
3560 historical reasons. IPv4 and IPv6 addresses should
3561 be represented using the IpAddr type. Generic
3562 Network addresses should be represented using a
3563 pair of TDomain and TAddress types (all defined in
3566 "RFC 2578, Sections 2. and 7.1.5.";
3572 "The TimeTicks type represents a non-negative
3573 integer which represents the time, modulo 2^32
3574 (4294967296 decimal), in hundredths of a second
3575 between two epochs. When objects are defined which
3576 use this type, the description of the object
3577 identifies both of the reference epochs.
3579 For example, the TimeStamp type (defined in this
3580 module) is based on the TimeTicks type.
3583 Strauss Expires August 15, 2000 [Page 64]
3585 Internet-Draft SMIng February 2000
3588 With a TimeStamp, the first reference epoch is
3589 defined as the time when SNMPv2-MIB::sysUpTime was
3590 zero, and the second reference epoch is defined as
3591 the current value of sysUpTime.
3593 The TimeTicks type should not be sub-typed.";
3595 "RFC 2578, Sections 2. and 7.1.8.";
3599 // The following type definitions are plain
3600 // conversions of the textual conventions from
3601 // the SNMPv2-TC module (RFC 2579).
3604 typedef DisplayString {
3605 type OctetString (0..255);
3608 "Represents textual information taken from the NVT ASCII
3609 character set, as defined in pages 4, 10-11 of RFC 854.
3611 To summarize RFC 854, the NVT ASCII repertoire specifies:
3613 - the use of character codes 0-127 (decimal)
3615 - the graphics characters (32-126) are interpreted as
3618 - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
3619 meanings specified in RFC 854
3621 - the other 25 codes have no standard interpretation
3623 - the sequence 'CR LF' means newline
3625 - the sequence 'CR NUL' means carriage-return
3627 - an 'LF' not preceded by a 'CR' means moving to the
3628 same column on the next line.
3630 - the sequence 'CR x' for any x other than LF or NUL is
3631 illegal. (Note that this also means that a string may
3632 end with either 'CR LF' or 'CR NUL', but not with CR.)
3634 Any object defined using this syntax may not exceed 255
3635 characters in length.";
3639 Strauss Expires August 15, 2000 [Page 65]
3641 Internet-Draft SMIng February 2000
3644 typedef PhysAddress {
3648 "Represents media- or physical-level addresses.";
3651 typedef MacAddress {
3652 type OctetString (6);
3655 "Represents an 802 MAC address represented in the
3656 `canonical' order defined by IEEE 802.1a, i.e., as if it
3657 were transmitted least significant bit first, even though
3658 802.5 (in contrast to other 802.x protocols) requires MAC
3659 addresses to be transmitted most significant bit first.";
3662 typedef TruthValue {
3663 type Enumeration (true(1), false(2));
3665 "Represents a boolean value.";
3668 typedef TestAndIncr {
3669 type Integer32 (0..2147483647);
3671 "Represents integer-valued information used for atomic
3672 operations. When the management protocol is used to specify
3673 that an object instance having this syntax is to be
3674 modified, the new value supplied via the management protocol
3675 must precisely match the value presently held by the
3676 instance. If not, the management protocol set operation
3677 fails with an error of `inconsistentValue'. Otherwise, if
3678 the current value is the maximum value of 2^31-1 (2147483647
3679 decimal), then the value held by the instance is wrapped to
3680 zero; otherwise, the value held by the instance is
3681 incremented by one. (Note that regardless of whether the
3682 management protocol set operation succeeds, the variable-
3683 binding in the request and response PDUs are identical.)
3685 The value of the ACCESS clause for objects having this
3686 syntax is either `read-write' or `read-create'. When an
3687 instance of a columnar object having this syntax is created,
3688 any value may be supplied via the management protocol.
3690 When the network management portion of the system is re-
3691 initialized, the value of every object instance having this
3692 syntax must either be incremented from its value prior to
3695 Strauss Expires August 15, 2000 [Page 66]
3697 Internet-Draft SMIng February 2000
3700 the re-initialization, or (if the value prior to the re-
3701 initialization is unknown) be set to a pseudo-randomly
3705 typedef AutonomousType {
3706 type ObjectIdentifier;
3708 "Represents an independently extensible type identification
3709 value. It may, for example, indicate a particular sub-tree
3710 with further MIB definitions, or define a particular type of
3711 protocol or hardware.";
3714 typedef InstancePointer {
3715 type ObjectIdentifier;
3718 "A pointer to either a specific instance of a MIB object or
3719 a conceptual row of a MIB table in the managed device. In
3720 the latter case, by convention, it is the name of the
3721 particular instance of the first accessible columnar object
3722 in the conceptual row.
3724 The two uses of this textual convention are replaced by
3725 VariablePointer and RowPointer, respectively.";
3728 typedef VariablePointer {
3729 type ObjectIdentifier;
3731 "A pointer to a specific object instance. For example,
3732 sysContact.0 or ifInOctets.3.";
3735 typedef RowPointer {
3736 type ObjectIdentifier;
3738 "Represents a pointer to a conceptual row. The value is the
3739 name of the instance of the first accessible columnar object
3740 in the conceptual row.
3742 For example, ifIndex.3 would point to the 3rd row in the
3743 ifTable (note that if ifIndex were not-accessible, then
3744 ifDescr.3 would be used instead).";
3748 type Enumeration (active(1), notInService(2),
3751 Strauss Expires August 15, 2000 [Page 67]
3753 Internet-Draft SMIng February 2000
3756 notReady(3), createAndGo(4),
3757 createAndWait(5), destroy(6));
3759 "The RowStatus textual convention is used to manage the
3760 creation and deletion of conceptual rows, and is used as the
3761 value of the SYNTAX clause for the status column of a
3762 conceptual row (as described in Section 7.7.1 of [2].)
3764 The status column has six defined values:
3766 - `active', which indicates that the conceptual row is
3767 available for use by the managed device;
3769 - `notInService', which indicates that the conceptual
3770 row exists in the agent, but is unavailable for use by
3771 the managed device (see NOTE below);
3773 - `notReady', which indicates that the conceptual row
3774 exists in the agent, but is missing information
3775 necessary in order to be available for use by the
3778 - `createAndGo', which is supplied by a management
3779 station wishing to create a new instance of a
3780 conceptual row and to have its status automatically set
3781 to active, making it available for use by the managed
3784 - `createAndWait', which is supplied by a management
3785 station wishing to create a new instance of a
3786 conceptual row (but not make it available for use by
3787 the managed device); and,
3789 - `destroy', which is supplied by a management station
3790 wishing to delete all of the instances associated with
3791 an existing conceptual row.
3793 Whereas five of the six values (all except `notReady') may
3794 be specified in a management protocol set operation, only
3795 three values will be returned in response to a management
3796 protocol retrieval operation: `notReady', `notInService' or
3797 `active'. That is, when queried, an existing conceptual row
3798 has only three states: it is either available for use by the
3799 managed device (the status column has value `active'); it is
3800 not available for use by the managed device, though the
3803 agent has sufficient information to make it so (the status
3804 column has value `notInService'); or, it is not available
3807 Strauss Expires August 15, 2000 [Page 68]
3809 Internet-Draft SMIng February 2000
3812 for use by the managed device, and an attempt to make it so
3813 would fail because the agent has insufficient information
3814 (the state column has value `notReady').
3818 This textual convention may be used for a MIB table,
3819 irrespective of whether the values of that table's
3820 conceptual rows are able to be modified while it is
3821 active, or whether its conceptual rows must be taken
3822 out of service in order to be modified. That is, it is
3823 the responsibility of the DESCRIPTION clause of the
3824 status column to specify whether the status column must
3825 not be `active' in order for the value of some other
3826 column of the same conceptual row to be modified. If
3827 such a specification is made, affected columns may be
3828 changed by an SNMP set PDU if the RowStatus would not
3829 be equal to `active' either immediately before or after
3830 processing the PDU. In other words, if the PDU also
3831 contained a varbind that would change the RowStatus
3832 value, the column in question may be changed if the
3833 RowStatus was not equal to `active' as the PDU was
3834 received, or if the varbind sets the status to a value
3835 other than 'active'.
3837 Also note that whenever any elements of a row exist, the
3838 RowStatus column must also exist.
3841 To summarize the effect of having a conceptual row with a
3842 status column having a SYNTAX clause value of RowStatus,
3843 consider the following state diagram:
3846 +--------------+-----------+-------------+-------------
3848 | |status col.|status column|
3849 |status column | is | is |status column
3850 ACTION |does not exist| notReady | notInService| is active
3851 --------------+--------------+-----------+-------------+-------------
3852 set status |noError ->D|inconsist- |inconsistent-|inconsistent-
3853 column to | or | entValue| Value| Value
3854 createAndGo |inconsistent- | | |
3856 --------------+--------------+-----------+-------------+-------------
3857 set status |noError see 1|inconsist- |inconsistent-|inconsistent-
3858 column to | or | entValue| Value| Value
3859 createAndWait |wrongValue | | |
3860 --------------+--------------+-----------+-------------+-------------
3863 Strauss Expires August 15, 2000 [Page 69]
3865 Internet-Draft SMIng February 2000
3868 set status |inconsistent- |inconsist- |noError |noError
3869 column to | Value| entValue| |
3873 | |see 2 ->D|see 8 ->D| ->D
3874 --------------+--------------+-----------+-------------+-------------
3875 set status |inconsistent- |inconsist- |noError |noError ->C
3876 column to | Value| entValue| |
3877 notInService | | | |
3880 | |see 3 ->C| ->C|see 6
3881 --------------+--------------+-----------+-------------+-------------
3882 set status |noError |noError |noError |noError ->A
3883 column to | | | | or
3884 destroy | ->A| ->A| ->A|see 7
3885 --------------+--------------+-----------+-------------+-------------
3886 set any other |see 4 |noError |noError |see 5
3887 column to some| | | |
3888 value | | see 1| ->C| ->D
3889 --------------+--------------+-----------+-------------+-------------
3891 (1) goto B or C, depending on information available to the
3896 (2) if other variable bindings included in the same PDU,
3897 provide values for all columns which are missing but
3898 required, then return noError and goto D.
3900 (3) if other variable bindings included in the same PDU,
3901 provide values for all columns which are missing but
3902 required, then return noError and goto C.
3904 (4) at the discretion of the agent, the return value may be
3907 inconsistentName: because the agent does not choose to
3908 create such an instance when the corresponding
3909 RowStatus instance does not exist, or
3911 inconsistentValue: if the supplied value is
3912 inconsistent with the state of some other MIB object's
3915 noError: because the agent chooses to create the
3919 Strauss Expires August 15, 2000 [Page 70]
3921 Internet-Draft SMIng February 2000
3924 If noError is returned, then the instance of the status
3925 column must also be created, and the new state is B or C,
3926 depending on the information available to the agent. If
3927 inconsistentName or inconsistentValue is returned, the row
3930 (5) depending on the MIB definition for the column/table,
3931 either noError or inconsistentValue may be returned.
3933 (6) the return value can indicate one of the following
3936 wrongValue: because the agent does not support
3939 inconsistentValue: because the agent is unable to take
3940 the row out of service at this time, perhaps because it
3941 is in use and cannot be de-activated.
3943 (7) the return value can indicate the following error:
3946 inconsistentValue: because the agent is unable to
3947 remove the row at this time, perhaps because it is in
3948 use and cannot be de-activated.
3950 NOTE: Other processing of the set request may result in a
3951 response other than noError being returned, e.g.,
3952 wrongValue, noCreation, etc.
3954 Conceptual Row Creation
3956 There are four potential interactions when creating a
3957 conceptual row: selecting an instance-identifier which is
3958 not in use; creating the conceptual row; initializing any
3959 objects for which the agent does not supply a default; and,
3960 making the conceptual row available for use by the managed
3963 Interaction 1: Selecting an Instance-Identifier
3965 The algorithm used to select an instance-identifier varies
3966 for each conceptual row. In some cases, the instance-
3967 identifier is semantically significant, e.g., the
3968 destination address of a route, and a management station
3969 selects the instance-identifier according to the semantics.
3971 In other cases, the instance-identifier is used solely to
3972 distinguish conceptual rows, and a management station
3975 Strauss Expires August 15, 2000 [Page 71]
3977 Internet-Draft SMIng February 2000
3980 without specific knowledge of the conceptual row might
3981 examine the instances present in order to determine an
3982 unused instance-identifier. (This approach may be used, but
3983 it is often highly sub-optimal; however, it is also a
3984 questionable practice for a naive management station to
3985 attempt conceptual row creation.)
3987 Alternately, the MIB module which defines the conceptual row
3988 might provide one or more objects which provide assistance
3989 in determining an unused instance-identifier. For example,
3990 if the conceptual row is indexed by an integer-value, then
3991 an object having an integer-valued SYNTAX clause might be
3992 defined for such a purpose, allowing a management station to
3993 issue a management protocol retrieval operation. In order
3994 to avoid unnecessary collisions between competing management
3995 stations, `adjacent' retrievals of this object should be
3999 Finally, the management station could select a pseudo-random
4000 number to use as the index. In the event that this index
4001 was already in use and an inconsistentValue was returned in
4002 response to the management protocol set operation, the
4003 management station should simply select a new pseudo-random
4004 number and retry the operation.
4006 A MIB designer should choose between the two latter
4007 algorithms based on the size of the table (and therefore the
4008 efficiency of each algorithm). For tables in which a large
4009 number of entries are expected, it is recommended that a MIB
4010 object be defined that returns an acceptable index for
4011 creation. For tables with small numbers of entries, it is
4012 recommended that the latter pseudo-random index mechanism be
4015 Interaction 2: Creating the Conceptual Row
4017 Once an unused instance-identifier has been selected, the
4018 management station determines if it wishes to create and
4019 activate the conceptual row in one transaction or in a
4020 negotiated set of interactions.
4022 Interaction 2a: Creating and Activating the Conceptual Row
4024 The management station must first determine the column
4025 requirements, i.e., it must determine those columns for
4026 which it must or must not provide values. Depending on the
4027 complexity of the table and the management station's
4028 knowledge of the agent's capabilities, this determination
4031 Strauss Expires August 15, 2000 [Page 72]
4033 Internet-Draft SMIng February 2000
4036 can be made locally by the management station. Alternately,
4037 the management station issues a management protocol get
4038 operation to examine all columns in the conceptual row that
4039 it wishes to create. In response, for each column, there
4040 are three possible outcomes:
4042 - a value is returned, indicating that some other
4043 management station has already created this conceptual
4044 row. We return to interaction 1.
4047 - the exception `noSuchInstance' is returned,
4048 indicating that the agent implements the object-type
4049 associated with this column, and that this column in at
4050 least one conceptual row would be accessible in the MIB
4051 view used by the retrieval were it to exist. For those
4052 columns to which the agent provides read-create access,
4053 the `noSuchInstance' exception tells the management
4054 station that it should supply a value for this column
4055 when the conceptual row is to be created.
4057 - the exception `noSuchObject' is returned, indicating
4058 that the agent does not implement the object-type
4059 associated with this column or that there is no
4060 conceptual row for which this column would be
4061 accessible in the MIB view used by the retrieval. As
4062 such, the management station can not issue any
4063 management protocol set operations to create an
4064 instance of this column.
4066 Once the column requirements have been determined, a
4067 management protocol set operation is accordingly issued.
4068 This operation also sets the new instance of the status
4069 column to `createAndGo'.
4071 When the agent processes the set operation, it verifies that
4072 it has sufficient information to make the conceptual row
4073 available for use by the managed device. The information
4074 available to the agent is provided by two sources: the
4075 management protocol set operation which creates the
4076 conceptual row, and, implementation-specific defaults
4077 supplied by the agent (note that an agent must provide
4078 implementation-specific defaults for at least those objects
4079 which it implements as read-only). If there is sufficient
4080 information available, then the conceptual row is created, a
4081 `noError' response is returned, the status column is set to
4082 `active', and no further interactions are necessary (i.e.,
4083 interactions 3 and 4 are skipped). If there is insufficient
4084 information, then the conceptual row is not created, and the
4087 Strauss Expires August 15, 2000 [Page 73]
4089 Internet-Draft SMIng February 2000
4092 set operation fails with an error of `inconsistentValue'.
4093 On this error, the management station can issue a management
4094 protocol retrieval operation to determine if this was
4095 because it failed to specify a value for a required column,
4096 or, because the selected instance of the status column
4097 already existed. In the latter case, we return to
4098 interaction 1. In the former case, the management station
4101 can re-issue the set operation with the additional
4102 information, or begin interaction 2 again using
4103 `createAndWait' in order to negotiate creation of the
4108 Regardless of the method used to determine the column
4109 requirements, it is possible that the management
4110 station might deem a column necessary when, in fact,
4111 the agent will not allow that particular columnar
4112 instance to be created or written. In this case, the
4113 management protocol set operation will fail with an
4114 error such as `noCreation' or `notWritable'. In this
4115 case, the management station decides whether it needs
4116 to be able to set a value for that particular columnar
4117 instance. If not, the management station re-issues the
4118 management protocol set operation, but without setting
4119 a value for that particular columnar instance;
4120 otherwise, the management station aborts the row
4124 Interaction 2b: Negotiating the Creation of the Conceptual
4127 The management station issues a management protocol set
4128 operation which sets the desired instance of the status
4129 column to `createAndWait'. If the agent is unwilling to
4130 process a request of this sort, the set operation fails with
4131 an error of `wrongValue'. (As a consequence, such an agent
4132 must be prepared to accept a single management protocol set
4133 operation, i.e., interaction 2a above, containing all of the
4134 columns indicated by its column requirements.) Otherwise,
4135 the conceptual row is created, a `noError' response is
4136 returned, and the status column is immediately set to either
4137 `notInService' or `notReady', depending on whether it has
4138 sufficient information to make the conceptual row available
4139 for use by the managed device. If there is sufficient
4140 information available, then the status column is set to
4143 Strauss Expires August 15, 2000 [Page 74]
4145 Internet-Draft SMIng February 2000
4148 `notInService'; otherwise, if there is insufficient
4149 information, then the status column is set to `notReady'.
4150 Regardless, we proceed to interaction 3.
4152 Interaction 3: Initializing non-defaulted Objects
4154 The management station must now determine the column
4155 requirements. It issues a management protocol get operation
4156 to examine all columns in the created conceptual row. In
4157 the response, for each column, there are three possible
4160 - a value is returned, indicating that the agent
4161 implements the object-type associated with this column
4162 and had sufficient information to provide a value. For
4163 those columns to which the agent provides read-create
4164 access (and for which the agent allows their values to
4165 be changed after their creation), a value return tells
4166 the management station that it may issue additional
4167 management protocol set operations, if it desires, in
4168 order to change the value associated with this column.
4171 - the exception `noSuchInstance' is returned,
4172 indicating that the agent implements the object-type
4173 associated with this column, and that this column in at
4174 least one conceptual row would be accessible in the MIB
4175 view used by the retrieval were it to exist. However,
4176 the agent does not have sufficient information to
4177 provide a value, and until a value is provided, the
4178 conceptual row may not be made available for use by the
4179 managed device. For those columns to which the agent
4180 provides read-create access, the `noSuchInstance'
4181 exception tells the management station that it must
4182 issue additional management protocol set operations, in
4183 order to provide a value associated with this column.
4185 - the exception `noSuchObject' is returned, indicating
4186 that the agent does not implement the object-type
4187 associated with this column or that there is no
4188 conceptual row for which this column would be
4189 accessible in the MIB view used by the retrieval. As
4190 such, the management station can not issue any
4191 management protocol set operations to create an
4192 instance of this column.
4194 If the value associated with the status column is
4195 `notReady', then the management station must first deal with
4196 all `noSuchInstance' columns, if any. Having done so, the
4199 Strauss Expires August 15, 2000 [Page 75]
4201 Internet-Draft SMIng February 2000
4204 value of the status column becomes `notInService', and we
4205 proceed to interaction 4.
4207 Interaction 4: Making the Conceptual Row Available
4209 Once the management station is satisfied with the values
4210 associated with the columns of the conceptual row, it issues
4211 a management protocol set operation to set the status column
4212 to `active'. If the agent has sufficient information to
4213 make the conceptual row available for use by the managed
4214 device, the management protocol set operation succeeds (a
4215 `noError' response is returned). Otherwise, the management
4216 protocol set operation fails with an error of
4217 `inconsistentValue'.
4222 A conceptual row having a status column with value
4223 `notInService' or `notReady' is unavailable to the
4224 managed device. As such, it is possible for the
4225 managed device to create its own instances during the
4226 time between the management protocol set operation
4227 which sets the status column to `createAndWait' and the
4228 management protocol set operation which sets the status
4229 column to `active'. In this case, when the management
4230 protocol set operation is issued to set the status
4231 column to `active', the values held in the agent
4232 supersede those used by the managed device.
4234 If the management station is prevented from setting the
4235 status column to `active' (e.g., due to management station
4236 or network failure) the conceptual row will be left in the
4237 `notInService' or `notReady' state, consuming resources
4238 indefinitely. The agent must detect conceptual rows that
4239 have been in either state for an abnormally long period of
4240 time and remove them. It is the responsibility of the
4241 DESCRIPTION clause of the status column to indicate what an
4242 abnormally long period of time would be. This period of
4243 time should be long enough to allow for human response time
4244 (including `think time') between the creation of the
4245 conceptual row and the setting of the status to `active'.
4246 In the absence of such information in the DESCRIPTION
4248 it is suggested that this period be approximately 5 minutes
4249 in length. This removal action applies not only to newly-
4250 created rows, but also to previously active rows which are
4251 set to, and left in, the notInService state for a prolonged
4252 period exceeding that which is considered normal for such a
4255 Strauss Expires August 15, 2000 [Page 76]
4257 Internet-Draft SMIng February 2000
4263 Conceptual Row Suspension
4265 When a conceptual row is `active', the management station
4266 may issue a management protocol set operation which sets the
4267 instance of the status column to `notInService'. If the
4268 agent is unwilling to do so, the set operation fails with an
4269 error of `wrongValue' or `inconsistentValue'.
4270 Otherwise, the conceptual row is taken out of service, and a
4271 `noError' response is returned. It is the responsibility of
4272 the DESCRIPTION clause of the status column to indicate
4273 under what circumstances the status column should be taken
4274 out of service (e.g., in order for the value of some other
4275 column of the same conceptual row to be modified).
4277 Conceptual Row Deletion
4279 For deletion of conceptual rows, a management protocol set
4280 operation is issued which sets the instance of the status
4281 column to `destroy'. This request may be made regardless of
4282 the current value of the status column (e.g., it is possible
4283 to delete conceptual rows which are either `notReady',
4284 `notInService' or `active'.) If the operation succeeds, then
4285 all instances associated with the conceptual row are
4286 immediately removed.";
4292 "The value of the sysUpTime object at which a specific
4293 occurrence happened. The specific occurrence must be
4294 defined in the description of any object defined using this
4295 type. When the specific occurrence occurred prior to the
4296 last time sysUpTime was zero, then the TimeStamp value is
4297 zero. Note that this requires all TimeStamp values to be
4298 reset to zero when the value of sysUpTime reaches 497+ days
4299 and wraps around to zero.";
4302 typedef TimeInterval {
4303 type Integer32 (0..2147483647);
4305 "A period of time, measured in units of 0.01 seconds.";
4308 typedef DateAndTime {
4311 Strauss Expires August 15, 2000 [Page 77]
4313 Internet-Draft SMIng February 2000
4316 type OctetString (8 | 11);
4317 format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
4319 "A date-time specification.
4321 field octets contents range
4322 ----- ------ -------- -----
4323 1 1-2 year* 0..65536
4329 (use 60 for leap-second)
4330 7 8 deci-seconds 0..9
4331 8 9 direction from UTC '+' / '-'
4332 9 10 hours from UTC* 0..13
4333 10 11 minutes from UTC 0..59
4336 - the value of year is in big-endian encoding
4337 - daylight saving time in New Zealand is +13
4339 For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
4342 1992-5-26,13:30:15.0,-4:0
4344 Note that if only local time is known, then timezone
4345 information (fields 8-10) is not present.";
4348 typedef StorageType {
4349 type Enumeration (other(1), volatile(2),
4350 nonVolatile(3), permanent(4),
4353 "Describes the memory realization of a conceptual row. A
4354 row which is volatile(2) is lost upon reboot. A row which
4355 is either nonVolatile(3), permanent(4) or readOnly(5), is
4356 backed up by stable storage. A row which is permanent(4)
4357 can be changed but not deleted. A row which is readOnly(5)
4358 cannot be changed nor deleted.
4360 If the value of an object with this syntax is either
4361 permanent(4) or readOnly(5), it cannot be modified.
4362 Conversely, if the value is either other(1), volatile(2) or
4363 nonVolatile(3), it cannot be modified to be permanent(4) or
4364 readOnly(5). (All illegal modifications result in a
4367 Strauss Expires August 15, 2000 [Page 78]
4369 Internet-Draft SMIng February 2000
4372 'wrongValue' error.)
4374 Every usage of this textual convention is required to
4375 specify the columnar objects which a permanent(4) row must
4376 at a minimum allow to be writable.";
4380 type ObjectIdentifier;
4382 "Denotes a kind of transport service.
4384 Some possible values, such as snmpUDPDomain, are defined in
4385 'Transport Mappings for Version 2 of the Simple Network
4386 Management Protocol (SNMPv2)'.";
4390 type OctetString (1..255);
4392 "Denotes a transport service address.
4394 For snmpUDPDomain, a TAddress is 6 octets long, the initial
4395 4 octets containing the IP-address in network-byte order and
4396 the last 2 containing the UDP port in network-byte order.
4397 Cosult 'Transport Mappings for Version 2 of the Simple
4398 Network Management Protocol (SNMPv2)' for further
4399 information on snmpUDPDomain.";
4404 14.3 IRTF-NMRG-SMING-EXTENSIONS
4406 module IRTF-NMRG-SMING-EXTENSIONS {
4409 // $RCSfile: IRTF-NMRG-SMING-EXTENSIONS,v $
4411 // $Author: strauss $
4412 // $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $
4415 organization "IRTF Network Management Research Group (NMRG),
4416 Network Management Group, TU Braunschweig";
4418 contact " Frank Strauss
4420 Postal: TU Braunschweig
4423 Strauss Expires August 15, 2000 [Page 79]
4425 Internet-Draft SMIng February 2000
4432 Phone: +49 531 391-3266
4433 EMail: strauss@ibr.cs.tu-bs.de";
4435 description "Core extension definitions for SMIng.";
4439 description "SMIng grammar dropped module identity objects.";
4444 description "Initial Revision.";
4447 extension agentcaps {
4450 "The agentcaps extension statement is used to describe
4451 an agent's deviation from the compliance statements
4452 of the modules it implements. It is designed to be
4453 compatible with the SMIv2 AGENT-CAPABILITIES macro.
4455 The agentcaps extension statement should only be used
4456 in the statement body of a module that does not
4457 contain any other type or node definitions that do not
4458 correspond to an agent implementation.";
4460 "RFC 2580, Section 6 describes the SMIv2
4461 compatible AGENT-CAPABILITIES macro.";
4463 "agentcapsStatement = 'agentcaps' sep lcIdentifier
4465 oidStatement stmtsep
4466 releaseStatement stmtsep
4467 *1(statusStatement stmtsep)
4468 descriptionStatement stmtsep
4469 *1(referenceStatement stmtsep)
4470 *(includesStatement stmtsep)
4473 includesStatement = 'includes' sep qlcIdentifier
4475 *(variationStatement stmtsep)
4479 Strauss Expires August 15, 2000 [Page 80]
4481 Internet-Draft SMIng February 2000
4484 variationStatement = 'variation' sep qlcIdentifier
4486 typeStatement stmtsep
4487 writetypeStatement stmtsep
4488 accessStatement stmtsep
4489 createStatement stmtsep
4535 Strauss Expires August 15, 2000 [Page 81]
4537 Internet-Draft SMIng February 2000
4540 15. Extending a Module
4542 As experience is gained with a module, it may be desirable to revise
4543 that module. However, changes are not allowed if they have any
4544 potential to cause interoperability problems between an
4545 implementation using an original specification and an implementation
4546 using an updated specification(s).
4548 For any change, some statements near the top of the module MUST be
4549 updated to include information about the revision: specifically, a
4550 new `revision' statement (Section 5.6) must be included in front of
4551 the `revision' statements. Furthermore, any necessary changes MUST
4552 be applied to other statements, including the `organization' and
4553 `contact' statements (Section 5.2, Section 5.3).
4555 Note that any definition contained in a module is available to be
4556 imported by any other module, and is referenced in an `import'
4557 statement via the module name. Thus, a module name MUST NOT be
4558 changed. Specifically, the module name (e.g., `FIZBIN-MIB' in the
4559 example of Section 5.8) MUST NOT be changed when revising a module
4560 (except to correct typographical errors), and definitions MUST NOT
4561 be moved from one module to another.
4563 Also note, that obsolete definitions MUST NOT be removed from
4564 modules since their descriptors may still be referenced by other
4565 modules, and the object identifiers used to name them MUST never be
4568 A definition may be revised in any of the following ways:
4570 o In `typedef', `scalar' and `column' statement blocks, a `type'
4571 statement containing an `Enumeration' or `Bits' type may have new
4572 named numbers added.
4574 o In `typedef', `scalar' and `column' statement blocks, the value
4575 of a `type' statement may be replaced by another type if the new
4576 type is derived (directly or indirectly) from the same base type,
4577 has the same set of values, and has identical semantics.
4579 o In any statement block, a `status' statement value of `current'
4580 (or a missing `status' statement) may be revised as `deprecated'
4581 or `obsolete'. Similarly, a `status' statement value of
4582 `deprecated' may be revised as `obsolete'. When making such a
4583 change, the `description' statement SHOULD be updated to explain
4586 o In `typedef', `scalar' and `column' statement blocks, a `default'
4587 statement may be added or updated.
4591 Strauss Expires August 15, 2000 [Page 82]
4593 Internet-Draft SMIng February 2000
4596 o In any statement block, a `reference' statement may be added or
4599 o In `typedef', `scalar' and `column' statement blocks, a `units'
4600 statement may be added.
4602 o A row may be augmented by adding new columnar objects (`column'
4603 statements) at the end of the row's statement block.
4605 o In any statement block, clarifications and additional information
4606 may be included in the `description' statement.
4608 o Entirely new extensions, types, nodes, scalar objects, tables,
4609 groups, or compliance statements may be defined, using previously
4610 unassigned identifiers and object identifier values.
4612 Otherwise, if the semantics of any previous definition are changed
4613 (i.e., if a non-editorial change is made to any definition other
4614 than those specifically allowed above), then the `oid' statement
4615 value associated with that object MUST also be changed.
4617 Note that changing the identifier associated with an existing object
4618 is considered a semantic change, as these strings may be used in an
4647 Strauss Expires August 15, 2000 [Page 83]
4649 Internet-Draft SMIng February 2000
4652 16. SMIng Language Extensibility
4654 While SMIng has a well defined set of statements (Section 5 through
4655 Section 13) that are used to specify those aspects of management
4656 information commonly regarded as necessary, there may be further
4657 information, people wish to express. To describe additional
4658 information informally in description statements has the
4659 disadvantage, that this information cannot be parsed by any program.
4661 SMIng allows modules to include statements that are unknown to a
4662 parser but fulfill some core grammar rules (Section 4.2).
4663 Furthermore, additional statements may be defined by the `extension'
4664 statement (Section 6). Extensions can be used in the local module or
4665 in other modules, that import the extension. This has some
4668 o A parser can differentiate between statements known as extensions
4669 and unknown statements. This enables the parser to complain about
4670 unknown statements, e.g. due to typos.
4672 o If an extension's definition contains a formal ABNF grammar
4673 definition and a parser is able to interpret this ABNF
4674 definition, this enables the parser also to complain about wrong
4675 usage of an extension.
4677 o Since, there might be some common need for extensions, there is a
4678 relatively high probability of extension name collisions
4679 originated by different organizations, as long as there is no
4680 standardized extension for that purpose. The requirement to
4681 explicitly import extension statements allows to distinguish
4684 o The supported extensions of an SMIng implementation, e.g. a MIB
4685 compiler, can be clearly expressed.
4687 The only formal effect of an extension statement definition is to
4688 declare its existence and its status, and optionally its ABNF
4689 grammar. All additional aspects SHOULD be described in the
4690 `description' statement:
4692 o The detailed semantics of the new statement SHOULD be described.
4694 o The contexts in which the new statement can be used, SHOULD be
4695 described, e.g., a new statement may be designed to be used only
4696 in the statement block of a module, but not in other nested
4697 statement blocks. Others may be applicable in multiple contexts.
4698 In addition, the point in the sequence of an obligatory order of
4699 other statements, where the new statement may be inserted, might
4703 Strauss Expires August 15, 2000 [Page 84]
4705 Internet-Draft SMIng February 2000
4708 o The circumstances that make the new statement mandatory or
4709 optional SHOULD be described.
4711 o The syntax of the new statement SHOULD at least be described
4712 informally, if not supplied formally in an `abnf' statement.
4714 o It might be reasonable to give some suggestions under which
4715 conditions the implementation of the new statement is adequate
4716 and how it could be integrated into existent implementations.
4718 Some possible extension applications might be:
4720 o Agent capabilities statements, that allow to describe an agent
4721 implemention's deviation from the compliance statements of the
4722 modules they implement. SMIv2 has a regular AGENT-CAPABILITIES
4723 construct [4], though it's rarely used. That's why it's not a
4724 common SMIng statement. Instead, it is defined as an `agentcaps'
4725 extension statement in the module IRTF-NMRG-SMING-EXTENSIONS
4728 o Inlined annotations to definitions. E.g., a vendor may wish to
4729 describe additional information to object definitions in private
4730 modules. An example are severity levels of notifications in the
4731 statement block of a `notification' statement.
4733 o Arbitrary annotations to external definitions. E.g., a vendor may
4734 wish to describe additional information to object definitions in
4735 a "standard" module. This allows a vendor to implement "standard"
4736 modules as well as additional private features, without redundant
4737 MIB definitions, but on top of "standard" MIB definitions.
4759 Strauss Expires August 15, 2000 [Page 85]
4761 Internet-Draft SMIng February 2000
4764 17. Module Conversions
4766 17.1 Converting SMIv2 to SMIng
4768 Conversions of SMIv2 modules to SMIng are feasible. The only SMIv2
4769 construct that cannot be mapped to an SMIng statement is the
4770 AGENT-CAPABILITIES macro. However, this can be mapped to the
4771 `agentcaps' extension. All other constructs and types are directly
4772 mappable without loss of information.
4774 Detailed mapping information is subject to a future document.
4776 17.2 Converting SMIng to SMIv2
4778 SMIng is more liberal in some aspects to ensure a more consistent
4779 information model and a short grammar with less exceptions. This
4780 leads to a limited backwards convertability to SMIv2 of different
4781 kinds of identifiers, groups, type definition hierarchies, octet
4782 string length limitations, and object identifier values (those with
4783 a single sub-identifier). Some other information gets lost when
4784 being converted to SMIv2: some occurences of references, units,
4785 formats, default values, table indexing information, and table row
4786 creation information.
4788 Detailed mapping information is subject to a future document.
4792 Conversions between SMIv1 and SMIng are not covered by this
4793 document. Anyhow, conversions between SMIv1 and SMIv2 are subject to
4794 SMIv2 and partly described in [14]. Conversions between SMIv2 and
4795 SMIng are covered in the sections above.
4797 In few words, conversion from SMIv1 to SMIng is not possible in some
4798 cases and without some additional information. Conversion from SMIng
4799 to SMIv1 is possible if 64 bit types and floating point data types
4800 are not used and if identifiers conform to the SMIv1 restrictions.
4815 Strauss Expires August 15, 2000 [Page 86]
4817 Internet-Draft SMIng February 2000
4820 18. Security Considerations
4822 This document defines a language with which to write and read
4823 descriptions of management information. The language itself has no
4824 security impact on the Internet.
4871 Strauss Expires August 15, 2000 [Page 87]
4873 Internet-Draft SMIng February 2000
4876 19. Acknowledgements
4878 This document is originated as a central part of a master's thesis
4879 at the Technical University of Braunschweig, under the guidance of
4880 Juergen Schoenwaelder.
4882 Since SMIng represents a successor of SMIv2, a huge amount of
4883 paragraphs and phrases are taken from the SMIv2 specifications [2],
4884 [3], [4] written by Jeff Case, Keith McCloghrie, David Perkins,
4885 Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser.
4887 Finally, Marshall T. Rose's work on an XML framework for RFC authors
4888 [15] made the writing of an Internet standards document much more
4891 Thanks to these people and the authors of these documents.
4927 Strauss Expires August 15, 2000 [Page 88]
4929 Internet-Draft SMIng February 2000
4934 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
4935 Levels", RFC 2119, BCP 14, March 1997.
4937 [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
4938 M., Waldbusser, S., "Structure of Management Information
4939 Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
4941 [3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
4942 M., Waldbusser, S., "Textual Conventions for SMIv2", RFC 2579,
4945 [4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
4946 M., Waldbusser, S., "Conformance Statements for SMIv2", RFC
4947 2580, STD 60, April 1999.
4949 [5] Rose, M., McCloghrie, K., "Structure and Identification of
4950 Management Information for TCP/IP-based Internets", RFC 1155,
4953 [6] Rose, M., McCloghrie, K., "Concise MIB Definitions", RFC 1212,
4956 [7] Rose, M., "A Convention for Defining Traps for use with the
4957 SNMP", RFC 1215, March 1991.
4959 [8] Crocker, D., Overell, P., "Augmented BNF for Syntax
4960 Specifications: ABNF", RFC 2234, November 1997.
4962 [9] International Organization for Standardization, "Specification
4963 of Abstract Syntax Notation One (ASN.1)", International
4964 Standard 8824, December 1987.
4966 [10] Harrington, D., Presuhn, R., Wijnen, B., "An Architecture for
4967 Describing SNMP Management Frameworks", RFC 2271, January 1999.
4969 [11] Institute of Electrical and Electronics Engineers, "IEEE
4970 Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
4971 Standard 754-1985, August 1985.
4973 [12] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
4974 RFC 2279, January 1998.
4976 [13] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,
4977 "Management Information Base for Version 2 of the Simple
4978 Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
4980 [14] Wijnen, B., Levi, D., "V2ToV1 - Mapping SNMPv2 onto SNMPv1
4983 Strauss Expires August 15, 2000 [Page 89]
4985 Internet-Draft SMIng February 2000
4988 within a bi-lingual SNMP agent", RFC 2089, January 1997.
4990 [15] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
5001 Phone: +49 531 391-3266
5002 EMail: strauss@ibr.cs.tu-bs.de
5003 URI: http://www.ibr.cs.tu-bs.de/
5039 Strauss Expires August 15, 2000 [Page 90]
5041 Internet-Draft SMIng February 2000
5044 Appendix A. The SMIng ABNF grammar
5046 The SMIng grammar conforms to the Augmented Backus-Naur Form
5047 (ABNF)[8], with one exception: For readability, keywords are
5048 represented as quoted strings, although ABNF would declare these
5049 strings to be case-insensitive. Anyhow, SMIng keyword are meant to
5053 ;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234).
5055 ;; @(#) $Id: draft-irtf-nmrg-sming-02.txt 817 2000-02-15 10:41:02Z strauss $
5057 ;; Copyright (C) The Internet Society (1999). All Rights Reserved.
5060 smingFile = optsep *(moduleStatement optsep)
5066 moduleStatement = moduleKeyword sep ucIdentifier optsep "{" stmtsep
5067 *(importStatement stmtsep)
5068 organizationStatement stmtsep
5069 contactStatement stmtsep
5070 descriptionStatement stmtsep
5071 *1(referenceStatement stmtsep)
5072 1*(revisionStatement stmtsep)
5073 *1(identityStatement stmtsep)
5074 *(extensionStatement stmtsep)
5075 *(typedefStatement stmtsep)
5076 *(anyObjectStatement stmtsep)
5077 *(notificationStatement stmtsep)
5078 *(groupStatement stmtsep)
5079 *(complianceStatement stmtsep)
5082 extensionStatement = extensionKeyword sep lcIdentifier optsep
5084 *1(statusStatement stmtsep)
5085 descriptionStatement stmtsep
5086 *1(referenceStatement stmtsep)
5087 *1(abnfStatement stmtsep)
5090 typedefStatement = typedefKeyword sep ucIdentifier optsep
5092 typedefTypeStatement stmtsep
5095 Strauss Expires August 15, 2000 [Page 91]
5097 Internet-Draft SMIng February 2000
5100 *1(defaultStatement stmtsep)
5101 *1(formatStatement stmtsep)
5102 *1(unitsStatement stmtsep)
5103 *1(statusStatement stmtsep)
5104 descriptionStatement stmtsep
5105 *1(referenceStatement stmtsep)
5108 anyObjectStatement = nodeStatement /
5112 nodeStatement = nodeKeyword sep lcIdentifier optsep
5114 oidStatement stmtsep
5115 *1(statusStatement stmtsep)
5116 *1(descriptionStatement stmtsep)
5117 *1(referenceStatement stmtsep)
5120 scalarStatement = scalarKeyword sep lcIdentifier optsep
5122 oidStatement stmtsep
5123 typeStatement stmtsep
5124 accessStatement stmtsep
5125 *1(defaultStatement stmtsep)
5126 *1(formatStatement stmtsep)
5127 *1(unitsStatement stmtsep)
5128 *1(statusStatement stmtsep)
5129 descriptionStatement stmtsep
5130 *1(referenceStatement stmtsep)
5133 tableStatement = tableKeyword sep lcIdentifier optsep
5135 oidStatement stmtsep
5136 *1(statusStatement stmtsep)
5137 descriptionStatement stmtsep
5138 *1(referenceStatement stmtsep)
5139 rowStatement stmtsep
5142 rowStatement = rowKeyword sep lcIdentifier optsep
5144 oidStatement stmtsep
5145 anyIndexStatement stmtsep
5146 *1(createStatement stmtsep)
5147 *1(statusStatement stmtsep)
5148 descriptionStatement stmtsep
5151 Strauss Expires August 15, 2000 [Page 92]
5153 Internet-Draft SMIng February 2000
5156 *1(referenceStatement stmtsep)
5157 1*(columnStatement stmtsep)
5160 columnStatement = columnKeyword sep lcIdentifier optsep
5162 oidStatement stmtsep
5163 typeStatement stmtsep
5164 accessStatement stmtsep
5165 *1(defaultStatement stmtsep)
5166 *1(formatStatement stmtsep)
5167 *1(unitsStatement stmtsep)
5168 *1(statusStatement stmtsep)
5169 descriptionStatement stmtsep
5170 *1(referenceStatement stmtsep)
5173 notificationStatement = notificationKeyword sep lcIdentifier
5175 oidStatement stmtsep
5176 *1(objectsStatement stmtsep)
5177 *1(statusStatement stmtsep)
5178 descriptionStatement stmtsep
5179 *1(referenceStatement stmtsep)
5182 groupStatement = groupKeyword sep lcIdentifier optsep
5184 oidStatement stmtsep
5185 membersStatement stmtsep
5186 *1(statusStatement stmtsep)
5187 descriptionStatement stmtsep
5188 *1(referenceStatement stmtsep)
5191 complianceStatement = complianceKeyword sep lcIdentifier optsep
5193 oidStatement stmtsep
5194 *1(statusStatement stmtsep)
5195 descriptionStatement stmtsep
5196 *1(referenceStatement stmtsep)
5197 *1(mandatoryStatement stmtsep)
5198 *(optionalStatement stmtsep)
5199 *(refineStatement stmtsep)
5202 importStatement = importKeyword sep ucIdentifier optsep
5204 identifierList optsep
5207 Strauss Expires August 15, 2000 [Page 93]
5209 Internet-Draft SMIng February 2000
5214 revisionStatement = revisionKeyword optsep "{" stmtsep
5215 dateStatement stmtsep
5216 descriptionStatement stmtsep
5219 identityStatement = identityKeyword sep lcIdentifier optsep ";"
5221 typedefTypeStatement = typeKeyword sep refinedBaseType optsep ";"
5223 typeStatement = typeKeyword sep
5224 (refinedBaseType / refinedType)
5227 writetypeStatement = writetypeKeyword sep
5228 (refinedBaseType / refinedType)
5231 anyIndexStatement = indexStatement /
5237 indexStatement = indexKeyword *1(sep impliedKeyword) optsep
5238 "(" optsep qlcIdentifierList
5239 optsep ")" optsep ";"
5241 augmentsStatement = augmentsKeyword sep qlcIdentifier
5244 reordersStatement = reordersKeyword sep qlcIdentifier
5245 *1(sep impliedKeyword)
5247 qlcIdentifierList optsep ")"
5250 sparseStatement = sparseKeyword sep qlcIdentifier optsep ";"
5252 expandsStatement = expandsKeyword sep qlcIdentifier
5253 *1(sep impliedKeyword)
5255 qlcIdentifierList optsep ")"
5258 createStatement = createKeyword optsep ";"
5260 oidStatement = oidKeyword sep objectIdentifier optsep ";"
5263 Strauss Expires August 15, 2000 [Page 94]
5265 Internet-Draft SMIng February 2000
5268 dateStatement = dateKeyword sep date optsep ";"
5270 organizationStatement = organizationKeyword sep text optsep ";"
5272 contactStatement = contactKeyword sep text optsep ";"
5274 formatStatement = formatKeyword sep format optsep ";"
5276 unitsStatement = unitsKeyword sep units optsep ";"
5278 statusStatement = statusKeyword sep status optsep ";"
5280 accessStatement = accessKeyword sep access optsep ";"
5282 defaultStatement = defaultKeyword sep anyValue optsep ";"
5284 descriptionStatement = descriptionKeyword sep text optsep ";"
5286 referenceStatement = referenceKeyword sep text optsep ";"
5288 abnfStatement = abnfKeyword sep text optsep ";"
5290 membersStatement = membersKeyword optsep "(" optsep
5291 qlcIdentifierList optsep
5294 objectsStatement = objectsKeyword optsep "(" optsep
5295 qlcIdentifierList optsep
5298 mandatoryStatement = mandatoryKeyword optsep "(" optsep
5299 qlcIdentifierList optsep
5302 optionalStatement = optionalKeyword sep qlcIdentifier optsep
5303 "{" descriptionStatement stmtsep
5306 refineStatement = refineKeyword sep qlcIdentifier optsep "{"
5307 *1(typeStatement stmtsep)
5308 *1(writetypeStatement stmtsep)
5309 *1(accessStatement stmtsep)
5310 descriptionStatement stmtsep
5319 Strauss Expires August 15, 2000 [Page 95]
5321 Internet-Draft SMIng February 2000
5324 refinedBaseType = OctetStringKeyword *1(optsep numberSpec) /
5325 ObjectIdentifierKeyword /
5326 Integer32Keyword *1(optsep numberSpec) /
5327 Unsigned32Keyword *1(optsep numberSpec) /
5328 Integer64Keyword *1(optsep numberSpec) /
5329 Unsigned64Keyword *1(optsep numberSpec) /
5330 Float32Keyword *1(optsep floatSpec) /
5331 Float64Keyword *1(optsep floatSpec) /
5332 Float128Keyword *1(optsep floatSpec) /
5333 EnumerationKeyword optsep namedNumberSpec /
5334 // TODO: inserted optsep, do also in parser grammar!
5335 BitsKeyword optsep namedNumberSpec
5336 // TODO: inserted optsep, do also in parser grammar!
5338 refinedType = qucIdentifier *1(optsep anySpec)
5340 anySpec = numberSpec / floatSpec
5342 numberSpec = "(" optsep numberElement
5343 *furtherNumberElement
5346 furtherNumberElement = optsep "|" optsep numberElement
5348 numberElement = signedNumber *1numberUpperLimit
5350 numberUpperLimit = optsep ".." optsep signedNumber
5352 floatSpec = "(" optsep floatElement
5353 *furtherFloatElement
5356 furtherFloatElement = optsep "|" optsep floatElement
5358 floatElement = floatValue *1floatUpperLimit
5360 floatUpperLimit = optsep ".." optsep floatValue
5362 namedNumberSpec = "(" optsep namedNumberList optsep ")"
5364 namedNumberList = namedNumberItem
5365 *(optsep "," optsep namedNumberItem)
5368 namedNumberItem = lcIdentifier optsep "(" optsep number
5371 identifierList = identifier
5372 *(optsep "," optsep identifier)
5375 Strauss Expires August 15, 2000 [Page 96]
5377 Internet-Draft SMIng February 2000
5382 qIdentifierList = qIdentifier
5383 *(optsep "," optsep qIdentifier)
5386 qlcIdentifierList = qlcIdentifier
5387 *(optsep "," optsep qlcIdentifier)
5390 bitsValue = "(" optsep bitsList optsep ")"
5392 bitsList = *1(lcIdentifier
5393 *(optsep "," optsep lcIdentifier))
5397 ;; Other basic rules.
5400 identifier = ucIdentifier / lcIdentifier
5402 qIdentifier = qucIdentifier / qlcIdentifier
5404 ucIdentifier = ucAlpha *63(ALPHA / DIGIT / "-")
5406 qucIdentifier = *1(ucIdentifier "::") ucIdentifier
5408 lcIdentifier = lcAlpha *63(ALPHA / DIGIT / "-")
5410 qlcIdentifier = *1(ucIdentifier "::") lcIdentifier
5412 text = textSegment *(optsep textSegment)
5414 textSegment = DQUOTE *textAtom DQUOTE
5416 textAtom = textVChar / HTAB / SP / lineBreak
5418 date = DQUOTE 4DIGIT "-" 2DIGIT "-" 2DIGIT
5419 *1(" " 2DIGIT ":" 2DIGIT)
5423 format = textSegment
5427 anyValue = bitsValue /
5431 Strauss Expires August 15, 2000 [Page 97]
5433 Internet-Draft SMIng February 2000
5440 ; Note: `objectIdentifer' includes the
5441 ; syntax of enumeration labels and postive
5442 ; numbers. They are not named literally to
5443 ; avoid reduce/reduce conflicts when
5444 ; building LR parsers based on this
5447 status = currentKeyword /
5451 access = noaccessKeyword /
5456 objectIdentifier = (qlcIdentifier / subid) *127("." subid)
5458 subid = decimalNumber
5460 number = hexadecimalNumber / decimalNumber
5462 negativeNumber = "-" decimalNumber
5464 signedNumber = number / negativeNumber
5466 decimalNumber = "0" / (nonZeroDigit *DIGIT)
5468 zeroDecimalNumber = 1*DIGIT
5470 hexadecimalNumber = "0x" 1*(HEXDIG HEXDIG)
5472 floatValue = neginfKeyword /
5476 signedNumber "." zeroDecimalNumber
5477 *1("E" ("+"/"-") zeroDecimalNumber)
5480 ;; Rules to skip unknown statements
5481 ;; with arbitrary arguments and blocks.
5484 unknownStatement = unknownKeyword optsep *unknownArgument
5487 Strauss Expires August 15, 2000 [Page 98]
5489 Internet-Draft SMIng February 2000
5494 unknownArgument = ("(" optsep unknownList optsep ")") /
5495 ("{" optsep *unknownStatement optsep "}") /
5500 unknownList = namedNumberList /
5503 unknownKeyword = lcIdentifier
5508 ;; Typically, keywords are represented by tokens returned from the
5509 ;; lexical analyzer. Note, that the lexer has to be stateful to
5510 ;; distinguish keywords from identifiers depending on the context
5511 ;; position in the input stream.
5513 ;; Also note, that these keyword definitions are represented in
5514 ;; cleartext for readability, while SMIng keywords are meant to be
5515 ;; case-sensitive, although ABNF makes quoted strings like these to
5516 ;; be case-insensitive.
5519 ;; Statement keywords.
5521 moduleKeyword = "module"
5522 importKeyword = "import"
5523 revisionKeyword = "revision"
5525 dateKeyword = "date"
5526 organizationKeyword = "organization"
5527 contactKeyword = "contact"
5528 descriptionKeyword = "description"
5529 referenceKeyword = "reference"
5530 identityKeyword = "identity"
5531 extensionKeyword = "extension"
5532 typedefKeyword = "typedef"
5533 typeKeyword = "type"
5534 writetypeKeyword = "writetype"
5535 nodeKeyword = "node"
5536 scalarKeyword = "scalar"
5537 tableKeyword = "table"
5538 columnKeyword = "column"
5540 notificationKeyword = "notification"
5543 Strauss Expires August 15, 2000 [Page 99]
5545 Internet-Draft SMIng February 2000
5548 groupKeyword = "group"
5549 complianceKeyword = "compliance"
5550 formatKeyword = "format"
5551 unitsKeyword = "units"
5552 statusKeyword = "status"
5553 accessKeyword = "access"
5554 defaultKeyword = "default"
5555 impliedKeyword = "implied"
5556 indexKeyword = "index"
5557 augmentsKeyword = "augments"
5558 reordersKeyword = "reorders"
5559 sparseKeyword = "sparse"
5560 expandsKeyword = "expands"
5561 createKeyword = "create"
5562 membersKeyword = "members"
5563 objectsKeyword = "objects"
5564 mandatoryKeyword = "mandatory"
5565 optionalKeyword = "optional"
5566 refineKeyword = "refine"
5567 abnfKeyword = "abnf"
5569 ;; Base type keywords.
5571 OctetStringKeyword = "OctetString"
5572 ObjectIdentifierKeyword = "ObjectIdentifier"
5573 Integer32Keyword = "Integer32"
5574 Unsigned32Keyword = "Unsigned32"
5575 Integer64Keyword = "Integer64"
5576 Unsigned64Keyword = "Unsigned64"
5577 Float32Keyword = "Float32"
5578 Float64Keyword = "Float64"
5579 Float128Keyword = "Float128"
5580 BitsKeyword = "Bits"
5581 EnumerationKeyword = "Enumeration"
5585 currentKeyword = "current"
5586 deprecatedKeyword = "deprecated"
5587 obsoleteKeyword = "obsolete"
5591 noaccessKeyword = "noaccess"
5592 notifyonlyKeyword = "notifyonly"
5593 readonlyKeyword = "readonly"
5594 readwriteKeyword = "readwrite"
5596 ;; Special floating point values' keywords.
5599 Strauss Expires August 15, 2000 [Page 100]
5601 Internet-Draft SMIng February 2000
5604 neginfKeyword = "neginf"
5605 posinfKeyword = "posinf"
5606 snanKeyword = "snan"
5607 qnanKeyword = "qnan"
5610 ;; Some low level rules.
5611 ;; These tokens are typically skipped by the lexical analyzer.
5614 sep = 1*(comment / lineBreak / WSP)
5615 ; unconditional separator
5617 optsep = *(comment / lineBreak / WSP)
5619 stmtsep = *(comment /
5624 comment = "//" *(WSP / VCHAR) lineBreak
5626 lineBreak = CRLF / LF
5629 ;; Encoding specific rules.
5632 textVChar = %x21 / %x23-7E
5633 ; any VCHAR except DQUOTE
5639 nonZeroDigit = %x31-39
5642 ;; RFC 2234 core rules.
5645 ALPHA = %x41-5A / %x61-7A
5652 ; Internet standard newline
5655 Strauss Expires August 15, 2000 [Page 101]
5657 Internet-Draft SMIng February 2000
5666 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
5678 ; visible (printing) characters
5711 Strauss Expires August 15, 2000 [Page 102]
5713 Internet-Draft SMIng February 2000
5716 Appendix B. Glossary
5718 columnar object: An object in a table row that may have zero, one or
5719 more object instances. Instances are identified by using the
5720 values of `indexing objects' as `instance identifier'.
5722 extension: The SMIng `extension' statement can be used to define new
5723 statements. Extensions can express annotations to existent
5724 management information, agent capabilities known from SMIv2, or
5725 arbitrary other information. See Section 16 for details.
5727 identifier: The name of any definition, either a module, type, node,
5728 scalar object, table, row, columnar object, notification, group,
5729 compliance, a named number of an enumeration or bits type or any
5730 construct defined by an SMIng extension. Every identifier starts
5731 with an upper-case or lower-case character, followed by letters,
5732 digits and hyphens, but without consecutive or trailing hyphens.
5733 The length of an identifier MUST NOT exceed 64 characters. Note
5734 that SMIng keywords may be used as identifiers, though it's NOT
5735 RECOMMENDED. See also Section 2.1.
5737 indexing objects: A Table may contain multiple instances of single
5738 columnar objects. That is, there may be multiple rows. The
5739 table's `indexing objects' are used to unambiguously distinguish
5740 the rows of a table. A special encoding of their values
5741 represents the columns' instance-identifier, and thus identifies
5744 instance-identifier: That part of an object identifier value, that
5745 is used to unambiguously identify an instance of an object. For
5746 scalar objects, the instance-identifier is `0'. For columnar
5747 objects, the instance-identifier is built from the values of the
5748 `indexing objects'. See also Section 2.4.
5750 module: A module is the container of inter-related management
5751 information, either managed objects or other definitions like
5752 type definitions or annotations. A module has to conform the
5753 SMIng grammar and semantics described by this document. A module
5754 represents a namespace in which local definitions are available
5755 and external definitions have to be imported.
5757 named number: Values of `Enumeration' types (Section 3.10) and
5758 single elements of `Bits' (Section 3.11) types are integer
5759 numbers, each associated with an identifers. Those
5760 number-identifier pairs are called `named numbers'.
5762 object: A leaf definition in the object identifier tree, that
5763 represents a class of object instances. Objects are exactly those
5764 definitions declared by the SMIng keywords `scalar' or `column'.
5767 Strauss Expires August 15, 2000 [Page 103]
5769 Internet-Draft SMIng February 2000
5772 object identifier: Management information is organized in a tree of
5773 nodes. Each node is unambiguously identified by an `object
5774 identifier', that consists of a sequence of integer numbers
5775 (`sub-identifiers') which represent the path of nodes from the
5776 root to the addressed node in the tree. See also Section 2.
5778 row: The kind of node used to group columnar objects of a table.
5779 Some significant information on table indexing and information
5780 used for row creation and deletion is associated with a table's
5783 scalar object: An object that has zero or one object instance.
5785 sub-identifier: A single component of an object identifier. There
5786 are at most 128 sub-identifiers in an object identifier value and
5787 each sub-identifier has a maximum value of 2^32-1 (4294967295).
5789 table: The kind of node used to group management information that is
5790 organized in a sequence of rows.
5823 Strauss Expires August 15, 2000 [Page 104]
5825 Internet-Draft SMIng February 2000
5828 Full Copyright Statement
5830 Copyright (C) The Internet Society (2000). All Rights Reserved.
5832 This document and translations of it may be copied and furnished to
5833 others, and derivative works that comment on or otherwise explain it
5834 or assist in its implmentation may be prepared, copied, published
5835 and distributed, in whole or in part, without restriction of any
5836 kind, provided that the above copyright notice and this paragraph
5837 are included on all such copies and derivative works. However, this
5838 document itself may not be modified in any way, such as by removing
5839 the copyright notice or references to the Internet Society or other
5840 Internet organizations, except as needed for the purpose of
5841 developing Internet standards in which case the procedures for
5842 copyrights defined in the Internet Standards process must be
5843 followed, or as required to translate it into languages other than
5846 The limited permissions granted above are perpetual and will not be
5847 revoked by the Internet Society or its successors or assigns.
5849 This document and the information contained herein is provided on an
5850 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
5851 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
5852 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
5853 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
5854 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5879 Strauss Expires August 15, 2000 [Page 105]
projects / platform / upstream / libsmi.git / blob