ACC SHELL
Network Working Group F. Strauss
Internet-Draft TU Braunschweig
Expires: August 15, 2000 February 15, 2000
SMIng - A new Structure of Management Information
draft-irtf-nmrg-sming-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2000.
Abstract
This memo presents a language for management information
specifications. It eliminates known problems present in the current
SMIv2 as specified in [2], [3], and [4]. Language extensibility
features and a more efficient and programmer-friendly notation are
introduced. Conversions from SMIv2 to SMIng and vice versa are also
considered by this document.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Strauss Expires August 15, 2000 [Page 1]
Internet-Draft SMIng February 2000
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Relation to SNMP . . . . . . . . . . . . . . . . . . . . 6
2. The Information Model . . . . . . . . . . . . . . . . . 8
2.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Object Identifier Hierarchy . . . . . . . . . . . . . . 10
2.3 Kinds of Nodes . . . . . . . . . . . . . . . . . . . . . 11
2.4 Scalar and Columnar Objects' Instances . . . . . . . . . 12
3. Base Types and Derived Types . . . . . . . . . . . . . . 15
3.1 OctetString . . . . . . . . . . . . . . . . . . . . . . 15
3.2 ObjectIdentifier . . . . . . . . . . . . . . . . . . . . 16
3.3 Integer32 . . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Integer64 . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . 18
3.6 Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 Float32 . . . . . . . . . . . . . . . . . . . . . . . . 20
3.8 Float64 . . . . . . . . . . . . . . . . . . . . . . . . 21
3.9 Float128 . . . . . . . . . . . . . . . . . . . . . . . . 22
3.10 Enumeration . . . . . . . . . . . . . . . . . . . . . . 23
3.11 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.12 Display Formats . . . . . . . . . . . . . . . . . . . . 24
4. The SMIng File Structure . . . . . . . . . . . . . . . . 27
4.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Statements and Arguments . . . . . . . . . . . . . . . . 27
5. The module Statement . . . . . . . . . . . . . . . . . . 28
5.1 The module's import Statement . . . . . . . . . . . . . 28
5.2 The module's organization Statement . . . . . . . . . . 29
5.3 The module's contact Statement . . . . . . . . . . . . . 29
5.4 The module's description Statement . . . . . . . . . . . 29
5.5 The module's reference Statement . . . . . . . . . . . . 29
5.6 The module's revision Statement . . . . . . . . . . . . 29
5.6.1 The revision's date Statement . . . . . . . . . . . . . 30
5.6.2 The revision's description Statement . . . . . . . . . . 30
5.7 The module's identity Statement . . . . . . . . . . . . 30
5.8 Usage Example . . . . . . . . . . . . . . . . . . . . . 30
6. The extension Statement . . . . . . . . . . . . . . . . 32
6.1 The extension's status Statement . . . . . . . . . . . . 32
6.2 The extension's description Statement . . . . . . . . . 32
6.3 The extension's reference Statement . . . . . . . . . . 32
6.4 The extension's abnf Statement . . . . . . . . . . . . . 33
7. The typedef Statement . . . . . . . . . . . . . . . . . 34
7.1 The typedef's type Statement . . . . . . . . . . . . . . 34
7.2 The typedef's default Statement . . . . . . . . . . . . 34
7.3 The typedef's format Statement . . . . . . . . . . . . . 34
7.4 The typedef's units Statement . . . . . . . . . . . . . 35
7.5 The typedef's status Statement . . . . . . . . . . . . . 35
7.6 The typedef's description Statement . . . . . . . . . . 36
Strauss Expires August 15, 2000 [Page 2]
Internet-Draft SMIng February 2000
7.7 The typedef's reference Statement . . . . . . . . . . . 36
7.8 Usage Examples . . . . . . . . . . . . . . . . . . . . . 36
8. The node Statement . . . . . . . . . . . . . . . . . . . 38
8.1 The node's oid Statement . . . . . . . . . . . . . . . . 38
8.2 The node's status Statement . . . . . . . . . . . . . . 38
8.3 The node's description Statement . . . . . . . . . . . . 38
8.4 The node's reference Statement . . . . . . . . . . . . . 38
8.5 Usage Examples . . . . . . . . . . . . . . . . . . . . . 39
9. The scalar Statement . . . . . . . . . . . . . . . . . . 40
9.1 The scalar's oid Statement . . . . . . . . . . . . . . . 40
9.2 The scalar's type Statement . . . . . . . . . . . . . . 40
9.3 The scalar's access Statement . . . . . . . . . . . . . 40
9.4 The scalar's default Statement . . . . . . . . . . . . . 40
9.5 The scalar's format Statement . . . . . . . . . . . . . 41
9.6 The scalar's units Statement . . . . . . . . . . . . . . 41
9.7 The scalar's status Statement . . . . . . . . . . . . . 41
9.8 The scalar's description Statement . . . . . . . . . . . 42
9.9 The scalar's reference Statement . . . . . . . . . . . . 42
9.10 Usage Examples . . . . . . . . . . . . . . . . . . . . . 42
10. The table Statement . . . . . . . . . . . . . . . . . . 43
10.1 The table's oid Statement . . . . . . . . . . . . . . . 43
10.2 The table's status Statement . . . . . . . . . . . . . . 43
10.3 The table's description Statement . . . . . . . . . . . 43
10.4 The table's reference Statement . . . . . . . . . . . . 43
10.5 The table's row Statement . . . . . . . . . . . . . . . 44
10.5.1 The row's oid Statement . . . . . . . . . . . . . . . . 44
10.5.2 Table Indexing Statements . . . . . . . . . . . . . . . 44
10.5.2.1 The row's index Statement for Table Indexing . . . . . . 44
10.5.2.2 The row's augments Statement for Table Indexing . . . . 44
10.5.2.3 The row's sparse Statement for Table Indexing . . . . . 45
10.5.2.4 The row's reorders Statement for Table Indexing . . . . 45
10.5.2.5 The row's expands Statement for Table Indexing . . . . . 46
10.5.3 The row's create Statement . . . . . . . . . . . . . . . 46
10.5.4 The row's status Statement . . . . . . . . . . . . . . . 46
10.5.5 The row's description Statement . . . . . . . . . . . . 46
10.5.6 The row's reference Statement . . . . . . . . . . . . . 47
10.6 The table row's column Statement . . . . . . . . . . . . 47
10.6.1 The column's oid Statement . . . . . . . . . . . . . . . 47
10.6.2 The column's type Statement . . . . . . . . . . . . . . 47
10.6.3 The column's access Statement . . . . . . . . . . . . . 47
10.6.4 The column's default Statement . . . . . . . . . . . . . 48
10.6.5 The column's format Statement . . . . . . . . . . . . . 48
10.6.6 The column's units Statement . . . . . . . . . . . . . . 48
10.6.7 The column's status Statement . . . . . . . . . . . . . 49
10.6.8 The column's description Statement . . . . . . . . . . . 49
10.6.9 The column's reference Statement . . . . . . . . . . . . 49
10.7 Usage Example . . . . . . . . . . . . . . . . . . . . . 49
11. The notification Statement . . . . . . . . . . . . . . . 52
11.1 The notification's oid Statement . . . . . . . . . . . . 52
Strauss Expires August 15, 2000 [Page 3]
Internet-Draft SMIng February 2000
11.2 The notification's objects Statement . . . . . . . . . . 52
11.3 The notification's status Statement . . . . . . . . . . 52
11.4 The notification's description Statement . . . . . . . . 53
11.5 The notification's reference Statement . . . . . . . . . 53
11.6 Usage Example . . . . . . . . . . . . . . . . . . . . . 53
12. The group Statement . . . . . . . . . . . . . . . . . . 54
12.1 The group's oid Statement . . . . . . . . . . . . . . . 54
12.2 The group's members Statement . . . . . . . . . . . . . 54
12.3 The group's status Statement . . . . . . . . . . . . . . 54
12.4 The group's description Statement . . . . . . . . . . . 54
12.5 The group's reference Statement . . . . . . . . . . . . 55
12.6 Usage Example . . . . . . . . . . . . . . . . . . . . . 55
13. The compliance Statement . . . . . . . . . . . . . . . . 56
13.1 The compliance's oid Statement . . . . . . . . . . . . . 56
13.2 The compliance's status Statement . . . . . . . . . . . 56
13.3 The compliance's description Statement . . . . . . . . . 56
13.4 The compliance's reference Statement . . . . . . . . . . 56
13.5 The compliance's mandatory Statement . . . . . . . . . . 56
13.6 The compliance's optional Statement . . . . . . . . . . 57
13.6.1 The optional's description Statement . . . . . . . . . . 57
13.7 The compliance's refine Statement . . . . . . . . . . . 57
13.7.1 The refine's type Statement . . . . . . . . . . . . . . 58
13.7.2 The refine's writetype Statement . . . . . . . . . . . . 58
13.7.3 The refine's access Statement . . . . . . . . . . . . . 58
13.7.4 The refine's description Statement . . . . . . . . . . . 58
13.8 Usage Example . . . . . . . . . . . . . . . . . . . . . 58
14. SMIng Core Modules . . . . . . . . . . . . . . . . . . . 60
14.1 IRTF-NMRG-SMING . . . . . . . . . . . . . . . . . . . . 60
14.2 IRTF-NMRG-SMING-TYPES . . . . . . . . . . . . . . . . . 61
14.3 IRTF-NMRG-SMING-EXTENSIONS . . . . . . . . . . . . . . . 80
15. Extending a Module . . . . . . . . . . . . . . . . . . . 83
16. SMIng Language Extensibility . . . . . . . . . . . . . . 85
17. Module Conversions . . . . . . . . . . . . . . . . . . . 87
17.1 Converting SMIv2 to SMIng . . . . . . . . . . . . . . . 87
17.2 Converting SMIng to SMIv2 . . . . . . . . . . . . . . . 87
17.3 SMIv1 . . . . . . . . . . . . . . . . . . . . . . . . . 87
18. Security Considerations . . . . . . . . . . . . . . . . 88
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . 89
References . . . . . . . . . . . . . . . . . . . . . . . 90
Author's Address . . . . . . . . . . . . . . . . . . . . 91
A. The SMIng ABNF grammar . . . . . . . . . . . . . . . . . 92
B. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 104
Strauss Expires August 15, 2000 [Page 4]
Internet-Draft SMIng February 2000
1. Introduction
Management information is viewed as a collection of managed objects,
residing in a virtual information store, termed the Management
Information Base (MIB). Collections of related objects are defined
in MIB modules. These modules are written conforming to a
specification language, the Structure of Management Information
(SMI). There are different versions of the SMI. SMIv1 [5], [6], [7]
and SMIv2 [2], [3], [4] are based on adapted subsets of OSI's
Abstract Syntax Notation One, ASN.1 [9]. It is the purpose of this
document to define a successor of SMIv1 and SMIv2, the SMIng, in a
self-contained way independent from other standardization bodies'
documents.
Section 2 gives an overview of some basic concepts of the
information model while the subsequent sections present the concepts
of SMIng: the base types, the SMIng file structure, and all SMIng
statements in detail. Section 14 contains three core modules that
are part of the SMIng specification. Section 15 lists rules to
follow when changes are applied to a module. One flexible feature of
SMIng is its extensibility which is described in Section 16.
Finally, Section 17 discusses conversions of SMIv2 modules to SMIng
and vice versa. Appendix A contains the grammar of SMIng in ABNF
[8] notation.
1.1 Terminology
Many terms in SMIv1 and SMIv2 are derived from ASN.1. In some cases,
SMIv1/v2 uses different terms for equal or similar language items
without precise definitions. Appendix B presents a glossary of terms
used throughout this document and in related SMIng documents. Also
refer to the glossary and Appendix A to get detailed information on
the syntax of single language items where not explained in place.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
1.2 Relation to SNMP
Although SMIng is primarily intended to be applied to the SNMP
management framework [10], SMIng is designed to have as few
relations to a specific management protocol as possible. However,
there are some implications of SNMP on SMIv2 that have to be
retained in SMIng:
o In SNMP the last item on a list of objects used to identify a
table row can be encoded without an explicit length encoding.
This has to be expressed by the SMIng `implied' keyword. See
Strauss Expires August 15, 2000 [Page 5]
Internet-Draft SMIng February 2000
Section 10.5 for details.
o SNMP allows to distinguish several related types "on the wire"
while SMIng has a minimal but complete set of base types. To
keep SMIng compatible with the SNMP framework, additional types
derived from SMIng base types are defined in the standard SMIng
module IRTF-NMRG-SMING-TYPES (Section 14.2).
o The encoding of values of type `Bits' in SNMP is dependent on
their named number values. It is RECOMMENDED that they start at 0
and be numbered contiguously to allow a compact encoding for use
with SNMP.
o SNMP implies some restrictions on indexing columnar objects:
Those columns that are used for indexing have to be defined as
non-accessible auxiliary objects, with two exceptions. Hence, the
access level `noaccess' has to be retained in SMIng.
o In order to achieve compatibility with SNMPv1 traps, the next to
last sub-identifier of notification object identifiers SHOULD
have the value zero.
Strauss Expires August 15, 2000 [Page 6]
Internet-Draft SMIng February 2000
2. The Information Model
Internet management is based on the model of "managed objects". A
managed object represents a class of any real or synthesized
variable of systems that are to be managed. Those objects are
organized hierarchically in an "object identifier tree", where only
leaf nodes may represent objects.
Nodes may also identify tables, row definitions of tables,
notifications, groups of objects and/or notifications, compliance
statements, modules or other information. Each node is identified
by an unique "object identifier" value which is an ordered list of
non-negative numbers, named "sub-identifiers", where the left-most
sub-identifier refers to the node next to the root of the tree and
the right-most sub-identifier refers to the node that is identified
by the complete object identifier.
The SMI in general, and SMIng in particular, is the information
model used to define and organize the structure of managed objects
and related information. Thus, SMIng describes a language designed
to specify management information in a way readable to computer
programs, named MIB compilers, as well as to human readers.
Related management information is defined in MIB modules. A module
may refer to definitions from other modules by importing identifiers
from those modules. Each module may serve one or multiple purposes:
o the definition of inter-related managed objects, notifications
and groups of them,
o the definition of (restricted) types for use in the local module
or in other modules,
o the definition of compliance statements for groups of objects and
notifications to guide agent implementors in what they have to
serve or implementors of management applications in what they can
expect,
o the definition of SMIng extensions to allow the local module or
other modules to specify information beyond the scope of the base
SMIng in a machine readable notation,
o the definition of information beyond the scope of the base SMIng
statements, based on locally defined or imported SMIng
extensions, like capability statements for agent implementations.
This classification scheme does not imply a rigid taxonomy. For
example, a "standard" module will normally include definitions of
managed objects and a compliance statement. Similarly, an
Strauss Expires August 15, 2000 [Page 7]
Internet-Draft SMIng February 2000
"enterprise-specific" module might include definitions of managed
objects and a capability statement based on an extension. Of course,
a "standard" module may not contain capability statements.
Each module is identified by an upper-case identifier. The names of
all standard modules must be unique (but different versions of the
same module should have the same name). Developers of enterprise
modules are encouraged to choose names for their modules that will
have a low probability of colliding with standard or other
enterprise modules, e.g. by using the enterprise or organization
name as a prefix.
2.1 Identifiers
Identifiers are used to identify different kinds of SMIng items by
name. These names are valid in a namespace which is dependent on the
SMIng item. Those items are
o modules (Section 5), whose namespace is the global range of all
SMIng definitions,
o defined data types (Section 7), whose namespace is the local
module where the type is defined,
o elements of enumeration and bitset types (Section 3.10, Section
3.11), whose namespace is the related type definition construct
and all constructs using that type,
o object identifier tree nodes of different kinds (Section 5, and
Section 8 through Section 13), whose namespace is the local
module where the node is defined, and
o SMIng extension statements (Section 6), whose namespace is the
local module where the extension is defined.
Each identifier starts with an upper-case or lower-case character,
dependent on the kind of SMIng item, followed by zero or more
letters, digits, and hyphens.
For all identifiers of a single kind of item defined in a namespace,
the identifier MUST be unique and SHOULD NOT only differ in case.
Identifiers MUST NOT exceed 64 characters in length. Furthermore,
the set of all identifiers defined in all modules of a single
standardization body or organization SHOULD be unique and mnemonic.
This promotes a common language for humans to use when discussing a
module.
To reference an item that is defined in the local module, its
definition MUST sequentially precede the reference. Thus, there MUST
Strauss Expires August 15, 2000 [Page 8]
Internet-Draft SMIng February 2000
NOT be any forward references, except in two cases:
1. The optional module's `identity' statement, which is located
near the head of a module, specifies an identity node, which is
defined in a subsequent section of the local module.
2. The specification of table indexing objects in a table row may
include objects that cannot be defined without the definition of
the current table row. Hence table indexing statements are
allowed to include forward references.
To reference an item, that is defined in an external module it MUST
be imported into the local module's namespace (Section 5.1).
Identifiers that are neither defined nor imported MUST NOT be
visible in the local module. On the other hand, all items defined in
a module are implicitly exported.
Note when identifiers from external modules are referenced, there is
the possibility of name collisions. As such, if different items with
the same identifier are imported or if imported identifiers collide
with identifiers of locally defined items, then this ambiguity is
resolved by prefixing those identifiers with the names of their
modules and the namespace operator `::', i.e. `Module::item'. Of
course, this notation can be used to refer to identifiers even when
there is no name collision.
Note that SMIng language keywords MUST NOT be imported. The main set
of keywords are SMIng statements and base types. See the
`...Keyword' rules of the SMIng ABNF grammar in Appendix A for a
list of those keywords.
Finally, by convention, if the identifier refers to an object with a
counter type (Counter32 or Counter64, derived from Unsigned32 and
Unsigned64) then the identifier used for the object SHOULD denote
plurality.
2.2 Object Identifier Hierarchy
The layers of the object identifier tree near the root are well
defined and organized by standardization bodies. The first level
next to the root has three nodes:
0: ccitt
1: iso
2: joint-iso-ccitt
Note that the renaming of the Commite Consultatif International de
Strauss Expires August 15, 2000 [Page 9]
Internet-Draft SMIng February 2000
Telegraphique et Telephonique (CCITT) to International
Telecommunications Union (ITU) had no consequence on the names used
in the object identifier tree.
The root of the subtree administered by the Internet Assigned
Numbers Authority (IANA) for the Internet is `1.3.6.1' which is
assigned with the identifier `internet'. That is, the Internet
subtree of object identifiers starts with the prefix `1.3.6.1.'.
Several branches underneath this subtree are used for network
management:
The `mgmt' (internet.2) subtree is used to identify "standard"
information.
The `experimental' (internet.3) subtree is used to identify
information being designed by working groups of the IETF or IRTF. If
a module produced by a working group becomes a "standard" module
then at the very beginning of its entry onto the Internet standards
track, the information is moved under the mgmt subtree.
The `private' (internet.4) subtree is used to identify information
defined unilaterally. The `enterprises' (private.1) subtree beneath
private is used, among other things, to permit providers of
networking subsystems to register models of their products.
These and some other nodes are defined in the SMIng standard module
IRTF-NMRG-SMING (Section 14.1).
2.3 Kinds of Nodes
Each node in the object identifier tree may be of a single kind
which may represent management information or not:
o simple nodes, that do not represent management information, but
may be used for grouping nodes in a subtree,
o nodes representing the identity of a module to allow references
to a module in other objects of type `ObjectIdentifier',
o scalar objects, which have zero or one object instance and no
child nodes. See Section 2.4 for scalar objects' instances,
o tables, which represent the root node of a collection of
information structured in table rows. A table node SHOULD have no
more child nodes than the single row node of this table,
o rows, which belong to a table (that is, the table's full object
identifier is a prefix of the row's object identifier) and
Strauss Expires August 15, 2000 [Page 10]
Internet-Draft SMIng February 2000
represent a sequence of one or more columnar objects. Those
columnar objects MUST be the only child nodes of a table row. A
row's object identifier MUST be constructed by appending a `1'
sub-identifier to the table's object identifier,
o columnar objects, which belong to a row (that is, the row's full
object identifier is a prefix of the columnar objects' object
identifier) and have zero or more object instances and no child
nodes. Each columnar object's object identifier MUST be
constructed by appending a single sub-identifier to the row's
object identifier. See Section 2.4 for columnar objects'
instances,
o notifications, which represent information that is sent by agents
within unsolicited transmissions. A notification's object
identifier SHOULD not have any child node,
o groups of objects and notifications, which may be used for
compliance statements or other purposes,
o compliance statements which define requirements for MIB module
implementations,
o other nodes, that may be used to identify arbitrary information.
2.4 Scalar and Columnar Objects' Instances
Instances of managed objects are identified by appending an
instance-identifier to the object's object identifier. Scalar
objects and columnar objects use different ways to construct the
instance-identifier.
Scalar objects have zero or one object instance. If it exists, it is
identified by appending a single `0' sub-identifier to the object
identifier of the scalar object.
Within tables, different instances of the same columnar object are
identified by appending a sequence of one or more sub-identifiers to
the object identifier of the columnar object which consists of the
values of object instances that unambiguously distinguish a table
row. These indexing objects can be columnar objects of the same
and/or another table, but MUST NOT be scalar objects. Multiple
applications of the same object in a single table indexing
specification are strongly discouraged.
The base types (Section 3) of the indexing objects indicate how to
form the instance-identifier:
o integer-valued or enumeration-valued: a single sub-identifier
Strauss Expires August 15, 2000 [Page 11]
Internet-Draft SMIng February 2000
taking the integer value (this works only for non-negative
integers and integers of a size of up to 32 bits),
o string-valued, fixed-length strings (or variable-length with
compact encoding): `n' sub-identifiers, where `n' is the length
of the string (each octet of the string is encoded in a separate
sub-identifier),
o string-valued, variable-length strings or bits-valued: `n+1'
sub-identifiers, where `n' is the length of the string or bits
encoding (the first sub-identifier is `n' itself, following this,
each octet of the string or bits is encoded in a separate
sub-identifier),
o object identifier-valued (with compact encoding): `n'
sub-identifiers, where `n' is the number of sub-identifiers in
the value (each sub-identifier of the value is copied into a
separate sub-identifier),
o object identifier-valued: `n+1' sub-identifiers, where `n' is the
number of sub-identifiers in the value (the first sub-identifier
is `n' itself, following this, each sub-identifier in the value
is copied),
Note that compact encoding can only be applied to an object having a
variable-length syntax (e.g., variable-length strings, bits objects
or object identifier-valued objects). Further, compact encoding can
only be associated with the last object in a list of indexing
objects. Finally, compact encoding MUST NOT be used on a
variable-length string object if that string might have a value of
zero-length.
Instances identified by use of integer-valued or enumeration-valued
objects are RECOMMENDED to be numbered starting from one (i.e., not
from zero). Integer objects that allow negative values, Unsigned64
objects, Integer64 objects and floating point objects MUST NOT be
used for table indexing.
Objects which are both specified for indexing in a row and also
columnar objects of the same row are termed auxiliary objects.
Auxiliary objects SHOULD be non-accessible, except in the following
circumstances:
o within a MIB module originally written to conform to SMIv1, or
o a row must contain at least one columnar object which is not an
auxiliary object. In the event that all of a row's columnar
objects are also specified to be indexing objects then one of
them MUST be accessible. (Note that this situation does not arise
Strauss Expires August 15, 2000 [Page 12]
Internet-Draft SMIng February 2000
for a row allowing create access, since such a row will have a
status column which will not be an auxiliary object.)
Strauss Expires August 15, 2000 [Page 13]
Internet-Draft SMIng February 2000
3. Base Types and Derived Types
SMIng has a minimal but complete set of base types, similar to those
of many programming languages, but with some differences due to
special requirements from the management information model described
in Section 2.
Additional types may be defined, derived from those base types and
even from other derived types. Derived types may use subtyping to
formally restrict the possible values. A set of derived types
commonly used in the SNMP framework is defined in the SMIng standard
module IRTF-NMRG-SMING-TYPES (Section 14.2).
Note that types can also be restricted "inline" in object
definitions (Section 9, Section 10.6) or in refinements of
compliance statements (Section 13) without referring an explicitly
defined type.
The different base types and its derived types allow different kinds
of subtyping, namely size restrictions and range restrictions. See
the following sections on base types (Section 3.1 through Section
3.11) for details.
3.1 OctetString
The OctetString base type represents arbitrary binary or textual
data. Although SMIng has a theoretical size limitation of 2^32-1
(4294967295) octets for this base type, MIB designers should realize
that there may be implementation and interoperability limitations
for sizes in excess of 255 octets.
Values of octet strings may be denoted as textual data enclosed in
double quotes or as arbitrary binary data denoted as a `0x'-prefixed
hexadecimal value of arbitrary but even length, where each pair of
hexadecimal digits represents a single octet. Letters in hexadecimal
values MAY be upper-case but lower-case characters are RECOMMENDED.
Textual data may contain any number (possibly zero) of any 7-bit
displayable ASCII characters except double quote `"', including tab
characters, spaces and line terminator characters (nl or cr & nl).
Textual data may span multiple lines, where each subsequent line
prefix containing only white space up to the column where the first
line's data starts SHOULD be skipped by parsers for a better text
formatting.
When defining a type derived (directly or indirectly) from the
OctetString base type, the size in octets may be restricted by
appending a list of size ranges or explicit size values, separated
by pipe `|' characters and the whole list enclosed in parenthesis. A
size range consists of a lower bound, two consecutive dots `..' and
Strauss Expires August 15, 2000 [Page 14]
Internet-Draft SMIng February 2000
an upper bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. Of course, size restricting values MUST NOT be
negative. If multiple values or ranges are given, they all MUST be
disjunct and SHOULD be in ascending order. If a size restriction is
applied to an already size restricted octet string the new
restriction MUST be more limiting, that is raising the lower bounds,
reducing the upper bounds, reducing the alternative size choices, or
splitting ranges into multiple ranges with intermediate gaps.
Value Examples:
"This is a multiline
textual data example." // legal
"This is "illegally" quoted." // illegal quotes
"But this is 'ok'." // legal apostrophe quoting
"" // legal zero length
0x123 // illegal odd hex length
0x534d496e670a // legal octet string
Restriction Examples:
OctetString (0 | 4..255) // legal size spec
OctetString (4) // legal exact size
OctetString (-1 | 1) // illegal negative size
OctetString (1 | 1..10) // illegal overlapping
3.2 ObjectIdentifier
The ObjectIdentifier base type represents any object identifier
value, which is a list of up to 128 numbers, named sub-identifiers.
Each sub-identifier has a value between 0 and 2^32-1 (4294967295).
Values of object identifiers may be denoted as a sequence of
numerical sub-identifier values (decimal or `0x'-prefixed
hexadecimal) separated by single dots and without any intermediate
white space. Alternatively (and preferred in most cases), the first
element may be a previously defined or imported lower-case
identifier, representing a static object identifier prefix while the
total number of sub-identifiers MUST NOT exceed 128 including the
expanded identifier.
Object identifier derived types cannot be restricted in any way.
Value Examples:
Strauss Expires August 15, 2000 [Page 15]
Internet-Draft SMIng February 2000
0 // legal single subid
1.3.6.1 // legal numerical oid
mib-2.1 // legal oid with identifier prefix
internet.4.1.0x0627.0x01 // legal oid with hex subids
iso.-1 // illegal negative subid
iso.org.6 // illegal non-heading identifier
IF-MIB::ifNumber.0 // legel fully quallified instance oid
3.3 Integer32
The Integer32 base type represents integer values between -2^31
(-2147483648) and 2^31-1 (2147483647).
Values of type Integer32 may be denoted as decimal or hexadecimal
numbers, where only decimal numbers can be negative. Other decimal
numbers than zero MUST NOT have leading zero digits. Hexadecimal
numbers are prefixed by `0x' and MUST have an even number of
hexadecimal digits, where letters MAY be upper-case but lower-case
characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the
Integer32 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. If multiple values or ranges are given they
all MUST be disjunct and SHOULD be in ascending order. If a value
restriction is applied to an already restricted type the new
restriction MUST be more limiting, that is raising the lower bounds,
reducing the upper bounds, reducing the alternative choices, or
splitting ranges into multiple ranges with intermediate gaps.
Value Examples:
015 // illegal leading zero
-123 // legal negative value
- 1 // illegal intermediate space
0xabc // illegal hexadecimal value length
-0xff // illegal sign on hex value
0x80000000 // illegal value, too large
0xf00f // legal hexadecimal value
Restriction Examples:
Integer32 (0 | 5..10) // legal range spec
Integer32 (4..8 | 5..10) // illegal overlapping
Strauss Expires August 15, 2000 [Page 16]
Internet-Draft SMIng February 2000
3.4 Integer64
The Integer64 base type represents integer values between -2^63
(-9223372036854775808) and 2^63-1 (9223372036854775807).
Values of type Integer64 may be denoted as decimal or hexadecimal
numbers, where only decimal numbers can be negative. Other decimal
numbers than zero MUST NOT have leading zero digits. Hexadecimal
numbers are prefixed by `0x' and MUST have an even number of
hexadecimal digits, where letters MAY be upper-case but lower-case
characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the
Integer64 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. If multiple values or ranges are given they
all MUST be disjunct and SHOULD be in ascending order. If a value
restriction is applied to an already restricted type the new
restriction MUST be more limiting, that is raising the lower bounds,
reducing the upper bounds, reducing the alternative choices, or
splitting ranges into multiple ranges with intermediate gaps.
Value Examples:
015 // illegal leading zero
-123 // legal negative value
- 1 // illegal intermediate space
0xabc // illegal hexadecimal value length
-0xff // illegal sign on hex value
0x80000000 // legal value
Restriction Examples:
Integer64 (0 | 5..10) // legal range spec
Integer64 (4..8 | 5..10) // illegal overlapping
3.5 Unsigned32
The Unsigned32 base type represents positive integer values between
0 and 2^32-1 (4294967295).
Values of type Unsigned32 may be denoted as decimal or hexadecimal
numbers. Other decimal numbers than zero MUST NOT have leading zero
digits. Hexadecimal numbers are prefixed by `0x' and MUST have an
even number of hexadecimal digits, where letters MAY be upper-case
but lower-case characters are RECOMMENDED.
Strauss Expires August 15, 2000 [Page 17]
Internet-Draft SMIng February 2000
When defining a type derived (directly or indirectly) from the
Unsigned32 base type, the set of possible values may be restricted
by appending a list of ranges or explicit values, separated by pipe
`|' characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. If multiple values or ranges are given they
all MUST be disjunct and SHOULD be in ascending order. If a value
restriction is applied to an already restricted type the new
restriction MUST be more limiting, that is raising the lower bounds,
reducing the upper bounds, reducing the alternative choices, or
splitting ranges into multiple ranges with intermediate gaps.
Value Examples:
015 // illegal leading zero
-123 // illegal negative value
0xabc // illegal hexadecimal value length
0x80000000 // legal hexadecimal value
0x8080000000 // illegal value, too large]]>
Restriction Examples:
Unsigned32 (0 | 5..10) // legal range spec
Unsigned32 (4..8 | 5..10) // illegal overlapping
3.6 Unsigned64
The Unsigned64 base type represents positive integer values between
0 and 2^64-1 (18446744073709551615).
Values of type Unsigned64 may be denoted as decimal or hexadecimal
numbers. Other decimal numbers than zero MUST NOT have leading zero
digits. Hexadecimal numbers are prefixed by `0x' and MUST have an
even number of hexadecimal digits, where letters MAY be upper-case
but lower-case characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the
Unsigned64 base type, the set of possible values may be restricted
by appending a list of ranges or explicit values, separated by pipe
`|' characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. If multiple values or ranges are given they
all MUST be disjunct and SHOULD be in ascending order. If a value
restriction is applied to an already restricted type the new
restriction MUST be more limiting, that is raising the lower bounds,
reducing the upper bounds, reducing the alternative choices, or
splitting ranges into multiple ranges with intermediate gaps.
Strauss Expires August 15, 2000 [Page 18]
Internet-Draft SMIng February 2000
Value Examples:
015 // illegal leading zero
-123 // illegal negative value
0xabc // illegal hexadecimal value length
0x8080000000 // legal hexadecimal value
Restriction Examples:
Unsigned64 (1..10000000000) // legal range spec
3.7 Float32
The Float32 base type represents floating point values of single
precision as described by [11].
Values of type Float32 may be denoted as a decimal fraction with an
optional exponent as known from many programming languages. See the
grammar rule `floatValue' of Appendix A for the detailed syntax.
Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the
Float32 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper
bound. If multiple values or ranges are given they all MUST be
disjunct and SHOULD be in ascending order. If a value restriction
is applied to an already restricted type the new restriction MUST be
more limiting, that is raising the lower bounds, reducing the upper
bounds, reducing the alternative choices, or splitting ranges into
multiple ranges with intermediate gaps. The special values `snan',
`qnan', `neginf', and `posinf' must be explicitly listed in
restrictions if they shall be included, where `snan' and `qnan'
cannot be used in ranges.
Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float32.
Note also that most floating point encodings disallow the
representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be
handled with care.
Value Examples:
Strauss Expires August 15, 2000 [Page 19]
Internet-Draft SMIng February 2000
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
Restriction Examples:
Float32 (-1.0..1.0) // legal range spec
Float32 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float32 (-10.0..10.0 | 0) // illegal overlapping
3.8 Float64
The Float64 base type represents floating point values of double
precision as described by [11].
Values of type Float64 may be denoted as a decimal fraction with an
optional exponent as known from many programming languages. See the
grammar rule `floatValue' of Appendix A for the detailed syntax.
Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the
Float64 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper
bound. If multiple values or ranges are given they all MUST be
disjunct and SHOULD be in ascending order. If a value restriction
is applied to an already restricted type the new restriction MUST be
more limiting, that is raising the lower bounds, reducing the upper
bounds, reducing the alternative choices, or splitting ranges into
multiple ranges with intermediate gaps. The special values `snan',
`qnan', `neginf', and `posinf' must be explicitly listed in
restrictions if they shall be included, where `snan' and `qnan'
cannot be used in ranges. If 0.0 is included, -0.0 will also be.
Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float64.
Note also that most floating point encodings disallow the
representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be
handled with care.
Value Examples:
Strauss Expires August 15, 2000 [Page 20]
Internet-Draft SMIng February 2000
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
Restriction Examples:
Float64 (-1.0..1.0) // legal range spec
Float64 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float64 (-10.0..10.0 | 0) // illegal overlapping
3.9 Float128
The Float128 base type represents floating point values of quadruple
precision as described by [11].
Values of type Float128 may be denoted as a decimal fraction with an
optional exponent as known from many programming languages. See the
grammar rule `floatValue' of Appendix A for the detailed syntax.
Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the
Float128 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper
bound. If multiple values or ranges are given they all MUST be
disjunct and SHOULD be in ascending order. If a value restriction
is applied to an already restricted type the new restriction MUST be
more limiting, that is raising the lower bounds, reducing the upper
bounds, reducing the alternative choices, or splitting ranges into
multiple ranges with intermediate gaps. The special values `snan',
`qnan', `neginf', and `posinf' must be explicitly listed in
restrictions if they shall be included, where `snan' and `qnan'
cannot be used in ranges. If 0.0 is included, -0.0 will also be.
Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float128.
Note also that most floating point encodings disallow the
representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be
handled with care.
Value Examples:
Strauss Expires August 15, 2000 [Page 21]
Internet-Draft SMIng February 2000
00.1 // illegal leading zero
3.1415 // legal value
-2.5E+3 // legal negative exponential value
Restriction Examples:
Float128 (-1.0..1.0) // legal range spec
Float128 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float128 (-10.0..10.0 | 0) // illegal overlapping
3.10 Enumeration
The Enumeration base type represents values from a set of integers
in the range between -2^31 (-2147483648) and 2^31-1 (2147483647),
where each value has an assigned name. The list of those named
numbers has to be comma-separated, enclosed in parenthesis and
appended to the `Enumeration' keyword. Each named number is denoted
by its lower-case identifier followed by the assigned integer value,
denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed
in parenthesis. Every name and every number in an enumeration type
MUST be unique. It is RECOMMENDED that values start at 1 and be
numbered contiguously.
Values of enumeration types may be denoted as decimal or
`0x'-prefixed hexadecimal numbers or preferably as their assigned
names.
When defining a type derived (directly or indirectly) from an
enumeration type, the set of named numbers may be restricted by
removing one or more named numbers. But no named numbers may be
added or changed regarding its name, value, or both.
Type and Value Examples:
Enumeration (up(1), down(2), testing(3))
0 // illegal, value 0 out of range
up // legal value given by name
2 // legal value given by number
3.11 Bits
The Bits base type represents bit sets. That is, a Bits value is a
set of flags identified by small integer numbers starting at 0.
Each bit number has an assigned name. The list of those named
numbers has to be comma-separated, enclosed in parenthesis and
appended to the `Bits' keyword. Each named number is denoted by its
lower-case identifier followed by the assigned integer value,
denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed
Strauss Expires August 15, 2000 [Page 22]
Internet-Draft SMIng February 2000
in parenthesis. Every name and every number in a bits type MUST be
unique. It is RECOMMENDED that numbers start at 0 and be numbered
contiguously.
Values of bits types may be denoted as a comma-separated list of
decimal or `0x'-prefixed hexadecimal numbers or preferably their
assigned names enclosed in parenthesis. There MUST NOT be any
element (by name or number) listed more than once. It is RECOMMENDED
to list elements in ascending order, although the order is
semantically irrelevant.
When defining a type derived (directly or indirectly) from a bits
type, the set of named numbers may be restricted by removing one or
more named numbers. But no named numbers may be added or changed
regarding its name, value, or both.
Type and Value Examples:
Bits (readable(0), writeable(1), executable(2))
() // legal empty value
(readable, writeable, 2) // legal value
(0, readable, executable) // illegal, readable(0) appears twice
(writeable, 4) // illegal, element 4 out of range
3.12 Display Formats
Some SMIng definitions, namely scalar and columnar object
definitions and type definitions, allow the specification of a
format to be used, when a value of that object or an object of that
type is displayed. Format specifications are represented as textual
data.
When the object or type has an underlying base type of Integer32,
Integer64, Unsigned32, or Unsigned64, the format consists of an
integer-format specification, containing two parts. The first part
is a single character suggesting a display format, either: `x' for
hexadecimal, or `d' for decimal, or `o' for octal, or `b' for
binary. For all types, when rendering the value, leading zeros are
omitted, and for negative values, a minus sign is rendered
immediately before the digits. The second part is always omitted
for `x', `o' and `b', and need not be present for `d'. If present,
the second part starts with a hyphen and is followed by a decimal
number, which defines the implied decimal point when rendering the
value. For example `d-2' suggests that a value of 1234 be rendered
as `12.34'.
When the object or type has an underlying base type of OctetString,
the format consists of one or more octet-format specifications.
Strauss Expires August 15, 2000 [Page 23]
Internet-Draft SMIng February 2000
Each specification consists of five parts, with each part using and
removing zero or more of the next octets from the value and
producing the next zero or more characters to be displayed. The
octets within the value are processed in order of significance, most
significant first.
The five parts of a octet-format specification are:
1. the (optional) repeat indicator; if present, this part is a `*',
and indicates that the current octet of the value is to be used
as the repeat count. The repeat count is an unsigned integer
(which may be zero) which specifies how many times the remainder
of this octet-format specification should be successively
applied. If the repeat indicator is not present, the repeat
count is one.
2. the octet length: one or more decimal digits specifying the
number of octets of the value to be used and formatted by this
octet-specification. Note that the octet length can be zero.
If less than this number of octets remain in the value, then the
lesser number of octets are used.
3. the display format, either: `x' for hexadecimal, `d' for
decimal, `o' for octal, `a' for ASCII, or `t' for UTF-8 [12]. If
the octet length part is greater than one, and the display
format part refers to a numeric format, then network
byte-ordering (big-endian encoding) is used interpreting the
octets in the value. The octets processed by the `t' display
format do not necessarily form an integral number of UTF-8
characters. Trailing octets which do not form a valid UTF-8
encoded character are discarded.
4. the (optional) display separator character; if present, this
part is a single character which is produced for display after
each application of this octet-specification; however, this
character is not produced for display if it would be immediately
followed by the display of the repeat terminator character for
this octet specification. This character can be any character
other than a decimal digit and a `*'.
5. the (optional) repeat terminator character, which can be present
only if the display separator character is present and this
octet specification begins with a repeat indicator; if present,
this part is a single character which is produced after all the
zero or more repeated applications (as given by the repeat
count) of this octet specification. This character can be any
character other than a decimal digit and a `*'.
Output of a display separator character or a repeat terminator
Strauss Expires August 15, 2000 [Page 24]
Internet-Draft SMIng February 2000
character is suppressed if it would occur as the last character of
the display.
If the octets of the value are exhausted before all the octet format
specification have been used, then the excess specifications are
ignored. If additional octets remain in the value after
interpreting all the octet format specifications, then the last
octet format specification is re-interpreted to process the
additional octets, until no octets remain in the value.
Note that for some types (e.g. ObjectIdentifier) no format
specifications are defined and SHOULD be omitted. Implementations
MUST ignore format specifications they cannot interpret. Also note
that the SMIng grammar (Appendix A) does not specify the syntax of
format specifications.
Display Format Examples:
Base Type Format Example Value Rendered Value
----------- ------------------- ---------------- -----------------
OctetString 255a "Hello World." Hello World.
OctetString 1x: "Hello!" 48:65:6c:6c:6f:21
OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0
OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024
OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee
Integer32 d-2 1234 12.34
Strauss Expires August 15, 2000 [Page 25]
Internet-Draft SMIng February 2000
4. The SMIng File Structure
The topmost container of SMIng information is a file. An SMIng file
may contain zero, one or more modules. It is RECOMMENDED to separate
modules into files named by their modules, where possible. Though,
for dedicated purposes it may be reasonable to collect several
modules in a single file.
The top level SMIng construct is the `module' statement (Section 5)
that defines a single MIB module. A module contains a sequence of
sections in an obligatory order with different kinds of definitions.
Whether these sections contain statements or remain empty mainly
depends on the purpose of the module (see Section 2).
4.1 Comments
Comments can be included at any position in an SMIng file, except in
between the characters of a single token like those of a quoted
strings. However, it is RECOMMENDED that all substantive
descriptions be placed within an appropriate description clause.
Comments commence with a pair of adjacent slashes `//' and end at
the end of the line.
4.2 Statements and Arguments
SMIng has a very small set of basic grammar rules based on the
concept of statements. Each statement starts with a lower-case
keyword identifying the statement followed by a number (possibly
zero) of arguments. An argument may be quoted text, an identifier, a
value of any base type, a list of identifiers enclosed in
parenthesis `( )' or a statement block enclosed in curly braces `{
}'. Since statement blocks are valid arguments, it is possible to
nest statement sequences. Each statement is terminated by a
semicolon `;'.
The core set of statements may be extended using the SMIng
`extension' statement. See Section 6 and Section 16 for details.
At places where a statement is expected, but an unknown lower-case
word is read, those statements MUST be skipped up to the proper
semicolon, including nested statement blocks.
Strauss Expires August 15, 2000 [Page 26]
Internet-Draft SMIng February 2000
5. The module Statement
The `module' statement is used as a container of all definitions of
a single SMIng MIB module. It gets two arguments: an upper-case
module name and a statement block that contains mandatory and
optional statements and sections of statements in an obligatory
order:
module <MODULE-NAME> {
<optional import statements>
<organization statement>
<contact statement>
<description statement>
<optional reference statement>
<at least one revision statement>
<optional identity statement>
<optional extension statements>
<optional typedef statements>
<optional node/scalar/table statements>
<optional notification statements>
<optional group statements>
<optional compliance statements>
};
The optional `import' statements are followed by the mandatory
`organization', `contact', and `description' statements and the
optional `reference' statement, which in turn are followed by the
mandatory `revision' statements. This part defines the module's meta
information while the following sections contain its main
definitions.
See the `moduleStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `module' statement.
5.1 The module's import Statement
The optional module's `import' statement is used to import
descriptors from external modules into the local module's namespace.
It gets two arguments: the name of the external module and a
comma-separated list of one or more identifiers to be imported
enclosed in parenthesis.
Strauss Expires August 15, 2000 [Page 27]
Internet-Draft SMIng February 2000
Multiple `import' statements for the same module but with disjunct
lists of identifiers are allowed, though NOT RECOMMENDED. Anyhow,
the same identifier from the same module MUST NOT be imported
multiple times. To import identifiers with the same name from
different modules might be necessary and is allowed. To distinguish
them in the local module, they have to be referred by qualified
names. It is NOT RECOMMENDED to import identifiers not used in the
local module.
See the `importStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `import' statement.
5.2 The module's organization Statement
The module's `organization' statement, which must be present, gets
one argument which is used to specify a textual description of the
organization(s) under whose auspices this module was developed.
5.3 The module's contact Statement
The module's `contact' statement, which must be present, gets one
argument which is used to specify the name, postal address,
telephone number, and electronic mail address of the person to whom
technical queries concerning this revision of this module should be
sent.
5.4 The module's description Statement
The module's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the contents of this module.
5.5 The module's reference Statement
The module's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
management information, or some other document which provides
additional information relevant to this module.
5.6 The module's revision Statement
The module's `revision' statement is repeatedly used to specify the
editorial revisions of the module, including the initial revision.
It gets one argument which is a statement block that holds detailed
information in an obligatory order. A module MUST have at least one
initial `revision' statement. For every editorial change, a new one
MUST be added in front of the revisions sequence, so that all
revisions are in reverse chronological order.
Strauss Expires August 15, 2000 [Page 28]
Internet-Draft SMIng February 2000
See the `revisionStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `revision' statement.
5.6.1 The revision's date Statement
The revision's `date' statement, which must be present, gets one
argument which is used to specify the date and time of the revision
in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the
time `00:00'. The time is always given in UTC.
See the `date' rule of the SMIng grammar (Appendix A) for the formal
syntax of the revision's `date' statement.
5.6.2 The revision's description Statement
The revision's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the revision.
5.7 The module's identity Statement
The module's `identity' statement, which need not be present, gets
one argument which specifies a node identifier within the local
module, so that the object identifier of this node can be used to
identify the module.
5.8 Usage Example
Consider how a skeletal MIB module might be constructed: e.g.,
module FIZBIN-MIB {
import IRTF-NMRG-SMING (experimental);
organization
"IETF SNMPv2 Working Group,
IRTF Network Management Research Group (NMRG)";
contact
" Frank Strauss
Postal: TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
DE
Phone: +49 531 391-3266
EMail: strauss@ibr.cs.tu-bs.de";
Strauss Expires August 15, 2000 [Page 29]
Internet-Draft SMIng February 2000
description
"The MIB module for entities implementing
the xxxx protocol.";
reference
"RFC 2578, Section 5.7.";
revision {
date "1999-09-28";
description
"Conversion from SMIv2 to SMIng.";
};
revision {
date "1995-05-24 18:11";
description
"Revision for RFC 1902.";
};
revision {
date "1992-10-07 04:33";
description
"The initial version of this MIB module,
published in RFC 1442.";
};
identity fizbin;
// ... further definitions ...
}; // end of module FIZBIN-MIB.
Strauss Expires August 15, 2000 [Page 30]
Internet-Draft SMIng February 2000
6. The extension Statement
The `extension' statement is used to define new statements to be
used in the local module following this extension statement
definition or in external modules that may import this extension
statement definition. The `extension' statement gets two arguments:
a lower-case extension statement identifier and a statement block
that holds detailed extension information in an obligatory order.
Extension statement identifiers SHOULD NOT contain any upper-case
characters or hyphens.
Note that the SMIng extension feature does not allow to formally
specify the context, argument syntax and semantics of an extension.
Its only purpose is to declare the existence of an extension and to
allow a unique reference to an extension. See Section 16 for
detailed information on extensions and Section 14.3 for a common
example, the `agentcaps' extension.
See the `extensionStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `extension' statement.
6.1 The extension's status Statement
The extension's `status' statement, which need not be present, gets
one argument which is used to specify whether this extension
definition is current or historic. The value `current' means that
the definition is current and valid. The value `obsolete' means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated'
also indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
If the `status' statement is omitted, the status value `current' is
implied.
6.2 The extension's description Statement
The extension's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the extension statement.
It is RECOMMENDED to include information on the extension's context,
its semantics, and implementation conditions. See also Section 16.
6.3 The extension's reference Statement
The extension's `reference' statement, which need not be present,
Strauss Expires August 15, 2000 [Page 31]
Internet-Draft SMIng February 2000
gets one argument which is used to specify a textual cross-reference
to some other document, either another module which defines related
extension definitions, or some other document which provides
additional information relevant to this extension.
6.4 The extension's abnf Statement
The extension's `abnf' statement, which need not be present, gets
one argument which is used to specify a formal ABNF [8] grammar
definition of the extension.
Note that the `abnf' statement should contain only pure ABNF and no
additional text, though comments prefixed by semicolon are allowed
but should probably be moved to the description statement. Note also
that double quotes are not allowed inside textual descriptions which
are itself enclosed in double quotes. So they have to be replaced by
single quotes.
Strauss Expires August 15, 2000 [Page 32]
Internet-Draft SMIng February 2000
7. The typedef Statement
The `typedef' statement is used to define new data types to be used
in the local module or in external modules. It gets two arguments:
an upper-case type identifier and a statement block that holds
detailed type information in an obligatory order.
Type identifiers SHOULD NOT consist of all upper-case characters and
SHOULD NOT contain hyphens.
See the `typedefStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `typedef' statement.
7.1 The typedef's type Statement
The typedef's `type' statement, which must be present, gets one
argument which is used to specify the type from which this type is
derived. Optionally, type restrictions may be applied to the new
type by appending subtyping information according to the rules of
the base type. See Section 3 for SMIng base types and their type
restrictions.
7.2 The typedef's default Statement
The typedef's `default' statement, which need not be present, gets
one argument which is used to specify an acceptable default value
for objects of this type. A default value may be used at the
discretion of an agent when an object instance is created. That is,
the value is a "hint" to implementors.
The value of the `default' statement must, of course, correspond to
the (probably restricted) type specified in the typedef's `type'
statement.
The default value of a type may be overwritten by a default value of
an object of this type.
Note that for some types, default values make no sense, e.g.
IRTF-NMRG-SMING-TYPES::Counter32.
7.3 The typedef's format Statement
The typedef's `format' statement, which need not be present, gets
one argument which is used to give a hint as to how the value of an
instance of an object of this type might be displayed. See Section
3.12 for a description of format specifications.
If no format is specified, it is inherited from the type given in
the `type' statement. On the other hand, the format specification
Strauss Expires August 15, 2000 [Page 33]
Internet-Draft SMIng February 2000
of a type may be overwritten by a format specification of an object
of this type.
7.4 The typedef's units Statement
The typedef's `units' statement, which need not be present, gets one
argument which is used to specify a textual definition of the units
associated with objects of this type.
If no units are specified, they are inherited from the type given in
the `type' statement. On the other hand, the units specification of
a type may be overwritten by a units specification of an object of
this type.
The units specification has to be appropriate for values displayed
according to the typedef's format specification, if present. E.g.,
if the type defines frequency values of type Unsigned64 measured in
thousands of Hertz, the format specification should be `d-3' and the
units specification should be `Hertz' or `Hz'. If the format
specification would be omitted, the units specification should be
`Milli-Hertz' or `mHz'. MIB Authors should pay attention to keep
format and units specifications of type and object definitions
synced. Application implementors MUST NOT implement units
specifications without implementing format specifications.
7.5 The typedef's status Statement
The typedef's `status' statement, which need not be present, gets
one argument which is used to specify whether this type definition
is current or historic. The value `current' means that the
definition is current and valid. The value `obsolete' means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated'
also indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
Derived types SHOULD NOT be defined as `current' if their underlying
type is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be
defined as `deprecated' if their underlying type is `obsolete'.
Nevertheless, subsequent revisions of the underlying type cannot be
avoided, but SHOULD be taken into account in subsequent revisions of
the local module.
If the `status' statement is omitted, the status value `current' is
implied.
Strauss Expires August 15, 2000 [Page 34]
Internet-Draft SMIng February 2000
7.6 The typedef's description Statement
The typedef's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the newly defined type.
It is RECOMMENDED to include all semantic definitions necessary for
implementation, and to embody any information which would otherwise
be communicated in any commentary annotations associated with this
type definition.
7.7 The typedef's reference Statement
The typedef's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
type definitions, or some other document which provides additional
information relevant to this type definition.
7.8 Usage Examples
Strauss Expires August 15, 2000 [Page 35]
Internet-Draft SMIng February 2000
typedef RptrOperStatus {
type Enumeration (other(1), ok(2), rptrFailure(3),
groupFailure(4), portFailure(5),
generalFailure(6));
default other; // undefined by default.
status deprecated;
description
"A type to indicate the operational state
of a repeater.";
reference
"[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState.";
};
typedef DateAndTime {
type OctetString (8 | 11);
format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
status current; // could be omitted
description
"A date-time specification.
...
Note that if only local time is known, then timezone
information (fields 8-10) is not present.";
reference
"RFC 2579, SNMPv2-TC.DateAndTime.";
};
typedef Frequency {
type Unsigned64;
format "d-3"
units "Hertz";
description
"A wide-range frequency specification measured
in thousands of Hertz.";
};
Strauss Expires August 15, 2000 [Page 36]
Internet-Draft SMIng February 2000
8. The node Statement
The `node' statement is used to name and describe a node in the
object identifier tree, without associating object information with
this node. This may be useful to group definitions in a subtree of
related management information, or to uniquely define an identity of
arbitrary kind to be referenced in objects of type ObjectIdentifier.
The `node' statement gets two arguments: a lower-case node
identifier and a statement block that holds detailed node
information in an obligatory order.
See the `nodeStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `node' statement.
8.1 The node's oid Statement
The node's `oid' statement, which must be present, gets one argument
which specifies the object identifier value that is assigned to this
node.
8.2 The node's status Statement
The node's `status' statement, which need not be present, gets one
argument which is used to specify whether this node definition is
current or historic. The value `current' means that the definition
is current and valid. The value `obsolete' means the definition is
obsolete and should not be implemented and/or can be removed if
previously implemented. While the value `deprecated' also indicates
an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing
implementations.
If the `status' statement is omitted, the status value `current' is
implied.
8.3 The node's description Statement
The node's `description' statement, which must be present, gets one
argument which is used to specify a high-level textual description
of this node.
It is RECOMMENDED to include all semantics and purposes of this
node.
8.4 The node's reference Statement
The node's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
Strauss Expires August 15, 2000 [Page 37]
Internet-Draft SMIng February 2000
nodes, or some other document which provides additional information
relevant to this node.
8.5 Usage Examples
node iso { oid 1; };
node org { oid iso.3; };
node dod { oid org.6; };
node internet { oid dod.1; };
node zeroDotZero {
oid 0.0;
description "A value used for null identifiers.";
reference "RFC 2578, 2. Definitions.";
};
Strauss Expires August 15, 2000 [Page 38]
Internet-Draft SMIng February 2000
9. The scalar Statement
The `scalar' statement is used to define a scalar managed object.
The `scalar' statement gets two arguments: a lower-case scalar
identifier and a statement block that holds detailed object
information in an obligatory order.
See the `scalarStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `scalar' statement.
9.1 The scalar's oid Statement
The scalar's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this scalar object.
9.2 The scalar's type Statement
The scalar's `type' statement, which must be present, gets one
argument which is used to specify the data type of this scalar
object. Optionally, type restrictions may be applied to the type by
appending subtyping information according to the rules of the base
type. See Section 3 for SMIng base types and their type
restrictions.
9.3 The scalar's access Statement
The scalar's `access' statement, which must be present, gets one
argument which is used to specify whether it makes sense to read
and/or write an instance of the object, or to include its value in a
notification. This is the maximal level of access for the object.
This maximal level of access is independent of any administrative
authorization policy.
The value `readwrite' indicates that read and write access makes
sense. The value `readonly' indicates that read access makes sense,
but write access is never possible. The value `notifyonly' indicates
an object which is accessible only via a notification.
These values are ordered, from least to greatest access level:
`notifyonly', `readonly', `readwrite'.
9.4 The scalar's default Statement
The scalar's `default' statement, which need not be present, gets
one argument which is used to specify an acceptable default value
for this scalar object. A default value may be used at the
discretion of an agent when an object instance is created. That is,
the value is a "hint" to implementors.
Strauss Expires August 15, 2000 [Page 39]
Internet-Draft SMIng February 2000
The value of the `default' statement must, of course, correspond to
the (probably restricted) type specified in the scalar's `type'
statement.
The scalar's default value overrides the default value of the
underlying type definition, if both are present.
Note that for objects of some types, default values make no sense,
e.g. IRTF-NMRG-SMING-TYPES::Counter32.
9.5 The scalar's format Statement
The scalar's `format' statement, which need not be present, gets one
argument which is used to give a hint as to how the value of an
instance of this object might be displayed. See Section 3.12 for a
description of format specifications.
The scalar's format specification overrides the format specification
of the underlying type definition if both are present.
9.6 The scalar's units Statement
The scalar's `units' statement, which need not be present, gets one
argument which is used to specify a textual definition of the units
associated with this scalar object.
The scalar's units specification overrides the units specification
of the underlying type definition if both are present.
The units specification has to be appropriate for values displayed
according to the scalar's format specification if present. E.g., if
the scalar object represents a frequency value of type Unsigned64
measured in thousands of Hertz, the format specification should be
`d-3' and the units specification should be `Hertz' or `Hz'. If the
format specification would be omitted, the units specification
should be `Milli-Hertz' or `mHz'. MIB Authors should pay attention
to keep format and units specifications of type and object
definitions synced. Application implementors MUST NOT implement
units specifications without implementing format specifications.
9.7 The scalar's status Statement
The scalar's `status' statement, which need not be present, gets one
argument which is used to specify whether this scalar object
definition is current or historic. The value `current' means that
the definition is current and valid. The value `obsolete' means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated'
also indicates an obsolete definition, it permits new/continued
Strauss Expires August 15, 2000 [Page 40]
Internet-Draft SMIng February 2000
implementation in order to foster interoperability with
older/existing implementations.
Scalar objects SHOULD NOT be defined as `current' if their type is
`deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as
`deprecated' if their type is `obsolete'. Nevertheless, subsequent
revisions of used type definition cannot be avoided, but SHOULD be
taken into account in subsequent revisions of the local module.
If the `status' statement is omitted the status value `current' is
implied.
9.8 The scalar's description Statement
The scalar's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of this scalar object.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this scalar object.
9.9 The scalar's reference Statement
The scalar's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
scalar objects, or some other document which provides additional
information relevant to this scalar object.
9.10 Usage Examples
scalar dialCtlTrapEnable {
oid dialCtlConfiguration.2;
type Enumeration (enabled(1), disabled(2));
access readwrite;
default disabled;
description
"This object indicates whether dialCtlPeerCallInformation
and dialCtlPeerCallSetup traps should be generated for
all peers. If the value of this object is enabled(1),
traps will be generated for all peers. If the value
of this object is disabled(2), traps will be generated
only for peers having dialCtlPeerCfgTrapEnable set
to enabled(1).";
};
Strauss Expires August 15, 2000 [Page 41]
Internet-Draft SMIng February 2000
10. The table Statement
The `table' statement is used to define the root node of a table.
The `table' statement gets two arguments: a lower-case table
identifier and a statement block that holds detailed table
information in an obligatory order.
See the `tableStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `table' statement.
10.1 The table's oid Statement
The table's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this table node.
10.2 The table's status Statement
The table's `status' statement, which need not be present, gets one
argument which is used to specify whether this table definition is
current or historic. The value `current' means that the definition
is current and valid. The value `obsolete' means the definition is
obsolete and should not be implemented and/or can be removed if
previously implemented. While the value `deprecated' also indicates
an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing
implementations.
If the `status' statement is omitted the status value `current' is
implied.
10.3 The table's description Statement
The table's `description' statement, which must be present, gets one
argument which is used to specify a high-level textual description
of this table.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this table.
10.4 The table's reference Statement
The table's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
tables, or some other document which provides additional information
relevant to this table.
Strauss Expires August 15, 2000 [Page 42]
Internet-Draft SMIng February 2000
10.5 The table's row Statement
The table's `row' statement, which must be present, gets two
arguments: a lower-case row identifier and a statement block that
holds detailed row information in an obligatory order.
See the `rowStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `row' statement.
10.5.1 The row's oid Statement
The row's `oid' statement, which must be present, gets one argument
which specifies the object identifier value that is assigned to this
table row. Note that the object identifier of a table row MUST be
built be the table's object identifier followed by a `1'
sub-identifier.
10.5.2 Table Indexing Statements
SMIng offers five methods to supply table indexing information:
ordinary tables, table augmentations, sparse table augmentations,
table expansions, and reordered tables use different statements to
denote their indexing information. Each table row definition must
contain exactly one of the following indexing statements.
10.5.2.1 The row's index Statement for Table Indexing
The row's `index' statement, which is used to supply table indexing
information of base table rows, gets at least one argument that
specifies a comma-separated list of object identifiers, that are
used for table indexing, enclosed in parenthesis.
Under some circumstances, an optional `implied' keyword may be added
in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.4 for details.
10.5.2.2 The row's augments Statement for Table Indexing
The row's `augments' statement, which is used to supply table
indexing information of table rows that augment a base table row,
gets one argument that specifies the identifier of the table row to
be augmented. Note that a row augmentation cannot itself be
augmented. Anyhow, a base row may be augmented by multiple row
augmentations.
A row augmentation makes instances of subordinate columnar objects
identified according to the index specification of the base row
corresponding to the row named in the `augments' statement.
Further, instances of subordinate columnar objects of a row
Strauss Expires August 15, 2000 [Page 43]
Internet-Draft SMIng February 2000
augmentation exist according to the same semantics as instances of
subordinate columnar objects of the base row being augmented. As
such, note that creation of a base row implies the correspondent
creation of any row augmentations. Row augmentations MUST NOT be
used in row creation and deletion operations.
10.5.2.3 The row's sparse Statement for Table Indexing
The row's `sparse' statement, which is used to supply table indexing
information of table rows that sparsely augment a base table row,
gets one argument that specifies the identifier of the table row to
be sparsely augmented. Note that a sparse row augmentation cannot
itself be augmented. Anyhow, a base row may be augmented by multiple
row augmentations, sparsely or not.
A sparse row augmentation makes instances of subordinate columnar
objects identified, if present, according to the index specification
of the base row corresponding to the row named in the `sparse'
statement. Further, instances of subordinate columnar objects of a
sparse row augmentation exist according to the semantics as
instances of subordinate columnar objects of the base row and the
(non-formal) rules that confine the sparse relationship. As such,
note that creation of a sparse row augmentation may be implied by
the creation of a base row as well as done by an explicit creation.
However, if a base row gets deleted, any dependent sparse row
augmentations get also deleted implicitly.
10.5.2.4 The row's reorders Statement for Table Indexing
The row's `reorders' statement is used to supply table indexing
information of table rows, that contain exactly the same index
objects of a base table row, except in another order. It gets at
least two arguments. The first one specifies the identifier of the
base table row. The second one specifies a comma-separated list of
exactly those object identifiers of the base row's `index'
statement, but in the order to be used in this table. Note that a
reordered table cannot itself be reordered. Anyhow, a base row may
be used for multiple reordered tables.
Under some circumstances, an optional `implied' keyword may be added
in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.4 for details.
Instances of subordinate columnar objects of a reordered table exist
according to the same semantics as instances of subordinate columnar
objects of the base row. As such, note that creation of a base row
implies the correspondent creation of any related reordered table.
Rows or reordered tables MUST NOT be used in row creation and
deletion operations.
Strauss Expires August 15, 2000 [Page 44]
Internet-Draft SMIng February 2000
10.5.2.5 The row's expands Statement for Table Indexing
The row's `expands' statement is used to supply table indexing
information of table row expansions. Table row expansions use
exactly the same index objects of another row together with
additional indexing objects. Thus, the `expands' statement gets at
least two arguments. The first one specifies the identifier of the
related table row. The second one specifies a comma-separated list
of the additional object identifiers used for indexing. Note that an
expanded table may itself be expanded, and related rows may be used
for multiple table expansions.
Under some circumstances, an optional `implied' keyword may be added
in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.4 for details.
10.5.3 The row's create Statement
The row's `create' statement, which need not be present, gets no
argument. If the `create' statement is present, row creation (and
deletion) is possible.
10.5.4 The row's status Statement
The row's `status' statement, which need not be present, gets one
argument which is used to specify whether this row definition is
current or historic. The value `current' means that the definition
is current and valid. The value `obsolete' means the definition is
obsolete and should not be implemented and/or can be removed if
previously implemented. While the value `deprecated' also indicates
an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing
implementations.
If the `status' statement is omitted the status value `current' is
implied.
10.5.5 The row's description Statement
The row's `description' statement, which must be present, gets one
argument which is used to specify a high-level textual description
of this table row.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this table row. Especially, if the row's
indexing statement contains objects that are not columnar objects of
the row, it SHOULD be described how these objects are used in
uniquely identifying instances of the row's columnar objects.
Strauss Expires August 15, 2000 [Page 45]
Internet-Draft SMIng February 2000
10.5.6 The row's reference Statement
The row's `reference' statement, which need not be present, gets one
argument which is used to specify a textual cross-reference to some
other document, either another module which defines related table
rows, or some other document which provides additional information
relevant to this table row.
10.6 The table row's column Statement
The row's `column' statement is used to define a columnar managed
object. The `column' statement gets two arguments: a lower-case
column identifier and a statement block that holds detailed object
information in an obligatory order.
See the `columnStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `column' statement.
10.6.1 The column's oid Statement
The column's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this columnar object.
10.6.2 The column's type Statement
The column's `type' statement, which must be present, gets at least
one argument which is used to specify the data type of this columnar
object. Optionally, type restrictions may be applied to the type by
appending subtyping information according to the rules of the base
type. See Section 3 for SMIng base types and their type
restrictions.
10.6.3 The column's access Statement
The column's `access' statement, which must be present, gets one
argument which is used to specify whether it makes sense to read
and/or write an instance of the object, or to include its value in a
notification. This is the maximal level of access for the object.
This maximal level of access is independent of any administrative
authorization policy.
The value `readwrite' indicates that read and write access makes
sense. The value `readonly' indicates that read access makes sense,
but write access is never possible. The value `noaccess' indicates
an auxiliary object (see Section 2.4). The value `notifyonly'
indicates an object which is accessible only via a notification.
These values are ordered, from least to greatest access level:
Strauss Expires August 15, 2000 [Page 46]
Internet-Draft SMIng February 2000
`noaccess', `notifyonly', `readonly', `readwrite'.
10.6.4 The column's default Statement
The column's `default' statement, which need not be present, gets
one argument which is used to specify an acceptable default value
for this columnar object. A default value may be used at the
discretion of an agent when an object instance is created. That is,
the value is a "hint" to implementors.
The value of the `default' statement must, of course, correspond to
the (probably restricted) type specified in the column's `type'
statement.
The column's default value overrides the default value of the
underlying type definition if both are present.
Note that for objects of some types, default values make no sense,
e.g. IRTF-NMRG-SMING-TYPES::Counter32.
10.6.5 The column's format Statement
The column's `format' statement, which need not be present, gets one
argument which is used to give a hint as to how the value of an
instance of this object might be displayed. See Section 3.12 for a
description of format specifications.
The column's format specification overrides the format specification
of the underlying type definition if both are present.
10.6.6 The column's units Statement
The column's `units' statement, which need not be present, gets one
argument which is used to specify a textual definition of the units
associated with this columnar object.
The column's units specification overrides the units specification
of the underlying type definition if both are present.
The units specification has to be appropriate for values displayed
according to the column's format specification if present. E.g., if
the columnar object represents a frequency value of type Unsigned64
measured in thousands of Hertz, the format specification should be
`d-3' and the units specification should be `Hertz' or `Hz'. If the
format specification would be omitted the units specification should
be `Milli-Hertz' or `mHz'. MIB Authors should pay attention to keep
format and units specifications of type and object definitions
synced. Application implementors MUST NOT implement units
specifications without implementing format specifications.
Strauss Expires August 15, 2000 [Page 47]
Internet-Draft SMIng February 2000
10.6.7 The column's status Statement
The column's `status' statement, which need not be present, gets one
argument which is used to specify whether this columnar object
definition is current or historic. The value `current' means that
the definition is current and valid. The value `obsolete' means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated'
also indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
Columnar objects SHOULD NOT be defined as `current' if their type is
`deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as
`deprecated' if their type is `obsolete'. Nevertheless, subsequent
revisions of used type definition cannot be avoided, but SHOULD be
taken into account in subsequent revisions of the local module.
If the `status' statement is omitted the status value `current' is
implied.
10.6.8 The column's description Statement
The column's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of this columnar object.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this columnar object.
10.6.9 The column's reference Statement
The column's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
columnar objects, or some other document which provides additional
information relevant to this columnar object.
10.7 Usage Example
Consider how one might define a table and its subordinates. (This
example uses the RowStatus type defined in Section 14.2.)
scalar evalSlot {
oid eval.1;
type Integer32 (0..2147483647);
access readonly;
description
"The index number of the first unassigned entry in the
Strauss Expires August 15, 2000 [Page 48]
Internet-Draft SMIng February 2000
evaluation table, or the value of zero indicating that
all entries are assigned.
A management station should create new entries in the
evaluation table using this algorithm: first, issue a
management protocol retrieval operation to determine the
value of evalSlot; and, second, issue a management
protocol set operation to create an instance of the
evalStatus object setting its value to createAndGo(4) or
createAndWait(5). If this latter operation succeeds,
then the management station may continue modifying the
instances corresponding to the newly created conceptual
row, without fear of collision with other management
stations.";
};
table evalTable {
oid eval.2;
description
"The (conceptual) evaluation table.";
reference
"RFC 2578, 7.11.";
row evalEntry {
oid evalTable.1;
index (evalIndex);
create (evalStatus);
description
"An entry (conceptual row) in the evaluation table.";
column evalIndex {
oid evalEntry.1;
type Integer32 (1..2147483647);
access noaccess;
description
"The auxiliary variable used for identifying instances of
the columnar objects in the evaluation table.";
};
column evalString {
oid evalEntry.2;
type DisplayString;
access readwrite;
description
"The string to evaluate.";
};
column evalValue {
oid evalEntry.3;
Strauss Expires August 15, 2000 [Page 49]
Internet-Draft SMIng February 2000
type Integer32;
access readonly;
default 0;
description
"The value when evalString was last evaluated, or zero if
no such value is available.";
};
column evalStatus {
oid evalEntry.4;
type RowStatus;
access readwrite;
default active;
description
"The status column used for creating, modifying, and
deleting instances of the columnar objects in the
evaluation table.";
};
};
};
Strauss Expires August 15, 2000 [Page 50]
Internet-Draft SMIng February 2000
11. The notification Statement
The `notification' statement is used to define a notification. It
gets two arguments: a lower-case notification identifier and a
statement block that holds detailed information in an obligatory
order.
See the `notificationStatement' rule of the SMIng grammar (Appendix
A) for the formal syntax of the `notification' statement.
11.1 The notification's oid Statement
The notification's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this notification.
11.2 The notification's objects Statement
The notification's `objects' statement, which need not be present,
gets one argument which specifies an ordered sequence of objects by
their identifiers to be emitted within this notification. The list
of objects has to be comma-separated and enclosed in parenthesis.
One and only one object instance for each occurrence of each object
must be present, and in the specified order, in every instance of
the notification. If the same object occurs multiple times in a
notification's `objects' statement, then an object instance is
present for each of them. An object specified in this sequence must
not have an `access' statement argument of `noaccess'.
Note that an agent is allowed, at its own discretion, to append as
many additional objects as it considers useful to the end of the
notification (i.e., after the objects defined by the notification's
`objects' statement if present).
11.3 The notification's status Statement
The notification's `status' statement, which need not be present,
gets one argument which is used to specify whether this notification
definition is current or historic. The value `current' means that
the definition is current and valid. The value `obsolete' means the
definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated'
also indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with
older/existing implementations.
If the `status' statement is omitted the status value `current' is
implied.
Strauss Expires August 15, 2000 [Page 51]
Internet-Draft SMIng February 2000
11.4 The notification's description Statement
The notification's `description' statement, which must be present,
gets one argument which is used to specify a high-level textual
description of this notification.
It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this notification. In particular, it SHOULD be
documented which instances of the objects mentioned in the `objects'
statement should be contained within notifications of this type.
11.5 The notification's reference Statement
The notification's `reference' statement, which need not be present,
gets one argument which is used to specify a textual cross-reference
to some other document, either another module which defines related
notifications, or some other document which provides additional
information relevant to this notification.
11.6 Usage Example
Consider how a configuration change notification might be described:
node entityMIBTraps { oid entityMIB.2; };
node entityMIBTrapPrefix { oid entityMIBTraps.0; };
notification entConfigChange {
oid entityMIBTrapPrefix.1;
description
"An entConfigChange trap is sent when the value of
entLastChangeTime changes. It can be utilized by an NMS
to trigger logical/physical entity table maintenance
polls. An agent must not generate more than one
entConfigChange 'trap-event' in a five second period,
where a 'trap-event' is the transmission of a single
trap PDU to a list of trap destinations. If additional
configuration changes occur within the five second
'throttling' period then these trap-events should be
suppressed by the agent. An NMS should periodically
check the value of entLastChangeTime to detect any
missed entConfigChange trap-events, e.g. due to
throttling or transmission loss.";
};
Strauss Expires August 15, 2000 [Page 52]
Internet-Draft SMIng February 2000
12. The group Statement
The `group' statement is used to define a group of arbitrary nodes
in the object identifier tree. It gets two arguments: a lower-case
group identifier and a statement block that holds detailed group
information in an obligatory order.
Note that the primary application of groups are compliance
statements, although they might be referred in other formal or
informal documents.
See the `groupStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `group' statement.
12.1 The group's oid Statement
The group's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this group.
12.2 The group's members Statement
The group's `members' statement, which must be present, gets one
argument which specifies the list of nodes by their identifiers to
be contained in this group. The list of nodes has to be
comma-separated and enclosed in parenthesis.
12.3 The group's status Statement
The group's `status' statement, which need not be present, gets one
argument which is used to specify whether this group definition is
current or historic. The value `current' means that the definition
is current and valid. The value `obsolete' means the definition is
obsolete and the group should no longer be used. While the value
`deprecated' also indicates an obsolete definition, it permits
new/continued use of this group.
If the `status' statement is omitted the status value `current' is
implied.
12.4 The group's description Statement
The group's `description' statement, which must be present, gets one
argument which is used to specify a high-level textual description
of this group. It is RECOMMENDED to include any relation to other
groups.
Strauss Expires August 15, 2000 [Page 53]
Internet-Draft SMIng February 2000
12.5 The group's reference Statement
The group's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related
groups, or some other document which provides additional information
relevant to this group.
12.6 Usage Example
The snmpGroup, originally defined in [13], may be described as
follows:
group snmpGroup {
oid snmpMIBGroups.8;
objects (snmpInPkts, snmpInBadVersions,
snmpInASNParseErrs,
snmpSilentDrops, snmpProxyDrops,
snmpEnableAuthenTraps);
description
"A collection of objects providing basic
instrumentation and control of an agent.";
};
Strauss Expires August 15, 2000 [Page 54]
Internet-Draft SMIng February 2000
13. The compliance Statement
The `compliance' statement is used to define a set of compliance
requirements, named a `compliance statement'. It gets two arguments:
a lower-case compliance identifier and a statement block that holds
detailed compliance information in an obligatory order.
See the `complianceStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `compliance' statement.
13.1 The compliance's oid Statement
The compliance's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is
assigned to this compliance statement.
13.2 The compliance's status Statement
The compliance's `status' statement, which need not be present, gets
one argument which is used to specify whether this compliance
statement is current or historic. The value `current' means that the
definition is current and valid. The value `obsolete' means the
definition is obsolete and no longer specifies a valid definition of
conformance. While the value `deprecated' also indicates an
obsolete definition, it permits new/continued use of the compliance
specification.
If the `status' statement is omitted the status value `current' is
implied.
13.3 The compliance's description Statement
The compliance's `description' statement, which must be present,
gets one argument which is used to specify a high-level textual
description of this compliance statement.
13.4 The compliance's reference Statement
The compliance's `reference' statement, which need not be present,
gets one argument which is used to specify a textual cross-reference
to some other document, either another module which defines related
compliance statements, or some other document which provides
additional information relevant to this compliance statement.
13.5 The compliance's mandatory Statement
The compliance's `mandatory' statement, which need not be present,
gets one argument which is used to specify a comma-separated list of
one or more groups (Section 12) of objects and/or notifications
Strauss Expires August 15, 2000 [Page 55]
Internet-Draft SMIng February 2000
enclosed in parenthesis. These groups are unconditionally mandatory
for implementation.
If an agent claims compliance to a MIB module then it must implement
each and every object and notification within each group listed the
`mandatory' statement(s) of the compliance statement(s) of that
module.
13.6 The compliance's optional Statement
The compliance's `optional' statement, which need not be present, is
repeatedly used to name each group which is conditionally mandatory
for compliance to the module. It can also be used to name
unconditionally optional groups. A group named in an `optional'
statement MUST be absent from the correspondent `mandatory'
statement. The `optional' statement gets two arguments: a lower-case
group identifier and a statement block that holds detailed
compliance information on that group.
Conditionally mandatory groups include those which are mandatory
only if a particular protocol is implemented, or only if another
group is implemented. The `description' statement specifies the
conditions under which the group is conditionally mandatory.
A group which is named in neither a `mandatory' statement nor an
`optional' statement, is unconditionally optional for compliance to
the module.
See the `optionalStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `optional' statement.
13.6.1 The optional's description Statement
The optional's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the conditions under which this group is
conditionally mandatory or unconditionally optional.
13.7 The compliance's refine Statement
The compliance's `refine' statement, which need not be present, is
repeatedly used to specify each object for which compliance has a
refined requirement with respect to the module definition. The
object must be present in one of the conformance groups named in the
correspondent `mandatory' or `optional' statements. The `refine'
statement gets two arguments: a lower-case identifier of a scalar or
columnar object and a statement block that holds detailed refinement
information on that object.
Strauss Expires August 15, 2000 [Page 56]
Internet-Draft SMIng February 2000
See the `refineStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `refine' statement.
13.7.1 The refine's type Statement
The refine's `type' statement, which need not be present, gets one
argument that is used to provide a refined type for the
correspondent object. Type restrictions may be applied by appending
subtyping information according to the rules of the base type. See
Section 3 for SMIng base types and their type restrictions.
Note that if a `type' and a `writetype' statement are both present
then this type only applies when instances of the correspondent
object are read.
13.7.2 The refine's writetype Statement
The refine's `writetype' statement, which need not be present, gets
one argument that is used to provide a refined type for the
correspondent object, only when instances of that object are
written. Type restrictions may be applied by appending subtyping
information according to the rules of the base type. See Section 3
for SMIng base types and their type restrictions.
13.7.3 The refine's access Statement
The refine's `access' statement, which need not be present, gets one
argument that is used to specify the minimal level of access that
the correspondent object must implement in the sense of its original
`access' statement. Hence, the refine's `access' statement MUST NOT
specify a greater level of access than is specified in the
correspondent object definition.
An implementation is compliant if the level of access it provides is
greater or equal to the minimal level in the refine's `access'
statement and less or equal to the maximal level in the object's
`access' statement.
13.7.4 The refine's description Statement
The refine's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual
description of the refined compliance requirement.
13.8 Usage Example
The compliance statement contained in the SNMPv2-MIB, converted to
SMIng:
Strauss Expires August 15, 2000 [Page 57]
Internet-Draft SMIng February 2000
compliance snmpBasicCompliance {
oid snmpMIBCompliances.2;
description
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 MIB.";
mandatory (snmpGroup, snmpSetGroup, systemGroup,
snmpBasicNotificationsGroup);
optional snmpCommunityGroup {
description
"This group is mandatory for SNMPv2 entities which
support community-based authentication.";
};
};
Strauss Expires August 15, 2000 [Page 58]
Internet-Draft SMIng February 2000
14. SMIng Core Modules
MIB modules, either SMIv1, SMIv2 or SMIng, are built on top of some
core definitions. These core definitions are imported from some
"well-defined" core modules. In case of SMIng, there are two core
modules:
1. IRTF-NMRG-SMING, which defines a special node, named
`zeroDotZero' that may be used by objects of type
`ObjectIdentifier' as a null value, and a core set of 18 nodes
near the root of the object identifier tree. Only some of those
core nodes are significant for the Internet management and have
been described in Section 2.2.
2. IRTF-NMRG-SMING-TYPES, which defines SMIng data types. Regarding
to their origin, these types can be divided into two groups:
those being ASN.1 application types defined as SMIv2 core types
[2] and those being textual conventions in SMIv2 [3]. For use in
SMIng, there is no need to care about these differences, though
it might be useful in SNMP applications, to know that some types
are distinguishable "on the wire" and others are not.
3. IRTF-NMRG-SMING-EXTENSIONS, which defines proposed SMIng
extensions. At this moment, there is only one extension, the
`agentcaps' statement. See Section 16 for details on extensions.
14.1 IRTF-NMRG-SMING
module IRTF-NMRG-SMING {
//
// $RCSfile: IRTF-NMRG-SMING,v $
// $Revision: 817 $
// $Author: strauss $
// $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $
//
organization "IRTF Network Management Research Group (NMRG),
Network Management Group, TU Braunschweig";
contact " Frank Strauss
Postal: TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3266
EMail: strauss@ibr.cs.tu-bs.de";
Strauss Expires August 15, 2000 [Page 59]
Internet-Draft SMIng February 2000
description "Core node definitions for SMIng.";
revision {
date "2000-02-13";
description "SMIng grammar dropped module identity objects.";
};
revision {
date "1999-05-07";
description "Initial Revision.";
};
node ccitt { oid 0; };
node zeroDotZero {
oid 0.0;
description "A value used for null identifiers.";
};
node iso { oid 1; };
node org { oid iso.3; };
node dod { oid org.6; };
node internet { oid dod.1; };
node directory { oid internet.1; };
node mgmt { oid internet.2; };
node mib-2 { oid mgmt.1; };
node transmission { oid mib-2.10; };
node experimental { oid internet.3; };
node private { oid internet.4; };
node enterprises { oid private.1; };
node security { oid internet.5; };
node snmpV2 { oid internet.6; };
node snmpDomains { oid snmpV2.1; };
node snmpProxys { oid snmpV2.2; };
node snmpModules { oid snmpV2.3; };
node joint-iso-ccitt { oid 2; };
};
14.2 IRTF-NMRG-SMING-TYPES
module IRTF-NMRG-SMING-TYPES {
//
// $RCSfile: IRTF-NMRG-SMING-TYPES,v $
// $Revision: 817 $
// $Author: strauss $
// $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $
Strauss Expires August 15, 2000 [Page 60]
Internet-Draft SMIng February 2000
//
organization "IRTF Network Management Research Group (NMRG),
Network Management Group, TU Braunschweig";
contact " Frank Strauss
Postal: TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3266
EMail: strauss@ibr.cs.tu-bs.de";
description "Core type definitions for SMIng.";
revision {
date "2000-02-13";
description "SMIng grammar dropped module identity objects.";
};
revision {
date "1999-05-07";
description "Initial Revision.";
};
typedef Gauge32 {
type Unsigned32;
description
"The Gauge32 type represents a non-negative integer,
which may increase or decrease, but shall never
exceed a maximum value, nor fall below a minimum
value. The maximum value can not be greater than
2^32-1 (4294967295 decimal), and the minimum value
can not be smaller than 0. The value of a Gauge32
has its maximum value whenever the information
being modeled is greater than or equal to its
maximum value, and has its minimum value whenever
the information being modeled is smaller than or
equal to its minimum value. If the information
being modeled subsequently decreases below
(increases above) the maximum (minimum) value, the
Gauge32 also decreases (increases). (Note that
despite of the use of the term `latched' in the
original definition of this type, it does not
become `stuck' at its maximum or minimum value.)";
reference
"RFC 2578, Sections 2. and 7.1.7.";
Strauss Expires August 15, 2000 [Page 61]
Internet-Draft SMIng February 2000
};
typedef Counter32 {
type Unsigned32;
description
"The Counter32 type represents a non-negative integer
which monotonically increases until it reaches a
maximum value of 2^32-1 (4294967295 decimal), when it
wraps around and starts increasing again from zero.
Counters have no defined `initial' value, and thus, a
single value of a Counter has (in general) no
information content. Discontinuities in the
monotonically increasing value normally occur at
re-initialization of the management system, and at
other times as specified in the description of an
object using this type. If such other times can
occur, for example, the creation of an object
instance at times other than re-initialization, then
a corresponding object should be defined, with an
appropriate type, to indicate the last discontinuity.
Examples of appropriate types include: TimeStamp,
DateAndTime or TimeTicks (other types defined in this
module).
The value of the access statement for objects with a
type value of Counter32 should be either `readonly'
or `notifyonly'.
A default statement should not be used for objects
with a type value of Counter32.";
reference
"RFC 2578, Sections 2. and 7.1.6.";
};
typedef Gauge64 {
type Unsigned64;
description
"The Gauge64 type represents a non-negative integer,
which may increase or decrease, but shall never
exceed a maximum value, nor fall below a minimum
value. The maximum value can not be greater than
2^64-1 (18446744073709551615), and the minimum value
can not be smaller than 0. The value of a Gauge64
has its maximum value whenever the information
being modeled is greater than or equal to its
maximum value, and has its minimum value whenever
the information being modeled is smaller than or
equal to its minimum value. If the information
Strauss Expires August 15, 2000 [Page 62]
Internet-Draft SMIng February 2000
being modeled subsequently decreases below
(increases above) the maximum (minimum) value, the
Gauge64 also decreases (increases). (Note that
despite of the use of the term `latched' in the
original definition of this type, it does not
become `stuck' at its maximum or minimum value.)";
};
typedef Counter64 {
type Unsigned64;
description
"The Counter64 type represents a non-negative integer
which monotonically increases until it reaches a
maximum value of 2^64-1 (18446744073709551615), when
it wraps around and starts increasing again from zero.
Counters have no defined `initial' value, and thus, a
single value of a Counter has (in general) no
information content. Discontinuities in the
monotonically increasing value normally occur at
re-initialization of the management system, and at
other times as specified in the description of an
object using this type. If such other times can
occur, for example, the creation of an object
instance at times other than re-initialization, then
a corresponding object should be defined, with an
appropriate type, to indicate the last discontinuity.
Examples of appropriate types include: TimeStamp,
DateAndTime or TimeTicks (other types defined in this
module).
The value of the access statement for objects with a
type value of Counter64 should be either `readonly'
or `notifyonly'.
A default statement should not be used for objects
with a type value of Counter64.";
reference
"RFC 2578, Sections 2. and 7.1.10.";
};
typedef Opaque {
type OctetString;
description
"The Opaque type is provided solely for
backward-compatibility, and shall not be used for
newly-defined object types.
The Opaque type supports the capability to pass
Strauss Expires August 15, 2000 [Page 63]
Internet-Draft SMIng February 2000
arbitrary ASN.1 syntax. A value is encoded using
the ASN.1 Basic Encoding Rules into a string of
octets. This, in turn, is encoded as an
OctetString, in effect `double-wrapping' the
original ASN.1 value.
Note that a conforming implementation need only be
able to accept and recognize opaquely-encoded data.
It need not be able to unwrap the data and then
interpret its contents.
A requirement on `standard' MIB modules is that no
object may have a type value of Opaque.";
reference
"RFC 2578, Sections 2. and 7.1.9.";
};
typedef IpAddress {
type OctetString (4);
status deprecated;
description
"******* THIS TYPE DEFINITION IS DEPRECATED *******
The IpAddress type represents a 32-bit internet
IPv4 address. It is represented as an OctetString
of length 4, in network byte-order.
Note that the IpAddress type is present for
historical reasons. IPv4 and IPv6 addresses should
be represented using the IpAddr type. Generic
Network addresses should be represented using a
pair of TDomain and TAddress types (all defined in
this module).";
reference
"RFC 2578, Sections 2. and 7.1.5.";
};
typedef TimeTicks {
type Unsigned32;
description
"The TimeTicks type represents a non-negative
integer which represents the time, modulo 2^32
(4294967296 decimal), in hundredths of a second
between two epochs. When objects are defined which
use this type, the description of the object
identifies both of the reference epochs.
For example, the TimeStamp type (defined in this
module) is based on the TimeTicks type.
Strauss Expires August 15, 2000 [Page 64]
Internet-Draft SMIng February 2000
With a TimeStamp, the first reference epoch is
defined as the time when SNMPv2-MIB::sysUpTime was
zero, and the second reference epoch is defined as
the current value of sysUpTime.
The TimeTicks type should not be sub-typed.";
reference
"RFC 2578, Sections 2. and 7.1.8.";
};
//
// The following type definitions are plain
// conversions of the textual conventions from
// the SNMPv2-TC module (RFC 2579).
//
typedef DisplayString {
type OctetString (0..255);
format "255a";
description
"Represents textual information taken from the NVT ASCII
character set, as defined in pages 4, 10-11 of RFC 854.
To summarize RFC 854, the NVT ASCII repertoire specifies:
- the use of character codes 0-127 (decimal)
- the graphics characters (32-126) are interpreted as
US ASCII
- NUL, LF, CR, BEL, BS, HT, VT and FF have the special
meanings specified in RFC 854
- the other 25 codes have no standard interpretation
- the sequence 'CR LF' means newline
- the sequence 'CR NUL' means carriage-return
- an 'LF' not preceded by a 'CR' means moving to the
same column on the next line.
- the sequence 'CR x' for any x other than LF or NUL is
illegal. (Note that this also means that a string may
end with either 'CR LF' or 'CR NUL', but not with CR.)
Any object defined using this syntax may not exceed 255
characters in length.";
};
Strauss Expires August 15, 2000 [Page 65]
Internet-Draft SMIng February 2000
typedef PhysAddress {
type OctetString;
format "1x:";
description
"Represents media- or physical-level addresses.";
};
typedef MacAddress {
type OctetString (6);
format "1x:";
description
"Represents an 802 MAC address represented in the
`canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though
802.5 (in contrast to other 802.x protocols) requires MAC
addresses to be transmitted most significant bit first.";
};
typedef TruthValue {
type Enumeration (true(1), false(2));
description
"Represents a boolean value.";
};
typedef TestAndIncr {
type Integer32 (0..2147483647);
description
"Represents integer-valued information used for atomic
operations. When the management protocol is used to specify
that an object instance having this syntax is to be
modified, the new value supplied via the management protocol
must precisely match the value presently held by the
instance. If not, the management protocol set operation
fails with an error of `inconsistentValue'. Otherwise, if
the current value is the maximum value of 2^31-1 (2147483647
decimal), then the value held by the instance is wrapped to
zero; otherwise, the value held by the instance is
incremented by one. (Note that regardless of whether the
management protocol set operation succeeds, the variable-
binding in the request and response PDUs are identical.)
The value of the ACCESS clause for objects having this
syntax is either `read-write' or `read-create'. When an
instance of a columnar object having this syntax is created,
any value may be supplied via the management protocol.
When the network management portion of the system is re-
initialized, the value of every object instance having this
syntax must either be incremented from its value prior to
Strauss Expires August 15, 2000 [Page 66]
Internet-Draft SMIng February 2000
the re-initialization, or (if the value prior to the re-
initialization is unknown) be set to a pseudo-randomly
generated value.";
};
typedef AutonomousType {
type ObjectIdentifier;
description
"Represents an independently extensible type identification
value. It may, for example, indicate a particular sub-tree
with further MIB definitions, or define a particular type of
protocol or hardware.";
};
typedef InstancePointer {
type ObjectIdentifier;
status obsolete;
description
"A pointer to either a specific instance of a MIB object or
a conceptual row of a MIB table in the managed device. In
the latter case, by convention, it is the name of the
particular instance of the first accessible columnar object
in the conceptual row.
The two uses of this textual convention are replaced by
VariablePointer and RowPointer, respectively.";
};
typedef VariablePointer {
type ObjectIdentifier;
description
"A pointer to a specific object instance. For example,
sysContact.0 or ifInOctets.3.";
};
typedef RowPointer {
type ObjectIdentifier;
description
"Represents a pointer to a conceptual row. The value is the
name of the instance of the first accessible columnar object
in the conceptual row.
For example, ifIndex.3 would point to the 3rd row in the
ifTable (note that if ifIndex were not-accessible, then
ifDescr.3 would be used instead).";
};
typedef RowStatus {
type Enumeration (active(1), notInService(2),
Strauss Expires August 15, 2000 [Page 67]
Internet-Draft SMIng February 2000
notReady(3), createAndGo(4),
createAndWait(5), destroy(6));
description
"The RowStatus textual convention is used to manage the
creation and deletion of conceptual rows, and is used as the
value of the SYNTAX clause for the status column of a
conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is
available for use by the managed device;
- `notInService', which indicates that the conceptual
row exists in the agent, but is unavailable for use by
the managed device (see NOTE below);
- `notReady', which indicates that the conceptual row
exists in the agent, but is missing information
necessary in order to be available for use by the
managed device;
- `createAndGo', which is supplied by a management
station wishing to create a new instance of a
conceptual row and to have its status automatically set
to active, making it available for use by the managed
device;
- `createAndWait', which is supplied by a management
station wishing to create a new instance of a
conceptual row (but not make it available for use by
the managed device); and,
- `destroy', which is supplied by a management station
wishing to delete all of the instances associated with
an existing conceptual row.
Whereas five of the six values (all except `notReady') may
be specified in a management protocol set operation, only
three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by the
managed device (the status column has value `active'); it is
not available for use by the managed device, though the
agent has sufficient information to make it so (the status
column has value `notInService'); or, it is not available
Strauss Expires August 15, 2000 [Page 68]
Internet-Draft SMIng February 2000
for use by the managed device, and an attempt to make it so
would fail because the agent has insufficient information
(the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table,
irrespective of whether the values of that table's
conceptual rows are able to be modified while it is
active, or whether its conceptual rows must be taken
out of service in order to be modified. That is, it is
the responsibility of the DESCRIPTION clause of the
status column to specify whether the status column must
not be `active' in order for the value of some other
column of the same conceptual row to be modified. If
such a specification is made, affected columns may be
changed by an SNMP set PDU if the RowStatus would not
be equal to `active' either immediately before or after
processing the PDU. In other words, if the PDU also
contained a varbind that would change the RowStatus
value, the column in question may be changed if the
RowStatus was not equal to `active' as the PDU was
received, or if the varbind sets the status to a value
other than 'active'.
Also note that whenever any elements of a row exist, the
RowStatus column must also exist.
To summarize the effect of having a conceptual row with a
status column having a SYNTAX clause value of RowStatus,
consider the following state diagram:
STATE
+--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
Strauss Expires August 15, 2000 [Page 69]
Internet-Draft SMIng February 2000
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the
agent.
(2) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, then return noError and goto D.
(3) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be
either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding
RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's
value, or
noError: because the agent chooses to create the
instance.
Strauss Expires August 15, 2000 [Page 70]
Internet-Draft SMIng February 2000
If noError is returned, then the instance of the status
column must also be created, and the new state is B or C,
depending on the information available to the agent. If
inconsistentName or inconsistentValue is returned, the row
remains in state A.
(5) depending on the MIB definition for the column/table,
either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following
errors:
wrongValue: because the agent does not support
createAndWait, or
inconsistentValue: because the agent is unable to take
the row out of service at this time, perhaps because it
is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to
remove the row at this time, perhaps because it is in
use and cannot be de-activated.
NOTE: Other processing of the set request may result in a
response other than noError being returned, e.g.,
wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any
objects for which the agent does not supply a default; and,
making the conceptual row available for use by the managed
device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies
for each conceptual row. In some cases, the instance-
identifier is semantically significant, e.g., the
destination address of a route, and a management station
selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to
distinguish conceptual rows, and a management station
Strauss Expires August 15, 2000 [Page 71]
Internet-Draft SMIng February 2000
without specific knowledge of the conceptual row might
examine the instances present in order to determine an
unused instance-identifier. (This approach may be used, but
it is often highly sub-optimal; however, it is also a
questionable practice for a naive management station to
attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row
might provide one or more objects which provide assistance
in determining an unused instance-identifier. For example,
if the conceptual row is indexed by an integer-value, then
an object having an integer-valued SYNTAX clause might be
defined for such a purpose, allowing a management station to
issue a management protocol retrieval operation. In order
to avoid unnecessary collisions between competing management
stations, `adjacent' retrievals of this object should be
different.
Finally, the management station could select a pseudo-random
number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in
response to the management protocol set operation, the
management station should simply select a new pseudo-random
number and retry the operation.
A MIB designer should choose between the two latter
algorithms based on the size of the table (and therefore the
efficiency of each algorithm). For tables in which a large
number of entries are expected, it is recommended that a MIB
object be defined that returns an acceptable index for
creation. For tables with small numbers of entries, it is
recommended that the latter pseudo-random index mechanism be
used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the
management station determines if it wishes to create and
activate the conceptual row in one transaction or in a
negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column
requirements, i.e., it must determine those columns for
which it must or must not provide values. Depending on the
complexity of the table and the management station's
knowledge of the agent's capabilities, this determination
Strauss Expires August 15, 2000 [Page 72]
Internet-Draft SMIng February 2000
can be made locally by the management station. Alternately,
the management station issues a management protocol get
operation to examine all columns in the conceptual row that
it wishes to create. In response, for each column, there
are three possible outcomes:
- a value is returned, indicating that some other
management station has already created this conceptual
row. We return to interaction 1.
- the exception `noSuchInstance' is returned,
indicating that the agent implements the object-type
associated with this column, and that this column in at
least one conceptual row would be accessible in the MIB
view used by the retrieval were it to exist. For those
columns to which the agent provides read-create access,
the `noSuchInstance' exception tells the management
station that it should supply a value for this column
when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating
that the agent does not implement the object-type
associated with this column or that there is no
conceptual row for which this column would be
accessible in the MIB view used by the retrieval. As
such, the management station can not issue any
management protocol set operations to create an
instance of this column.
Once the column requirements have been determined, a
management protocol set operation is accordingly issued.
This operation also sets the new instance of the status
column to `createAndGo'.
When the agent processes the set operation, it verifies that
it has sufficient information to make the conceptual row
available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the
conceptual row, and, implementation-specific defaults
supplied by the agent (note that an agent must provide
implementation-specific defaults for at least those objects
which it implements as read-only). If there is sufficient
information available, then the conceptual row is created, a
`noError' response is returned, the status column is set to
`active', and no further interactions are necessary (i.e.,
interactions 3 and 4 are skipped). If there is insufficient
information, then the conceptual row is not created, and the
Strauss Expires August 15, 2000 [Page 73]
Internet-Draft SMIng February 2000
set operation fails with an error of `inconsistentValue'.
On this error, the management station can issue a management
protocol retrieval operation to determine if this was
because it failed to specify a value for a required column,
or, because the selected instance of the status column
already existed. In the latter case, we return to
interaction 1. In the former case, the management station
can re-issue the set operation with the additional
information, or begin interaction 2 again using
`createAndWait' in order to negotiate creation of the
conceptual row.
NOTE WELL
Regardless of the method used to determine the column
requirements, it is possible that the management
station might deem a column necessary when, in fact,
the agent will not allow that particular columnar
instance to be created or written. In this case, the
management protocol set operation will fail with an
error such as `noCreation' or `notWritable'. In this
case, the management station decides whether it needs
to be able to set a value for that particular columnar
instance. If not, the management station re-issues the
management protocol set operation, but without setting
a value for that particular columnar instance;
otherwise, the management station aborts the row
creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual
Row
The management station issues a management protocol set
operation which sets the desired instance of the status
column to `createAndWait'. If the agent is unwilling to
process a request of this sort, the set operation fails with
an error of `wrongValue'. (As a consequence, such an agent
must be prepared to accept a single management protocol set
operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is
returned, and the status column is immediately set to either
`notInService' or `notReady', depending on whether it has
sufficient information to make the conceptual row available
for use by the managed device. If there is sufficient
information available, then the status column is set to
Strauss Expires August 15, 2000 [Page 74]
Internet-Draft SMIng February 2000
`notInService'; otherwise, if there is insufficient
information, then the status column is set to `notReady'.
Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column
requirements. It issues a management protocol get operation
to examine all columns in the created conceptual row. In
the response, for each column, there are three possible
outcomes:
- a value is returned, indicating that the agent
implements the object-type associated with this column
and had sufficient information to provide a value. For
those columns to which the agent provides read-create
access (and for which the agent allows their values to
be changed after their creation), a value return tells
the management station that it may issue additional
management protocol set operations, if it desires, in
order to change the value associated with this column.
- the exception `noSuchInstance' is returned,
indicating that the agent implements the object-type
associated with this column, and that this column in at
least one conceptual row would be accessible in the MIB
view used by the retrieval were it to exist. However,
the agent does not have sufficient information to
provide a value, and until a value is provided, the
conceptual row may not be made available for use by the
managed device. For those columns to which the agent
provides read-create access, the `noSuchInstance'
exception tells the management station that it must
issue additional management protocol set operations, in
order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating
that the agent does not implement the object-type
associated with this column or that there is no
conceptual row for which this column would be
accessible in the MIB view used by the retrieval. As
such, the management station can not issue any
management protocol set operations to create an
instance of this column.
If the value associated with the status column is
`notReady', then the management station must first deal with
all `noSuchInstance' columns, if any. Having done so, the
Strauss Expires August 15, 2000 [Page 75]
Internet-Draft SMIng February 2000
value of the status column becomes `notInService', and we
proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values
associated with the columns of the conceptual row, it issues
a management protocol set operation to set the status column
to `active'. If the agent has sufficient information to
make the conceptual row available for use by the managed
device, the management protocol set operation succeeds (a
`noError' response is returned). Otherwise, the management
protocol set operation fails with an error of
`inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value
`notInService' or `notReady' is unavailable to the
managed device. As such, it is possible for the
managed device to create its own instances during the
time between the management protocol set operation
which sets the status column to `createAndWait' and the
management protocol set operation which sets the status
column to `active'. In this case, when the management
protocol set operation is issued to set the status
column to `active', the values held in the agent
supersede those used by the managed device.
If the management station is prevented from setting the
status column to `active' (e.g., due to management station
or network failure) the conceptual row will be left in the
`notInService' or `notReady' state, consuming resources
indefinitely. The agent must detect conceptual rows that
have been in either state for an abnormally long period of
time and remove them. It is the responsibility of the
DESCRIPTION clause of the status column to indicate what an
abnormally long period of time would be. This period of
time should be long enough to allow for human response time
(including `think time') between the creation of the
conceptual row and the setting of the status to `active'.
In the absence of such information in the DESCRIPTION
clause,
it is suggested that this period be approximately 5 minutes
in length. This removal action applies not only to newly-
created rows, but also to previously active rows which are
set to, and left in, the notInService state for a prolonged
period exceeding that which is considered normal for such a
Strauss Expires August 15, 2000 [Page 76]
Internet-Draft SMIng February 2000
conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station
may issue a management protocol set operation which sets the
instance of the status column to `notInService'. If the
agent is unwilling to do so, the set operation fails with an
error of `wrongValue' or `inconsistentValue'.
Otherwise, the conceptual row is taken out of service, and a
`noError' response is returned. It is the responsibility of
the DESCRIPTION clause of the status column to indicate
under what circumstances the status column should be taken
out of service (e.g., in order for the value of some other
column of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set
operation is issued which sets the instance of the status
column to `destroy'. This request may be made regardless of
the current value of the status column (e.g., it is possible
to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds, then
all instances associated with the conceptual row are
immediately removed.";
};
typedef TimeStamp {
type TimeTicks;
description
"The value of the sysUpTime object at which a specific
occurrence happened. The specific occurrence must be
defined in the description of any object defined using this
type. When the specific occurrence occurred prior to the
last time sysUpTime was zero, then the TimeStamp value is
zero. Note that this requires all TimeStamp values to be
reset to zero when the value of sysUpTime reaches 497+ days
and wraps around to zero.";
};
typedef TimeInterval {
type Integer32 (0..2147483647);
description
"A period of time, measured in units of 0.01 seconds.";
};
typedef DateAndTime {
Strauss Expires August 15, 2000 [Page 77]
Internet-Draft SMIng February 2000
type OctetString (8 | 11);
format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
description
"A date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC* 0..13
10 11 minutes from UTC 0..59
* Notes:
- the value of year is in big-endian encoding
- daylight saving time in New Zealand is +13
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone
information (fields 8-10) is not present.";
};
typedef StorageType {
type Enumeration (other(1), volatile(2),
nonVolatile(3), permanent(4),
readOnly(5));
description
"Describes the memory realization of a conceptual row. A
row which is volatile(2) is lost upon reboot. A row which
is either nonVolatile(3), permanent(4) or readOnly(5), is
backed up by stable storage. A row which is permanent(4)
can be changed but not deleted. A row which is readOnly(5)
cannot be changed nor deleted.
If the value of an object with this syntax is either
permanent(4) or readOnly(5), it cannot be modified.
Conversely, if the value is either other(1), volatile(2) or
nonVolatile(3), it cannot be modified to be permanent(4) or
readOnly(5). (All illegal modifications result in a
Strauss Expires August 15, 2000 [Page 78]
Internet-Draft SMIng February 2000
'wrongValue' error.)
Every usage of this textual convention is required to
specify the columnar objects which a permanent(4) row must
at a minimum allow to be writable.";
};
typedef TDomain {
type ObjectIdentifier;
description
"Denotes a kind of transport service.
Some possible values, such as snmpUDPDomain, are defined in
'Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)'.";
};
typedef TAddress {
type OctetString (1..255);
description
"Denotes a transport service address.
For snmpUDPDomain, a TAddress is 6 octets long, the initial
4 octets containing the IP-address in network-byte order and
the last 2 containing the UDP port in network-byte order.
Cosult 'Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2)' for further
information on snmpUDPDomain.";
};
};
14.3 IRTF-NMRG-SMING-EXTENSIONS
module IRTF-NMRG-SMING-EXTENSIONS {
//
// $RCSfile: IRTF-NMRG-SMING-EXTENSIONS,v $
// $Revision: 817 $
// $Author: strauss $
// $Date: 2000-02-15 11:41:02 +0100 (Tue, 15 Feb 2000) $
//
organization "IRTF Network Management Research Group (NMRG),
Network Management Group, TU Braunschweig";
contact " Frank Strauss
Postal: TU Braunschweig
Strauss Expires August 15, 2000 [Page 79]
Internet-Draft SMIng February 2000
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3266
EMail: strauss@ibr.cs.tu-bs.de";
description "Core extension definitions for SMIng.";
revision {
date "2000-02-13";
description "SMIng grammar dropped module identity objects.";
};
revision {
date "1999-05-07";
description "Initial Revision.";
};
extension agentcaps {
status current;
description
"The agentcaps extension statement is used to describe
an agent's deviation from the compliance statements
of the modules it implements. It is designed to be
compatible with the SMIv2 AGENT-CAPABILITIES macro.
The agentcaps extension statement should only be used
in the statement body of a module that does not
contain any other type or node definitions that do not
correspond to an agent implementation.";
reference
"RFC 2580, Section 6 describes the SMIv2
compatible AGENT-CAPABILITIES macro.";
abnf
"agentcapsStatement = 'agentcaps' sep lcIdentifier
optsep '{' stmtsep
oidStatement stmtsep
releaseStatement stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
*(includesStatement stmtsep)
'}' optsep ';'
includesStatement = 'includes' sep qlcIdentifier
optsep '{' stmtsep
*(variationStatement stmtsep)
'}' optsep ';'
Strauss Expires August 15, 2000 [Page 80]
Internet-Draft SMIng February 2000
variationStatement = 'variation' sep qlcIdentifier
optsep '{' stmtsep
typeStatement stmtsep
writetypeStatement stmtsep
accessStatement stmtsep
createStatement stmtsep
'}' optsep ';'
";
};
};
Strauss Expires August 15, 2000 [Page 81]
Internet-Draft SMIng February 2000
15. Extending a Module
As experience is gained with a module, it may be desirable to revise
that module. However, changes are not allowed if they have any
potential to cause interoperability problems between an
implementation using an original specification and an implementation
using an updated specification(s).
For any change, some statements near the top of the module MUST be
updated to include information about the revision: specifically, a
new `revision' statement (Section 5.6) must be included in front of
the `revision' statements. Furthermore, any necessary changes MUST
be applied to other statements, including the `organization' and
`contact' statements (Section 5.2, Section 5.3).
Note that any definition contained in a module is available to be
imported by any other module, and is referenced in an `import'
statement via the module name. Thus, a module name MUST NOT be
changed. Specifically, the module name (e.g., `FIZBIN-MIB' in the
example of Section 5.8) MUST NOT be changed when revising a module
(except to correct typographical errors), and definitions MUST NOT
be moved from one module to another.
Also note, that obsolete definitions MUST NOT be removed from
modules since their descriptors may still be referenced by other
modules, and the object identifiers used to name them MUST never be
re-assigned.
A definition may be revised in any of the following ways:
o In `typedef', `scalar' and `column' statement blocks, a `type'
statement containing an `Enumeration' or `Bits' type may have new
named numbers added.
o In `typedef', `scalar' and `column' statement blocks, the value
of a `type' statement may be replaced by another type if the new
type is derived (directly or indirectly) from the same base type,
has the same set of values, and has identical semantics.
o In any statement block, a `status' statement value of `current'
(or a missing `status' statement) may be revised as `deprecated'
or `obsolete'. Similarly, a `status' statement value of
`deprecated' may be revised as `obsolete'. When making such a
change, the `description' statement SHOULD be updated to explain
the rationale.
o In `typedef', `scalar' and `column' statement blocks, a `default'
statement may be added or updated.
Strauss Expires August 15, 2000 [Page 82]
Internet-Draft SMIng February 2000
o In any statement block, a `reference' statement may be added or
updated.
o In `typedef', `scalar' and `column' statement blocks, a `units'
statement may be added.
o A row may be augmented by adding new columnar objects (`column'
statements) at the end of the row's statement block.
o In any statement block, clarifications and additional information
may be included in the `description' statement.
o Entirely new extensions, types, nodes, scalar objects, tables,
groups, or compliance statements may be defined, using previously
unassigned identifiers and object identifier values.
Otherwise, if the semantics of any previous definition are changed
(i.e., if a non-editorial change is made to any definition other
than those specifically allowed above), then the `oid' statement
value associated with that object MUST also be changed.
Note that changing the identifier associated with an existing object
is considered a semantic change, as these strings may be used in an
`import' statement.
Strauss Expires August 15, 2000 [Page 83]
Internet-Draft SMIng February 2000
16. SMIng Language Extensibility
While SMIng has a well defined set of statements (Section 5 through
Section 13) that are used to specify those aspects of management
information commonly regarded as necessary, there may be further
information, people wish to express. To describe additional
information informally in description statements has the
disadvantage, that this information cannot be parsed by any program.
SMIng allows modules to include statements that are unknown to a
parser but fulfill some core grammar rules (Section 4.2).
Furthermore, additional statements may be defined by the `extension'
statement (Section 6). Extensions can be used in the local module or
in other modules, that import the extension. This has some
advantages:
o A parser can differentiate between statements known as extensions
and unknown statements. This enables the parser to complain about
unknown statements, e.g. due to typos.
o If an extension's definition contains a formal ABNF grammar
definition and a parser is able to interpret this ABNF
definition, this enables the parser also to complain about wrong
usage of an extension.
o Since, there might be some common need for extensions, there is a
relatively high probability of extension name collisions
originated by different organizations, as long as there is no
standardized extension for that purpose. The requirement to
explicitly import extension statements allows to distinguish
those extensions.
o The supported extensions of an SMIng implementation, e.g. a MIB
compiler, can be clearly expressed.
The only formal effect of an extension statement definition is to
declare its existence and its status, and optionally its ABNF
grammar. All additional aspects SHOULD be described in the
`description' statement:
o The detailed semantics of the new statement SHOULD be described.
o The contexts in which the new statement can be used, SHOULD be
described, e.g., a new statement may be designed to be used only
in the statement block of a module, but not in other nested
statement blocks. Others may be applicable in multiple contexts.
In addition, the point in the sequence of an obligatory order of
other statements, where the new statement may be inserted, might
be prescribed.
Strauss Expires August 15, 2000 [Page 84]
Internet-Draft SMIng February 2000
o The circumstances that make the new statement mandatory or
optional SHOULD be described.
o The syntax of the new statement SHOULD at least be described
informally, if not supplied formally in an `abnf' statement.
o It might be reasonable to give some suggestions under which
conditions the implementation of the new statement is adequate
and how it could be integrated into existent implementations.
Some possible extension applications might be:
o Agent capabilities statements, that allow to describe an agent
implemention's deviation from the compliance statements of the
modules they implement. SMIv2 has a regular AGENT-CAPABILITIES
construct [4], though it's rarely used. That's why it's not a
common SMIng statement. Instead, it is defined as an `agentcaps'
extension statement in the module IRTF-NMRG-SMING-EXTENSIONS
(Section 14.3).
o Inlined annotations to definitions. E.g., a vendor may wish to
describe additional information to object definitions in private
modules. An example are severity levels of notifications in the
statement block of a `notification' statement.
o Arbitrary annotations to external definitions. E.g., a vendor may
wish to describe additional information to object definitions in
a "standard" module. This allows a vendor to implement "standard"
modules as well as additional private features, without redundant
MIB definitions, but on top of "standard" MIB definitions.
Strauss Expires August 15, 2000 [Page 85]
Internet-Draft SMIng February 2000
17. Module Conversions
17.1 Converting SMIv2 to SMIng
Conversions of SMIv2 modules to SMIng are feasible. The only SMIv2
construct that cannot be mapped to an SMIng statement is the
AGENT-CAPABILITIES macro. However, this can be mapped to the
`agentcaps' extension. All other constructs and types are directly
mappable without loss of information.
Detailed mapping information is subject to a future document.
17.2 Converting SMIng to SMIv2
SMIng is more liberal in some aspects to ensure a more consistent
information model and a short grammar with less exceptions. This
leads to a limited backwards convertability to SMIv2 of different
kinds of identifiers, groups, type definition hierarchies, octet
string length limitations, and object identifier values (those with
a single sub-identifier). Some other information gets lost when
being converted to SMIv2: some occurences of references, units,
formats, default values, table indexing information, and table row
creation information.
Detailed mapping information is subject to a future document.
17.3 SMIv1
Conversions between SMIv1 and SMIng are not covered by this
document. Anyhow, conversions between SMIv1 and SMIv2 are subject to
SMIv2 and partly described in [14]. Conversions between SMIv2 and
SMIng are covered in the sections above.
In few words, conversion from SMIv1 to SMIng is not possible in some
cases and without some additional information. Conversion from SMIng
to SMIv1 is possible if 64 bit types and floating point data types
are not used and if identifiers conform to the SMIv1 restrictions.
Strauss Expires August 15, 2000 [Page 86]
Internet-Draft SMIng February 2000
18. Security Considerations
This document defines a language with which to write and read
descriptions of management information. The language itself has no
security impact on the Internet.
Strauss Expires August 15, 2000 [Page 87]
Internet-Draft SMIng February 2000
19. Acknowledgements
This document is originated as a central part of a master's thesis
at the Technical University of Braunschweig, under the guidance of
Juergen Schoenwaelder.
Since SMIng represents a successor of SMIv2, a huge amount of
paragraphs and phrases are taken from the SMIv2 specifications [2],
[3], [4] written by Jeff Case, Keith McCloghrie, David Perkins,
Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser.
Finally, Marshall T. Rose's work on an XML framework for RFC authors
[15] made the writing of an Internet standards document much more
feasible.
Thanks to these people and the authors of these documents.
Strauss Expires August 15, 2000 [Page 88]
Internet-Draft SMIng February 2000
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., Waldbusser, S., "Structure of Management Information
Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
[3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., Waldbusser, S., "Textual Conventions for SMIv2", RFC 2579,
STD 59, April 1999.
[4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., Waldbusser, S., "Conformance Statements for SMIv2", RFC
2580, STD 60, April 1999.
[5] Rose, M., McCloghrie, K., "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155,
STD 16, May 1990.
[6] Rose, M., McCloghrie, K., "Concise MIB Definitions", RFC 1212,
STD 16, March 1991.
[7] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[8] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[9] International Organization for Standardization, "Specification
of Abstract Syntax Notation One (ASN.1)", International
Standard 8824, December 1987.
[10] Harrington, D., Presuhn, R., Wijnen, B., "An Architecture for
Describing SNMP Management Frameworks", RFC 2271, January 1999.
[11] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
Standard 754-1985, August 1985.
[12] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[13] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,
"Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
[14] Wijnen, B., Levi, D., "V2ToV1 - Mapping SNMPv2 onto SNMPv1
Strauss Expires August 15, 2000 [Page 89]
Internet-Draft SMIng February 2000
within a bi-lingual SNMP agent", RFC 2089, January 1997.
[15] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999.
Author's Address
Frank Strauss
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3266
EMail: strauss@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Strauss Expires August 15, 2000 [Page 90]
Internet-Draft SMIng February 2000
Appendix A. The SMIng ABNF grammar
The SMIng grammar conforms to the Augmented Backus-Naur Form
(ABNF)[8], with one exception: For readability, keywords are
represented as quoted strings, although ABNF would declare these
strings to be case-insensitive. Anyhow, SMIng keyword are meant to
be case-sensitive.
;;
;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234).
;;
;; @(#) $Id: draft-irtf-nmrg-sming-02.txt 817 2000-02-15 10:41:02Z strauss $
;;
;; Copyright (C) The Internet Society (1999). All Rights Reserved.
;;
smingFile = optsep *(moduleStatement optsep)
;;
;; Statement rules.
;;
moduleStatement = moduleKeyword sep ucIdentifier optsep "{" stmtsep
*(importStatement stmtsep)
organizationStatement stmtsep
contactStatement stmtsep
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
1*(revisionStatement stmtsep)
*1(identityStatement stmtsep)
*(extensionStatement stmtsep)
*(typedefStatement stmtsep)
*(anyObjectStatement stmtsep)
*(notificationStatement stmtsep)
*(groupStatement stmtsep)
*(complianceStatement stmtsep)
"}" optsep ";"
extensionStatement = extensionKeyword sep lcIdentifier optsep
"{" stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
*1(abnfStatement stmtsep)
"}" optsep ";"
typedefStatement = typedefKeyword sep ucIdentifier optsep
"{" stmtsep
typedefTypeStatement stmtsep
Strauss Expires August 15, 2000 [Page 91]
Internet-Draft SMIng February 2000
*1(defaultStatement stmtsep)
*1(formatStatement stmtsep)
*1(unitsStatement stmtsep)
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
anyObjectStatement = nodeStatement /
scalarStatement /
tableStatement
nodeStatement = nodeKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
*1(statusStatement stmtsep)
*1(descriptionStatement stmtsep)
*1(referenceStatement stmtsep)
"}" optsep ";"
scalarStatement = scalarKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
typeStatement stmtsep
accessStatement stmtsep
*1(defaultStatement stmtsep)
*1(formatStatement stmtsep)
*1(unitsStatement stmtsep)
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
tableStatement = tableKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
rowStatement stmtsep
"}" optsep ";"
rowStatement = rowKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
anyIndexStatement stmtsep
*1(createStatement stmtsep)
*1(statusStatement stmtsep)
descriptionStatement stmtsep
Strauss Expires August 15, 2000 [Page 92]
Internet-Draft SMIng February 2000
*1(referenceStatement stmtsep)
1*(columnStatement stmtsep)
"}" optsep ";"
columnStatement = columnKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
typeStatement stmtsep
accessStatement stmtsep
*1(defaultStatement stmtsep)
*1(formatStatement stmtsep)
*1(unitsStatement stmtsep)
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
notificationStatement = notificationKeyword sep lcIdentifier
optsep "{" stmtsep
oidStatement stmtsep
*1(objectsStatement stmtsep)
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
groupStatement = groupKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
membersStatement stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
"}" optsep ";"
complianceStatement = complianceKeyword sep lcIdentifier optsep
"{" stmtsep
oidStatement stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep
*1(referenceStatement stmtsep)
*1(mandatoryStatement stmtsep)
*(optionalStatement stmtsep)
*(refineStatement stmtsep)
"}" optsep ";"
importStatement = importKeyword sep ucIdentifier optsep
"(" optsep
identifierList optsep
Strauss Expires August 15, 2000 [Page 93]
Internet-Draft SMIng February 2000
")" optsep ";"
revisionStatement = revisionKeyword optsep "{" stmtsep
dateStatement stmtsep
descriptionStatement stmtsep
"}" optsep ";"
identityStatement = identityKeyword sep lcIdentifier optsep ";"
typedefTypeStatement = typeKeyword sep refinedBaseType optsep ";"
typeStatement = typeKeyword sep
(refinedBaseType / refinedType)
optsep ";"
writetypeStatement = writetypeKeyword sep
(refinedBaseType / refinedType)
optsep ";"
anyIndexStatement = indexStatement /
augmentsStatement /
reordersStatement /
sparseStatement /
expandsStatement
indexStatement = indexKeyword *1(sep impliedKeyword) optsep
"(" optsep qlcIdentifierList
optsep ")" optsep ";"
augmentsStatement = augmentsKeyword sep qlcIdentifier
optsep ";"
reordersStatement = reordersKeyword sep qlcIdentifier
*1(sep impliedKeyword)
optsep "(" optsep
qlcIdentifierList optsep ")"
optsep ";"
sparseStatement = sparseKeyword sep qlcIdentifier optsep ";"
expandsStatement = expandsKeyword sep qlcIdentifier
*1(sep impliedKeyword)
optsep "(" optsep
qlcIdentifierList optsep ")"
optsep ";"
createStatement = createKeyword optsep ";"
oidStatement = oidKeyword sep objectIdentifier optsep ";"
Strauss Expires August 15, 2000 [Page 94]
Internet-Draft SMIng February 2000
dateStatement = dateKeyword sep date optsep ";"
organizationStatement = organizationKeyword sep text optsep ";"
contactStatement = contactKeyword sep text optsep ";"
formatStatement = formatKeyword sep format optsep ";"
unitsStatement = unitsKeyword sep units optsep ";"
statusStatement = statusKeyword sep status optsep ";"
accessStatement = accessKeyword sep access optsep ";"
defaultStatement = defaultKeyword sep anyValue optsep ";"
descriptionStatement = descriptionKeyword sep text optsep ";"
referenceStatement = referenceKeyword sep text optsep ";"
abnfStatement = abnfKeyword sep text optsep ";"
membersStatement = membersKeyword optsep "(" optsep
qlcIdentifierList optsep
")" optsep ";"
objectsStatement = objectsKeyword optsep "(" optsep
qlcIdentifierList optsep
")" optsep ";"
mandatoryStatement = mandatoryKeyword optsep "(" optsep
qlcIdentifierList optsep
")" optsep ";"
optionalStatement = optionalKeyword sep qlcIdentifier optsep
"{" descriptionStatement stmtsep
"}" optsep ";"
refineStatement = refineKeyword sep qlcIdentifier optsep "{"
*1(typeStatement stmtsep)
*1(writetypeStatement stmtsep)
*1(accessStatement stmtsep)
descriptionStatement stmtsep
"}" optsep ";"
;;
;;
;;
Strauss Expires August 15, 2000 [Page 95]
Internet-Draft SMIng February 2000
refinedBaseType = OctetStringKeyword *1(optsep numberSpec) /
ObjectIdentifierKeyword /
Integer32Keyword *1(optsep numberSpec) /
Unsigned32Keyword *1(optsep numberSpec) /
Integer64Keyword *1(optsep numberSpec) /
Unsigned64Keyword *1(optsep numberSpec) /
Float32Keyword *1(optsep floatSpec) /
Float64Keyword *1(optsep floatSpec) /
Float128Keyword *1(optsep floatSpec) /
EnumerationKeyword optsep namedNumberSpec /
// TODO: inserted optsep, do also in parser grammar!
BitsKeyword optsep namedNumberSpec
// TODO: inserted optsep, do also in parser grammar!
refinedType = qucIdentifier *1(optsep anySpec)
anySpec = numberSpec / floatSpec
numberSpec = "(" optsep numberElement
*furtherNumberElement
optsep ")"
furtherNumberElement = optsep "|" optsep numberElement
numberElement = signedNumber *1numberUpperLimit
numberUpperLimit = optsep ".." optsep signedNumber
floatSpec = "(" optsep floatElement
*furtherFloatElement
optsep ")"
furtherFloatElement = optsep "|" optsep floatElement
floatElement = floatValue *1floatUpperLimit
floatUpperLimit = optsep ".." optsep floatValue
namedNumberSpec = "(" optsep namedNumberList optsep ")"
namedNumberList = namedNumberItem
*(optsep "," optsep namedNumberItem)
*1(optsep ",")
namedNumberItem = lcIdentifier optsep "(" optsep number
optsep ")"
identifierList = identifier
*(optsep "," optsep identifier)
Strauss Expires August 15, 2000 [Page 96]
Internet-Draft SMIng February 2000
*1(optsep ",")
qIdentifierList = qIdentifier
*(optsep "," optsep qIdentifier)
*1(optsep ",")
qlcIdentifierList = qlcIdentifier
*(optsep "," optsep qlcIdentifier)
*1(optsep ",")
bitsValue = "(" optsep bitsList optsep ")"
bitsList = *1(lcIdentifier
*(optsep "," optsep lcIdentifier))
*1(optsep ",")
;;
;; Other basic rules.
;;
identifier = ucIdentifier / lcIdentifier
qIdentifier = qucIdentifier / qlcIdentifier
ucIdentifier = ucAlpha *63(ALPHA / DIGIT / "-")
qucIdentifier = *1(ucIdentifier "::") ucIdentifier
lcIdentifier = lcAlpha *63(ALPHA / DIGIT / "-")
qlcIdentifier = *1(ucIdentifier "::") lcIdentifier
text = textSegment *(optsep textSegment)
textSegment = DQUOTE *textAtom DQUOTE
textAtom = textVChar / HTAB / SP / lineBreak
date = DQUOTE 4DIGIT "-" 2DIGIT "-" 2DIGIT
*1(" " 2DIGIT ":" 2DIGIT)
DQUOTE
; always in UTC
format = textSegment
units = textSegment
anyValue = bitsValue /
negativeNumber /
Strauss Expires August 15, 2000 [Page 97]
Internet-Draft SMIng February 2000
hexadecimalNumber /
floatValue /
text /
objectIdentifier
; Note: `objectIdentifer' includes the
; syntax of enumeration labels and postive
; numbers. They are not named literally to
; avoid reduce/reduce conflicts when
; building LR parsers based on this
; grammar.
status = currentKeyword /
deprecatedKeyword /
obsoleteKeyword
access = noaccessKeyword /
notifyonlyKeyword /
readonlyKeyword /
readwriteKeyword
objectIdentifier = (qlcIdentifier / subid) *127("." subid)
subid = decimalNumber
number = hexadecimalNumber / decimalNumber
negativeNumber = "-" decimalNumber
signedNumber = number / negativeNumber
decimalNumber = "0" / (nonZeroDigit *DIGIT)
zeroDecimalNumber = 1*DIGIT
hexadecimalNumber = "0x" 1*(HEXDIG HEXDIG)
floatValue = neginfKeyword /
posinfKeyword /
snanKeyword /
qnanKeyword /
signedNumber "." zeroDecimalNumber
*1("E" ("+"/"-") zeroDecimalNumber)
;;
;; Rules to skip unknown statements
;; with arbitrary arguments and blocks.
;;
unknownStatement = unknownKeyword optsep *unknownArgument
Strauss Expires August 15, 2000 [Page 98]
Internet-Draft SMIng February 2000
optsep ";"
unknownArgument = ("(" optsep unknownList optsep ")") /
("{" optsep *unknownStatement optsep "}") /
qucIdentifier /
anyValue /
anySpec
unknownList = namedNumberList /
qIdentifierList
unknownKeyword = lcIdentifier
;;
;; Keyword rules.
;;
;; Typically, keywords are represented by tokens returned from the
;; lexical analyzer. Note, that the lexer has to be stateful to
;; distinguish keywords from identifiers depending on the context
;; position in the input stream.
;;
;; Also note, that these keyword definitions are represented in
;; cleartext for readability, while SMIng keywords are meant to be
;; case-sensitive, although ABNF makes quoted strings like these to
;; be case-insensitive.
;;
;; Statement keywords.
moduleKeyword = "module"
importKeyword = "import"
revisionKeyword = "revision"
oidKeyword = "oid"
dateKeyword = "date"
organizationKeyword = "organization"
contactKeyword = "contact"
descriptionKeyword = "description"
referenceKeyword = "reference"
identityKeyword = "identity"
extensionKeyword = "extension"
typedefKeyword = "typedef"
typeKeyword = "type"
writetypeKeyword = "writetype"
nodeKeyword = "node"
scalarKeyword = "scalar"
tableKeyword = "table"
columnKeyword = "column"
rowKeyword = "row"
notificationKeyword = "notification"
Strauss Expires August 15, 2000 [Page 99]
Internet-Draft SMIng February 2000
groupKeyword = "group"
complianceKeyword = "compliance"
formatKeyword = "format"
unitsKeyword = "units"
statusKeyword = "status"
accessKeyword = "access"
defaultKeyword = "default"
impliedKeyword = "implied"
indexKeyword = "index"
augmentsKeyword = "augments"
reordersKeyword = "reorders"
sparseKeyword = "sparse"
expandsKeyword = "expands"
createKeyword = "create"
membersKeyword = "members"
objectsKeyword = "objects"
mandatoryKeyword = "mandatory"
optionalKeyword = "optional"
refineKeyword = "refine"
abnfKeyword = "abnf"
;; Base type keywords.
OctetStringKeyword = "OctetString"
ObjectIdentifierKeyword = "ObjectIdentifier"
Integer32Keyword = "Integer32"
Unsigned32Keyword = "Unsigned32"
Integer64Keyword = "Integer64"
Unsigned64Keyword = "Unsigned64"
Float32Keyword = "Float32"
Float64Keyword = "Float64"
Float128Keyword = "Float128"
BitsKeyword = "Bits"
EnumerationKeyword = "Enumeration"
;; Status keyword.
currentKeyword = "current"
deprecatedKeyword = "deprecated"
obsoleteKeyword = "obsolete"
;; Access keywords.
noaccessKeyword = "noaccess"
notifyonlyKeyword = "notifyonly"
readonlyKeyword = "readonly"
readwriteKeyword = "readwrite"
;; Special floating point values' keywords.
Strauss Expires August 15, 2000 [Page 100]
Internet-Draft SMIng February 2000
neginfKeyword = "neginf"
posinfKeyword = "posinf"
snanKeyword = "snan"
qnanKeyword = "qnan"
;;
;; Some low level rules.
;; These tokens are typically skipped by the lexical analyzer.
;;
sep = 1*(comment / lineBreak / WSP)
; unconditional separator
optsep = *(comment / lineBreak / WSP)
stmtsep = *(comment /
lineBreak /
WSP /
unknownStatement)
comment = "//" *(WSP / VCHAR) lineBreak
lineBreak = CRLF / LF
;;
;; Encoding specific rules.
;;
textVChar = %x21 / %x23-7E
; any VCHAR except DQUOTE
ucAlpha = %x41-5A
lcAlpha = %x61-7A
nonZeroDigit = %x31-39
;;
;; RFC 2234 core rules.
;;
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
CR = %x0D
; carriage return
CRLF = CR LF
; Internet standard newline
Strauss Expires August 15, 2000 [Page 101]
Internet-Draft SMIng February 2000
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
SP = %x20
; space
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB
; white space
;;
;; EOF
;;
Strauss Expires August 15, 2000 [Page 102]
Internet-Draft SMIng February 2000
Appendix B. Glossary
columnar object: An object in a table row that may have zero, one or
more object instances. Instances are identified by using the
values of `indexing objects' as `instance identifier'.
extension: The SMIng `extension' statement can be used to define new
statements. Extensions can express annotations to existent
management information, agent capabilities known from SMIv2, or
arbitrary other information. See Section 16 for details.
identifier: The name of any definition, either a module, type, node,
scalar object, table, row, columnar object, notification, group,
compliance, a named number of an enumeration or bits type or any
construct defined by an SMIng extension. Every identifier starts
with an upper-case or lower-case character, followed by letters,
digits and hyphens, but without consecutive or trailing hyphens.
The length of an identifier MUST NOT exceed 64 characters. Note
that SMIng keywords may be used as identifiers, though it's NOT
RECOMMENDED. See also Section 2.1.
indexing objects: A Table may contain multiple instances of single
columnar objects. That is, there may be multiple rows. The
table's `indexing objects' are used to unambiguously distinguish
the rows of a table. A special encoding of their values
represents the columns' instance-identifier, and thus identifies
the row.
instance-identifier: That part of an object identifier value, that
is used to unambiguously identify an instance of an object. For
scalar objects, the instance-identifier is `0'. For columnar
objects, the instance-identifier is built from the values of the
`indexing objects'. See also Section 2.4.
module: A module is the container of inter-related management
information, either managed objects or other definitions like
type definitions or annotations. A module has to conform the
SMIng grammar and semantics described by this document. A module
represents a namespace in which local definitions are available
and external definitions have to be imported.
named number: Values of `Enumeration' types (Section 3.10) and
single elements of `Bits' (Section 3.11) types are integer
numbers, each associated with an identifers. Those
number-identifier pairs are called `named numbers'.
object: A leaf definition in the object identifier tree, that
represents a class of object instances. Objects are exactly those
definitions declared by the SMIng keywords `scalar' or `column'.
Strauss Expires August 15, 2000 [Page 103]
Internet-Draft SMIng February 2000
object identifier: Management information is organized in a tree of
nodes. Each node is unambiguously identified by an `object
identifier', that consists of a sequence of integer numbers
(`sub-identifiers') which represent the path of nodes from the
root to the addressed node in the tree. See also Section 2.
row: The kind of node used to group columnar objects of a table.
Some significant information on table indexing and information
used for row creation and deletion is associated with a table's
row definition.
scalar object: An object that has zero or one object instance.
sub-identifier: A single component of an object identifier. There
are at most 128 sub-identifiers in an object identifier value and
each sub-identifier has a maximum value of 2^32-1 (4294967295).
table: The kind of node used to group management information that is
organized in a sequence of rows.
Strauss Expires August 15, 2000 [Page 104]
Internet-Draft SMIng February 2000
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Strauss Expires August 15, 2000 [Page 105]
ACC SHELL 2018