< draft-ietf-sming-snmp-01.txt   draft-ietf-sming-snmp-02.txt >
Network Working Group F. Strauss Network Working Group F. Strauss
Internet-Draft J. Schoenwaelder Internet-Draft J. Schoenwaelder
Expires: August 31, 2001 TU Braunschweig Expires: January 18, 2002 TU Braunschweig
K. McCloghrie July 20, 2001
Cisco Systems
March 02, 2001
SMIng Mappings to SNMP SMIng Mappings to SNMP
draft-ietf-sming-snmp-01 draft-ietf-sming-snmp-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2001. This Internet-Draft will expire on January 18, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This memo presents an SMIng language extension that supports the This memo presents an SMIng language extension that supports the
mapping of SMIng definitions of identities, classes, and their mapping of SMIng definitions of identities, classes, and their
attributes and events to dedicated definitions of nodes, scalar attributes and events to dedicated definitions of nodes, scalar
objects, tables and columnar objects, and notifications for objects, tables and columnar objects, and notifications for
application in the SNMP management framework. application in the SNMP management framework.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5
2. SNMP Based Internet Management . . . . . . . . . . . . . . 6 2. SNMP Based Internet Management . . . . . . . . . . . . . . 5
2.1 Kinds of Nodes . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Kinds of Nodes . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Scalar and Columnar Object Instances . . . . . . . . . . . 7 2.2 Scalar and Columnar Object Instances . . . . . . . . . . . 7
2.3 Object Identifier Hierarchy . . . . . . . . . . . . . . . 9 2.3 Object Identifier Hierarchy . . . . . . . . . . . . . . . 8
3. SMIng Data Type Mappings . . . . . . . . . . . . . . . . . 11 3. SMIng Data Type Mappings . . . . . . . . . . . . . . . . . 9
3.1 ASN.1 Definitions . . . . . . . . . . . . . . . . . . . . 12 3.1 ASN.1 Definitions . . . . . . . . . . . . . . . . . . . . 11
4. The snmp Extension Statement . . . . . . . . . . . . . . . 13 4. The snmp Extension Statement . . . . . . . . . . . . . . . 11
4.1 The oid Statement . . . . . . . . . . . . . . . . . . . . 13 4.1 The oid Statement . . . . . . . . . . . . . . . . . . . . 12
4.2 The node Statement . . . . . . . . . . . . . . . . . . . . 13 4.2 The node Statement . . . . . . . . . . . . . . . . . . . . 12
4.2.1 The node's oid Statement . . . . . . . . . . . . . . . . . 13 4.2.1 The node's oid Statement . . . . . . . . . . . . . . . . . 12
4.2.2 The node's represents Statement . . . . . . . . . . . . . 13 4.2.2 The node's represents Statement . . . . . . . . . . . . . 12
4.2.3 The node's status Statement . . . . . . . . . . . . . . . 13 4.2.3 The node's status Statement . . . . . . . . . . . . . . . 12
4.2.4 The node's description Statement . . . . . . . . . . . . . 14 4.2.4 The node's description Statement . . . . . . . . . . . . . 13
4.2.5 The node's reference Statement . . . . . . . . . . . . . . 14 4.2.5 The node's reference Statement . . . . . . . . . . . . . . 13
4.2.6 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 14 4.2.6 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 13
4.3 The scalars Statement . . . . . . . . . . . . . . . . . . 14 4.3 The scalars Statement . . . . . . . . . . . . . . . . . . 13
4.3.1 The scalars' oid Statement . . . . . . . . . . . . . . . . 15 4.3.1 The scalars' oid Statement . . . . . . . . . . . . . . . . 13
4.3.2 The scalars' implements Statement . . . . . . . . . . . . 15 4.3.2 The scalars' implements Statement . . . . . . . . . . . . 14
4.3.2.1 The implements' object Statement . . . . . . . . . . . . . 15 4.3.2.1 The implements' object Statement . . . . . . . . . . . . . 14
4.3.3 The scalars' status Statement . . . . . . . . . . . . . . 15 4.3.3 The scalars' status Statement . . . . . . . . . . . . . . 14
4.3.4 The scalars' description Statement . . . . . . . . . . . . 16 4.3.4 The scalars' description Statement . . . . . . . . . . . . 14
4.3.5 The scalars' reference Statement . . . . . . . . . . . . . 16 4.3.5 The scalars' reference Statement . . . . . . . . . . . . . 15
4.3.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 16 4.3.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 15
4.4 The table Statement . . . . . . . . . . . . . . . . . . . 16 4.4 The table Statement . . . . . . . . . . . . . . . . . . . 15
4.4.1 The table's oid Statement . . . . . . . . . . . . . . . . 17 4.4.1 The table's oid Statement . . . . . . . . . . . . . . . . 15
4.4.2 Table Indexing Statements . . . . . . . . . . . . . . . . 17 4.4.2 Table Indexing Statements . . . . . . . . . . . . . . . . 15
4.4.2.1 The table's index Statement for Table Indexing . . . . . . 17 4.4.2.1 The table's index Statement for Table Indexing . . . . . . 16
4.4.2.2 The table's augments Statement for Table Indexing . . . . 17 4.4.2.2 The table's augments Statement for Table Indexing . . . . 16
4.4.2.3 The table's extends Statement for Table Indexing . . . . . 17 4.4.2.3 The table's extends Statement for Table Indexing . . . . . 16
4.4.2.4 The table's reorders Statement for Table Indexing . . . . 18 4.4.2.4 The table's reorders Statement for Table Indexing . . . . 17
4.4.2.5 The table's expands Statement for Table Indexing . . . . . 18 4.4.2.5 The table's expands Statement for Table Indexing . . . . . 17
4.4.3 The table's create Statement . . . . . . . . . . . . . . . 19 4.4.3 The table's create Statement . . . . . . . . . . . . . . . 18
4.4.4 The table's implements Statement . . . . . . . . . . . . . 19 4.4.4 The table's implements Statement . . . . . . . . . . . . . 18
4.4.4.1 The implements' object Statement . . . . . . . . . . . . . 19 4.4.4.1 The implements' object Statement . . . . . . . . . . . . . 18
4.4.5 The table's status Statement . . . . . . . . . . . . . . . 19 4.4.5 The table's status Statement . . . . . . . . . . . . . . . 18
4.4.6 The table's description Statement . . . . . . . . . . . . 20 4.4.6 The table's description Statement . . . . . . . . . . . . 19
4.4.7 The table's reference Statement . . . . . . . . . . . . . 20 4.4.7 The table's reference Statement . . . . . . . . . . . . . 19
4.4.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . 20 4.4.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . 19
4.5 The notification Statement . . . . . . . . . . . . . . . . 20 4.5 The notification Statement . . . . . . . . . . . . . . . . 19
4.5.1 The notification's oid Statement . . . . . . . . . . . . . 21 4.5.1 The notification's oid Statement . . . . . . . . . . . . . 20
4.5.2 The notification's signals Statement . . . . . . . . . . . 21 4.5.2 The notification's signals Statement . . . . . . . . . . . 20
4.5.2.1 The signals' object Statement . . . . . . . . . . . . . . 21 4.5.2.1 The signals' object Statement . . . . . . . . . . . . . . 20
4.5.3 The notification's status Statement . . . . . . . . . . . 21 4.5.3 The notification's status Statement . . . . . . . . . . . 20
4.5.4 The notification's description Statement . . . . . . . . . 21 4.5.4 The notification's description Statement . . . . . . . . . 20
4.5.5 The notification's reference Statement . . . . . . . . . . 22 4.5.5 The notification's reference Statement . . . . . . . . . . 20
4.5.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 22 4.5.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 21
4.6 The group Statement . . . . . . . . . . . . . . . . . . . 22 4.6 The group Statement . . . . . . . . . . . . . . . . . . . 21
4.6.1 The group's oid Statement . . . . . . . . . . . . . . . . 22 4.6.1 The group's oid Statement . . . . . . . . . . . . . . . . 21
4.6.2 The group's members Statement . . . . . . . . . . . . . . 22 4.6.2 The group's members Statement . . . . . . . . . . . . . . 21
4.6.3 The group's status Statement . . . . . . . . . . . . . . . 23 4.6.3 The group's status Statement . . . . . . . . . . . . . . . 22
4.6.4 The group's description Statement . . . . . . . . . . . . 23 4.6.4 The group's description Statement . . . . . . . . . . . . 22
4.6.5 The group's reference Statement . . . . . . . . . . . . . 23 4.6.5 The group's reference Statement . . . . . . . . . . . . . 22
4.6.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 23 4.6.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 22
4.7 The compliance Statement . . . . . . . . . . . . . . . . . 24 4.7 The compliance Statement . . . . . . . . . . . . . . . . . 22
4.7.1 The compliance's oid Statement . . . . . . . . . . . . . . 24 4.7.1 The compliance's oid Statement . . . . . . . . . . . . . . 23
4.7.2 The compliance's status Statement . . . . . . . . . . . . 24 4.7.2 The compliance's status Statement . . . . . . . . . . . . 23
4.7.3 The compliance's description Statement . . . . . . . . . . 24 4.7.3 The compliance's description Statement . . . . . . . . . . 23
4.7.4 The compliance's reference Statement . . . . . . . . . . . 24 4.7.4 The compliance's reference Statement . . . . . . . . . . . 23
4.7.5 The compliance's mandatory Statement . . . . . . . . . . . 24 4.7.5 The compliance's mandatory Statement . . . . . . . . . . . 23
4.7.6 The compliance's optional Statement . . . . . . . . . . . 25 4.7.6 The compliance's optional Statement . . . . . . . . . . . 24
4.7.6.1 The optional's description Statement . . . . . . . . . . . 25 4.7.6.1 The optional's description Statement . . . . . . . . . . . 24
4.7.7 The compliance's refine Statement . . . . . . . . . . . . 25 4.7.7 The compliance's refine Statement . . . . . . . . . . . . 24
4.7.7.1 The refine's type Statement . . . . . . . . . . . . . . . 26 4.7.7.1 The refine's type Statement . . . . . . . . . . . . . . . 24
4.7.7.2 The refine's writetype Statement . . . . . . . . . . . . . 26 4.7.7.2 The refine's writetype Statement . . . . . . . . . . . . . 25
4.7.7.3 The refine's access Statement . . . . . . . . . . . . . . 26 4.7.7.3 The refine's access Statement . . . . . . . . . . . . . . 25
4.7.7.4 The refine's description Statement . . . . . . . . . . . . 26 4.7.7.4 The refine's description Statement . . . . . . . . . . . . 25
4.7.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . 27 4.7.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . 25
5. IETF-SMING-SNMP-EXT . . . . . . . . . . . . . . . . . . . 28 5. IETF-SMING-SNMP-EXT . . . . . . . . . . . . . . . . . . . 26
6. IETF-SMING-SNMP . . . . . . . . . . . . . . . . . . . . . 36 6. IETF-SMING-SNMP . . . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . 49 7. Security Considerations . . . . . . . . . . . . . . . . . 46
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 50 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 46
References . . . . . . . . . . . . . . . . . . . . . . . . 51 References . . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48
A. SMIng SNMP Mapping ABNF Grammar . . . . . . . . . . . . . 53 A. SMIng SNMP Mapping ABNF Grammar . . . . . . . . . . . . . 48
B. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . 58 B. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . 53
Full Copyright Statement . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This memo presents an SMIng language extension that supports the This memo presents an SMIng language extension that supports the
mapping of SMIng definitions of identities, classes, and their mapping of SMIng definitions of identities, classes, and their
attributes and events to dedicated definitions of nodes, scalar attributes and events to dedicated definitions of nodes, scalar
objects, tables and columnar objects, and notifications for objects, tables and columnar objects, and notifications for
application in the SNMP management framework. application in the SNMP management framework.
Section 2 introduces basics of the SNMP management framework. Section 2 introduces basics of the SNMP management framework.
Section 3 defines how SMIng data types are mapped to the data types Section 3 defines how SMIng data types are mapped to the data types
supported by the SNMP protocol. It introduces some new ASN.1 supported by the SNMP protocol. It introduces some new ASN.1
definitions which are used to represent new SMIng base types such as definitions which are used to represent new SMIng base types such as
floats in the SNMP protocol via the opaque mapping technique. floats in the SNMP protocol via the opaque mapping technique.
Section 4 describes the semantics of the SNMP mapping extensions for Section 4 describes the semantics of the SNMP mapping extensions for
SMIng. The formal SMIng specification of the extension is provided SMIng. The formal SMIng specification of the extension is provided
in Section 5. in Section 5.
Section 6 contains an SMIng module which defines data types and Section 6 contains an SMIng module which defines data types and
classes (such as RowStatus) that are specific to the SNMP mapping. classes (such as RowStatus) that are specific to the SNMP mapping.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2]. document are to be interpreted as described in [2].
2. SNMP Based Internet Management 2. SNMP Based Internet Management
The SNMP network management framework [3] is based on the model of The SNMP network management framework [3] is based on the model of
"managed objects". A managed object represents a class of any real "managed objects". A managed object represents a class of any real
or synthesized variable of systems that are to be managed. Note that or synthesized variable of systems that are to be managed. Note that
in spite of these terms this model is not object-oriented. The in spite of these terms this model is not object-oriented. The
managed objects are organized hierarchically in an "object managed objects are organized hierarchically in an "object identifier
identifier tree", where only leaf nodes may represent objects. tree", where only leaf nodes may represent objects.
Nodes in the object identifier tree may also identify conceptual Nodes in the object identifier tree may also identify conceptual
tables, rows of conceptual tables, notifications, groups of objects tables, rows of conceptual tables, notifications, groups of objects
and/or notifications, compliance statements, modules or other and/or notifications, compliance statements, modules or other
information. Each node is identified by an unique "object information. Each node is identified by an unique "object
identifier" value which is an ordered list of non-negative numbers, identifier" value which is an ordered list of non-negative numbers,
named "sub-identifiers", where the left-most sub-identifier refers named "sub-identifiers", where the left-most sub-identifier refers to
to the node next to the root of the tree and the right-most the node next to the root of the tree and the right-most sub-
sub-identifier refers to the node that is identified by the complete identifier refers to the node that is identified by the complete
object identifier. The number of sub-identifiers of an object object identifier. The number of sub-identifiers of an object
identifier must not exceed 128. Each sub-identifier has a value identifier must not exceed 128. Each sub-identifier has a value
between 0 and 2^32-1 (4294967295). between 0 and 2^32-1 (4294967295).
The SMIng extensions described in this document are used to map The SMIng extensions described in this document are used to map SMIng
SMIng data definitions to SNMP compliant managed objects. This data definitions to SNMP compliant managed objects. This mapping is
mapping is done in a way readable to computer programs, named MIB done in a way readable to computer programs, named MIB compilers, as
compilers, as well as to human readers. well as to human readers.
2.1 Kinds of Nodes 2.1 Kinds of Nodes
Each node in the object identifier tree is of a certain kind and may Each node in the object identifier tree is of a certain kind and may
represent management information or not: represent management information or not:
o Simple nodes, that do not represent management information, but o Simple nodes, that do not represent management information, but
may be used for grouping nodes in a subtree. Those nodes are may be used for grouping nodes in a subtree. Those nodes are
defined by the `node' statement. This statement can also be used defined by the `node' statement. This statement can also be used
to map an SMIng `identity' to a node. to map an SMIng `identity' to a node.
o Nodes representing the identity of a module to allow references o Nodes representing the identity of a module to allow references to
to a module in other objects of type `ObjectIdentifier'. Those a module in other objects of type `ObjectIdentifier'. Those nodes
nodes are defined by the `snmp' statement, are defined by the `snmp' statement,
o Scalar objects, which have exactly one object instance and no o Scalar objects, which have exactly one object instance and no
child nodes. See Section 2.2 for scalar objects' instances. A child nodes. See Section 2.2 for scalar objects' instances. A
set of scalar objects is mapped from one or more SMIng classes set of scalar objects is mapped from one or more SMIng classes
using the `scalars' statement. The statement block of the using the `scalars' statement. The statement block of the
`scalars' statement contains one `implements' statement for each `scalars' statement contains one `implements' statement for each
class. The associated statement blocks in turn contain `object' class. The associated statement blocks in turn contain `object'
statements that specify the mapping of attributes to scalar statements that specify the mapping of attributes to scalar
objects. Scalar objects MUST not have any child node. objects. Scalar objects MUST not have any child node.
o Tables, which represent the root node of a collection of o Tables, which represent the root node of a collection of
information structured in table rows. Table nodes are defined by information structured in table rows. Table nodes are defined by
the `table' statement. A table object identifier SHOULD not have the `table' statement. A table object identifier SHOULD not have
any other child node than the implicitly defined row node (see any other child node than the implicitly defined row node (see
below). below).
o Rows, which belong to a table (that is, row's object identifier o Rows, which belong to a table (that is, row's object identifier
consists of the table's full object identifier plus a single `1' consists of the table's full object identifier plus a single `1'
sub-identifier) and represent a sequence of one or more columnar sub-identifier) and represent a sequence of one or more columnar
objects. A row node is implicitly defined for each table node. objects. A row node is implicitly defined for each table node.
o Columnar objects, which belong to a row (that is, the columnar o Columnar objects, which belong to a row (that is, the columnar
objects' object identifier consists of the row's full object objects' object identifier consists of the row's full object
identifier plus a single column-identifying sub-identifier) and identifier plus a single column-identifying sub-identifier) and
have zero or more object instances and no child nodes. They are have zero or more object instances and no child nodes. They are
defined as follows: The classes that are implemented by a `table' defined as follows: The classes that are implemented by a `table'
statement are identified by `implements' statements. The statement are identified by `implements' statements. The
statement block of each `implements' statement contains `object' statement block of each `implements' statement contains `object'
statements that specify the mapping of attributes to columnar statements that specify the mapping of attributes to columnar
objects of this table. Columnar objects MUST not have any child objects of this table. Columnar objects MUST not have any child
node. node.
o Notifications, which represent information that is sent by agents o Notifications, which represent information that is sent by agents
within unsolicited transmissions. The `notification' statement within unsolicited transmissions. The `notification' statement is
is used to map an SMIng event to a notification. A notification's used to map an SMIng event to a notification. A notification's
object identifier SHOULD not have any child node. object identifier SHOULD not have any child node.
o Groups of objects and notifications, which may be used for o Groups of objects and notifications, which may be used for
compliance statements. They are defined using the `group' compliance statements. They are defined using the `group'
statement. statement.
o Compliance statements which define requirements for MIB module o Compliance statements which define requirements for MIB module
implementations. They are defined using the `compliance' implementations. They are defined using the `compliance'
statement. statement.
2.2 Scalar and Columnar Object Instances 2.2 Scalar and Columnar Object Instances
Instances of managed objects are identified by appending an Instances of managed objects are identified by appending an instance-
instance-identifier to the object's object identifier. Scalar identifier to the object's object identifier. Scalar objects and
objects and columnar objects use different ways to construct the columnar objects use different ways to construct the instance-
instance-identifier. identifier.
Scalar objects have exactly one object instance. It is identified by Scalar objects have exactly one object instance. It is identified by
appending a single `0' sub-identifier to the object identifier of appending a single `0' sub-identifier to the object identifier of the
the scalar object. scalar object.
Within tables, different instances of the same columnar object are Within tables, different instances of the same columnar object are
identified by appending a sequence of one or more sub-identifiers to identified by appending a sequence of one or more sub-identifiers to
the object identifier of the columnar object which consists of the the object identifier of the columnar object which consists of the
values of object instances that unambiguously distinguish a table values of object instances that unambiguously distinguish a table
row. These indexing objects can be columnar objects of the same row. These indexing objects can be columnar objects of the same
and/or another table, but MUST NOT be scalar objects. Multiple and/or another table, but MUST NOT be scalar objects. Multiple
applications of the same object in a single table indexing applications of the same object in a single table indexing
specification are strongly discouraged. specification are strongly discouraged.
The base types of the indexing objects indicate how to form the The base types of the indexing objects indicate how to form the
instance-identifier: instance-identifier:
o integer-valued or enumeration-valued: a single sub-identifier o integer-valued or enumeration-valued: a single sub-identifier
taking the integer value (this works only for non-negative taking the integer value (this works only for non-negative
integers and integers of a size of up to 32 bits), integers and integers of a size of up to 32 bits),
o string-valued, fixed-length strings (or variable-length with o string-valued, fixed-length strings (or variable-length with
compact encoding): `n' sub-identifiers, where `n' is the length compact encoding): `n' sub-identifiers, where `n' is the length of
of the string (each octet of the string is encoded in a separate the string (each octet of the string is encoded in a separate sub-
sub-identifier), identifier),
o string-valued, variable-length strings or bits-valued: `n+1' o string-valued, variable-length strings or bits-valued: `n+1' sub-
sub-identifiers, where `n' is the length of the string or bits identifiers, where `n' is the length of the string or bits
encoding (the first sub-identifier is `n' itself, following this, encoding (the first sub-identifier is `n' itself, following this,
each octet of the string or bits is encoded in a separate each octet of the string or bits is encoded in a separate sub-
sub-identifier), identifier),
o object identifier-valued (with compact encoding): `n' o object identifier-valued (with compact encoding): `n' sub-
sub-identifiers, where `n' is the number of sub-identifiers in identifiers, where `n' is the number of sub-identifiers in the
the value (each sub-identifier of the value is copied into a value (each sub-identifier of the value is copied into a separate
separate sub-identifier), sub-identifier),
o object identifier-valued: `n+1' sub-identifiers, where `n' is the o object identifier-valued: `n+1' sub-identifiers, where `n' is the
number of sub-identifiers in the value (the first sub-identifier number of sub-identifiers in the value (the first sub-identifier
is `n' itself, following this, each sub-identifier in the value is `n' itself, following this, each sub-identifier in the value is
is copied), copied),
Note that compact encoding can only be applied to an object having a Note that compact encoding can only be applied to an object having a
variable-length syntax (e.g., variable-length strings, bits objects variable-length syntax (e.g., variable-length strings, bits objects
or object identifier-valued objects). Further, compact encoding can or object identifier-valued objects). Further, compact encoding can
only be associated with the last object in a list of indexing only be associated with the last object in a list of indexing
objects. Finally, compact encoding MUST NOT be used on a objects. Finally, compact encoding MUST NOT be used on a variable-
variable-length string object if that string might have a value of length string object if that string might have a value of zero-
zero-length. length.
Instances identified by use of integer-valued or enumeration-valued Instances identified by use of integer-valued or enumeration-valued
objects are RECOMMENDED to be numbered starting from one (i.e., not objects are RECOMMENDED to be numbered starting from one (i.e., not
from zero). Integer objects that allow negative values, Unsigned64 from zero). Integer objects that allow negative values, Unsigned64
objects, Integer64 objects and floating point objects MUST NOT be objects, Integer64 objects and floating point objects MUST NOT be
used for table indexing. used for table indexing.
Objects which are both specified for indexing in a row and also Objects which are both specified for indexing in a row and also
columnar objects of the same row are termed auxiliary objects. columnar objects of the same row are termed auxiliary objects.
Auxiliary objects SHOULD be non-accessible, except in the following Auxiliary objects SHOULD be non-accessible, except in the following
circumstances: circumstances:
o within a module originally written to conform to SMIv1, or o within a module originally written to conform to SMIv1, or
o a row must contain at least one columnar object which is not an 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 auxiliary object. In the event that all of a row's columnar
objects are also specified to be indexing objects then one of objects are also specified to be indexing objects then one of them
them MUST be accessible. MUST be accessible.
2.3 Object Identifier Hierarchy 2.3 Object Identifier Hierarchy
The layers of the object identifier tree near the root are well The layers of the object identifier tree near the root are well
defined and organized by standardization bodies. The first level defined and organized by standardization bodies. The first level
next to the root has three nodes: next to the root has three nodes:
0: ccitt 0: ccitt
1: iso 1: iso
2: joint-iso-ccitt 2: joint-iso-ccitt
Note that the renaming of the Commite Consultatif International de Note that the renaming of the Commite Consultatif International de
Telegraphique et Telephonique (CCITT) to International Telegraphique et Telephonique (CCITT) to International
Telecommunications Union (ITU) had no consequence on the names used Telecommunications Union (ITU) had no consequence on the names used
in the object identifier tree. in the object identifier tree.
The root of the subtree administered by the Internet Assigned The root of the subtree administered by the Internet Assigned Numbers
Numbers Authority (IANA) for the Internet is `1.3.6.1' which is Authority (IANA) for the Internet is `1.3.6.1' which is assigned with
assigned with the identifier `internet'. That is, the Internet the identifier `internet'. That is, the Internet subtree of object
subtree of object identifiers starts with the prefix `1.3.6.1.'. identifiers starts with the prefix `1.3.6.1.'.
Several branches underneath this subtree are used for network Several branches underneath this subtree are used for network
management: management:
The `mgmt' (internet.2) subtree is used to identify "standard" The `mgmt' (internet.2) subtree is used to identify "standard"
information. definitions. An information module produced by an IETF working group
becomes a "standard" information module when the document is first
approved by the IESG and enters the Internet standards track.
The `experimental' (internet.3) subtree is used to identify The `experimental' (internet.3) subtree is used to identify
information being designed by working groups of the IETF or IRTF. If experimental definitions being designed by working groups of the IETF
a module produced by a working group becomes a "standard" module or IRTF. If an information module produced by a working group
then at the very beginning of its entry onto the Internet standards becomes a "standard" module, then at the very beginning of its entry
track, the information is moved under the mgmt subtree. onto the Internet standards track, the definitions are moved under
the mgmt subtree.
The `private' (internet.4) subtree is used to identify information The `private' (internet.4) subtree is used to identify definitions
defined unilaterally. The `enterprises' (private.1) subtree beneath defined unilaterally. The `enterprises' (private.1) subtree beneath
private is used, among other things, to permit providers of private is used, among other things, to permit providers of
networking subsystems to register models of their products. networking subsystems to register information modules of their
products.
These and some other nodes are defined in the SMIng standard module These and some other nodes are defined in the SMIng standard module
IETF-SMING-SNMP-EXT (Section 5). IETF-SMING-SNMP-EXT (Section 5).
3. SMIng Data Type Mappings 3. SMIng Data Type Mappings
SMIng [1] supports the following set of base types: OctetString, SMIng [1] supports the following set of base types: OctetString,
Identity, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Identity, Integer32, Integer64, Unsigned32, Unsigned64, Float32,
Float64, Float128, Enumeration, and Bits. The SMIng core module Float64, Float128, Enumeration, and Bits. The SMIng core module
IETF-SMING [1] defines additional derived data types, among them IETF-SMING [1] defines additional derived data types, among them
Counter32 (derived from Unsigned32), Counter64 (derived from Counter32 (derived from Unsigned32), Counter64 (derived from
Unsigned64), TimeTicks (derived from Unsigned32), IpAddress (derived Unsigned64), TimeTicks (derived from Unsigned32), IpAddress (derived
from OctetString), and Opaque (derived from OctetString). from OctetString), and Opaque (derived from OctetString).
The version 2 of the protocol operations for SNMP document [16] The version 2 of the protocol operations for SNMP document [16]
defines the following 9 data types which are distinguished by the defines the following 9 data types which are distinguished by the
protocol: INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress, protocol: INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress,
Counter32, TimeTicks, Opaque, Counter64, Unsigned32. Counter32, TimeTicks, Opaque, Counter64, Unsigned32.
skipping to change at page 10, line 43 skipping to change at page 9, line 33
Float128 Opaque (Float128) (2) Float128 Opaque (Float128) (2)
Enumeration INTEGER Enumeration INTEGER
Bits OCTET STRING Bits OCTET STRING
Counter32 Counter32 Counter32 Counter32
Counter64 Counter64 Counter64 Counter64
TimeTicks TimeTicks TimeTicks TimeTicks
IpAddress IpAddress IpAddress IpAddress
Opaque Opaque Opaque Opaque
(1) This mapping includes all types derived from the OctetString (1) This mapping includes all types derived from the OctetString type
type except those types derived from the IpAddress and Opaque except those types derived from the IpAddress and Opaque SMIng
SMIng type defined in [1]. type defined in [1].
(2) This type is encoded according to the ASN.1 type with the same (2) This type is encoded according to the ASN.1 type with the same
name defined in Section 3.1. The resulting BER encoded value is name defined in Section 3.1. The resulting BER encoded value is
then wrapped in an Opaque value. then wrapped in an Opaque value.
(3) This mapping includes all types derived from the Unsigned32 type (3) This mapping includes all types derived from the Unsigned32 type
except those types derived from the Counter32 and TimeTicks SMIng except those types derived from the Counter32 and TimeTicks SMIng
type defined in [1]. type defined in [1].
(4) This mapping includes all types derived from the Unsigned64 type (4) This mapping includes all types derived from the Unsigned64 type
except those types derived from the Counter64 SMIng type defined except those types derived from the Counter64 SMIng type defined
in [1]. in [1].
3.1 ASN.1 Definitions 3.1 ASN.1 Definitions
The ASN.1 [12] type definitions below introduce data types which are The ASN.1 [12] type definitions below introduce data types which are
used to new SMIng base types into the set of ASN.1 types supported used to new SMIng base types into the set of ASN.1 types supported by
by the second version of SNMP protocol operations [16]. the second version of SNMP protocol operations [16].
IETF-SMING-SNMP-MAPPING DEFINITIONS ::= BEGIN IETF-SMING-SNMP-MAPPING DEFINITIONS ::= BEGIN
Integer64 ::= Integer64 ::=
[APPLICATION 10] [APPLICATION 10]
IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
Unsigned64 Unsigned64
[APPLICATION 11] [APPLICATION 11]
IMPLICIT INTEGER (0..18446744073709551615) IMPLICIT INTEGER (0..18446744073709551615)
skipping to change at page 11, line 41 skipping to change at page 10, line 36
[APPLICATION 13] [APPLICATION 13]
IMPLICIT OCTET STRING (SIZE (8)) IMPLICIT OCTET STRING (SIZE (8))
Float128 Float128
[APPLICATION 14] [APPLICATION 14]
IMPLICIT OCTET STRING (SIZE (16)) IMPLICIT OCTET STRING (SIZE (16))
END END
The definitions of Integer64 and Unsigned64 are consistent with the The definitions of Integer64 and Unsigned64 are consistent with the
same definitions in the SPPI. The floating point types Float32, same definitions in the SPPI. The floating point types Float32,
Float64 and Float128 support single, double and quadruple IEEE Float64 and Float128 support single, double and quadruple IEEE
floating point values. The encoding of the values follows the "IEEE floating point values. The encoding of the values follows the "IEEE
Standard for Binary Floating-Point Arithmetic" as defined in Standard for Binary Floating-Point Arithmetic" as defined in
ANSI/IEEE Standard 754-1985 [13]. ANSI/IEEE Standard 754-1985 [13].
4. The snmp Extension Statement 4. The snmp Extension Statement
The `snmp' statement is the main statement of the SNMP mapping The `snmp' statement is the main statement of the SNMP mapping
specification. It gets one or two arguments: an optional lower-case specification. It gets one or two arguments: an optional lower-case
identifier that can specifies a node that represents the module's identifier that can specifies a node that represents the module's
identity, and a mandatory statement block that contains all details identity, and a mandatory statement block that contains all details
of the SNMP mapping. All information of an SNMP mapping are mapped of the SNMP mapping. All information of an SNMP mapping are mapped
to an SNMP conformant module of the same name as the containing to an SNMP conformant module of the same name as the containing SMIng
SMIng module. A single SMIng module must not contain more than one module. A single SMIng module must not contain more than one `snmp'
`snmp' statement. statement.
4.1 The oid Statement 4.1 The oid Statement
The snmp's `oid' statement, which must be present, if the snmp The snmp's `oid' statement, which must be present, if the snmp
statement contains a module identifier and must be absent otherwise, statement contains a module identifier and must be absent otherwise,
gets one argument which specifies the object identifier value that gets one argument which specifies the object identifier value that is
is assigned to this module's identity node. assigned to this module's identity node.
4.2 The node Statement 4.2 The node Statement
The `node' statement is used to name and describe a node in the The `node' statement is used to name and describe a node in the
object identifier tree, without associating any class or attribute object identifier tree, without associating any class or attribute
information with this node. This may be useful to group definitions information with this node. This may be useful to group definitions
in a subtree of related management information, or to uniquely in a subtree of related management information, or to uniquely define
define an SMIng `identity' to be referenced in attributes of type an SMIng `identity' to be referenced in attributes of type Identity.
Identity. The `node' statement gets two arguments: a lower-case The `node' statement gets two arguments: a lower-case node identifier
node identifier and a statement block that holds detailed node and a statement block that holds detailed node information in an
information in an obligatory order. obligatory order.
See the `nodeStatement' rule of the SMIng grammar (Section 5) for See the `nodeStatement' rule of the SMIng grammar (Section 5) for the
the formal syntax of the `node' statement. formal syntax of the `node' statement.
4.2.1 The node's oid Statement 4.2.1 The node's oid Statement
The node's `oid' statement, which must be present, gets one argument The node's `oid' statement, which must be present, gets one argument
which specifies the object identifier value that is assigned to this which specifies the object identifier value that is assigned to this
node. node.
4.2.2 The node's represents Statement 4.2.2 The node's represents Statement
The node's `represents' statement, which need not be present, makes The node's `represents' statement, which need not be present, makes
this node represent an SMIng identity, so that objects of type this node represent an SMIng identity, so that objects of type
Identity can reference that identity. The statement gets one Identity can reference that identity. The statement gets one
argument which specifies the identity name. argument which specifies the identity name.
4.2.3 The node's status Statement 4.2.3 The node's status Statement
The node's `status' statement, which need not be present, gets one The node's `status' statement, which must be present, gets one
argument which is used to specify whether this node definition is argument which is used to specify whether this node definition is
current or historic. The value `current' means that the definition current or historic. The value `current' means that the definition
is current and valid. The value `obsolete' means the definition is is current and valid. The value `obsolete' means the definition is
obsolete and should not be implemented and/or can be removed if obsolete and should not be implemented and/or can be removed if
previously implemented. While the value `deprecated' also indicates previously implemented. While the value `deprecated' also indicates
an obsolete definition, it permits new/continued implementation in an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing order to foster interoperability with older/existing implementations.
implementations.
If the `status' statement is omitted, the status value `current' is
implied.
4.2.4 The node's description Statement 4.2.4 The node's description Statement
The node's `description' statement, which need not be present, gets The node's `description' statement, which need not be present, gets
one argument which is used to specify a high-level textual one argument which is used to specify a high-level textual
description of this node. description of this node.
It is RECOMMENDED to include all semantics and purposes of this It is RECOMMENDED to include all semantics and purposes of this node.
node.
4.2.5 The node's reference Statement 4.2.5 The node's reference Statement
The node's `reference' statement, which need not be present, gets The node's `reference' statement, which need not be present, gets one
one argument which is used to specify a textual cross-reference to argument which is used to specify a textual cross-reference to some
some other document, either another module which defines related other document, either another module which defines related
definitions, or some other document which provides additional definitions, or some other document which provides additional
information relevant to this node. information relevant to this node.
4.2.6 Usage Examples 4.2.6 Usage Examples
node iso { oid 1; }; node iso { oid 1; status current; };
node org { oid iso.3; }; node org { oid iso.3; status current; };
node dod { oid org.6; }; node dod { oid org.6; status current; };
node internet { oid dod.1; }; node internet { oid dod.1; status current; };
node zeroDotZero { node zeroDotZero {
oid 0.0; oid 0.0;
represents IETF-SMING::null; represents IETF-SMING::null;
status current;
description "A value used for null identifiers."; description "A value used for null identifiers.";
}; };
4.3 The scalars Statement 4.3 The scalars Statement
The `scalars' statement is used to define the mapping of one or more The `scalars' statement is used to define the mapping of one or more
classes to a group of SNMP scalar managed objects organized under a classes to a group of SNMP scalar managed objects organized under a
common parent node. The `scalars' statement gets two arguments: a common parent node. The `scalars' statement gets two arguments: a
lower-case scalar group identifier and a statement block that holds lower-case scalar group identifier and a statement block that holds
detailed mapping information of this scalar group in an obligatory detailed mapping information of this scalar group in an obligatory
order. order.
See the `scalarsStatement' rule of the SMIng grammar (Section 5) for See the `scalarsStatement' rule of the SMIng grammar (Section 5) for
the formal syntax of the `scalars' statement. the formal syntax of the `scalars' statement.
4.3.1 The scalars' oid Statement 4.3.1 The scalars' oid Statement
The scalars' `oid' statement, which must be present, gets one The scalars' `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is argument which specifies the object identifier value that is assigned
assigned to the common parent node of this scalar group. to the common parent node of this scalar group.
4.3.2 The scalars' implements Statement 4.3.2 The scalars' implements Statement
The scalars' `implements' statement, which must be present at least The scalars' `implements' statement, which must be present at least
once, makes this scalar group contain scalar objects that are once, makes this scalar group contain scalar objects that are defined
defined by a given class. It gets two arguments: the class being by a given class. It gets two arguments: the class being implemented
implemented and a statement block that holds detailed information on and a statement block that holds detailed information on the
the attributes of that class being implemented in an obligatory attributes of that class being implemented in an obligatory order.
order.
Note: It is possible to apply multiple implements statements to a Note: It is possible to apply multiple implements statements to a
single scalars statement, each specifying a distinct class. However, single scalars statement, each specifying a distinct class. However,
it is considerable to define a new class containing thoses classes it is considerable to define a new class containing thoses classes
and making the scalar group implement that single container class. and making the scalar group implement that single container class.
4.3.2.1 The implements' object Statement 4.3.2.1 The implements' object Statement
The `object' statement, which must be present at least once, makes a The `object' statement, which must be present at least once, makes a
single attribute of the class being contained as a scalar object in single attribute of the class being contained as a scalar object in
the scalar group. It gets two arguments: the scalar object name and the scalar group. It gets two arguments: the scalar object name and
the class attribute being implemented. the class attribute being implemented.
The object identifier of this scalar object is implicitly specified The object identifier of this scalar object is implicitly specified
by concatenating the scalar group's object identifier and the by concatenating the scalar group's object identifier and the
position of the object, starting at 1. [XXX see open issues: we position of the object, starting at 1. [XXX see open issues: we
better use mandatory explicit OID mapping.] better use mandatory explicit OID mapping.]
4.3.3 The scalars' status Statement 4.3.3 The scalars' status Statement
The scalars' `status' statement, which need not be present, gets one The scalars' `status' statement, which must be present, gets one
argument which is used to specify whether this scalar group argument which is used to specify whether this scalar group
definition is current or historic. The value `current' means that definition is current or historic. The value `current' means that
the definition is current and valid. The value `obsolete' means the the definition is current and valid. The value `obsolete' means the
definition is obsolete and should not be implemented and/or can be definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated' removed if previously implemented. While the value `deprecated' also
also indicates an obsolete definition, it permits new/continued indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with implementation in order to foster interoperability with
older/existing implementations. older/existing implementations.
Scalar groups SHOULD NOT be defined as `current' if one or more of Scalar groups SHOULD NOT be defined as `current' if one or more of
their classes are `deprecated' or `obsolete'. Similarly, they SHOULD their classes are `deprecated' or `obsolete'. Similarly, they SHOULD
NOT be defined as `deprecated' if one or more of their classes are NOT be defined as `deprecated' if one or more of their classes are
`obsolete'. Nevertheless, subsequent revisions of used class `obsolete'. Nevertheless, subsequent revisions of used class
definition cannot be avoided, but SHOULD be taken into account in definition cannot be avoided, but SHOULD be taken into account in
subsequent revisions of the local module. subsequent revisions of the local module.
If the `status' statement is omitted the status value `current' is
implied.
4.3.4 The scalars' description Statement 4.3.4 The scalars' description Statement
The scalars' `description' statement, which must be present, gets The scalars' `description' statement, which must be present, gets one
one argument which is used to specify a high-level textual argument which is used to specify a high-level textual description of
description of this scalar group. this scalar group.
It is RECOMMENDED to include all semantic definitions necessary for It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this scalar group. the implementation of this scalar group.
4.3.5 The scalars' reference Statement 4.3.5 The scalars' reference Statement
The scalars' `reference' statement, which need not be present, gets The scalars' `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related some other document, either another module which defines related
definitions, or some other document which provides additional definitions, or some other document which provides additional
skipping to change at page 15, line 38 skipping to change at page 14, line 26
4.3.6 Usage Example 4.3.6 Usage Example
scalars ip { scalars ip {
oid mib-2.4; oid mib-2.4;
implements Ip { implements Ip {
object ipForwarding forwarding; object ipForwarding forwarding;
object ipDefaultTTL defaultTTL; object ipDefaultTTL defaultTTL;
// ... // ...
} }
status current;
description description
"This scalar group implements the Ip class."; "This scalar group implements the Ip class.";
}; };
4.4 The table Statement 4.4 The table Statement
The `table' statement is used to define the mapping of one or more The `table' statement is used to define the mapping of one or more
classes to a single SNMP table of columnar managed objects. The classes to a single SNMP table of columnar managed objects. The
`table' statement gets two arguments: a lower-case table identifier `table' statement gets two arguments: a lower-case table identifier
and a statement block that holds detailed mapping information of and a statement block that holds detailed mapping information of this
this table in an obligatory order. table in an obligatory order.
See the `tableStatement' rule of the SMIng grammar (Section 5) for See the `tableStatement' rule of the SMIng grammar (Section 5) for
the formal syntax of the `table' statement. the formal syntax of the `table' statement.
4.4.1 The table's oid Statement 4.4.1 The table's oid Statement
The table's `oid' statement, which must be present, gets one The table's `oid' statement, which must be present, gets one argument
argument which specifies the object identifier value that is which specifies the object identifier value that is assigned to this
assigned to this table's node. table's node.
4.4.2 Table Indexing Statements 4.4.2 Table Indexing Statements
SNMP table mappings offers five methods to supply table indexing SNMP table mappings offers five methods to supply table indexing
information: ordinary tables, table augmentations, sparse table information: ordinary tables, table augmentations, sparse table
augmentations, table expansions, and reordered tables use different augmentations, table expansions, and reordered tables use different
statements to denote their indexing information. Each table statements to denote their indexing information. Each table
definition must contain exactly one of the following indexing definition must contain exactly one of the following indexing
statements. statements.
4.4.2.1 The table's index Statement for Table Indexing 4.4.2.1 The table's index Statement for Table Indexing
The table's `index' statement, which is used to supply table The table's `index' statement, which is used to supply table indexing
indexing information of base tables, gets one argument that information of base tables, gets one argument that specifies a comma-
specifies a comma-separated list of objects, that are used for table separated list of objects, that are used for table indexing, enclosed
indexing, enclosed in parenthesis. in parenthesis.
The elements of the `unique' statement of the implemented class(es)
(see Section 4.4.4) and their order should be regarded as a hint for
the index elements of the table.
Under some circumstances, an optional `implied' keyword may be added Under some circumstances, an optional `implied' keyword may be added
in front of the list to indicate a compact encoding of the last in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.2 for details. object in the list. See Section 2.2 for details.
4.4.2.2 The table's augments Statement for Table Indexing 4.4.2.2 The table's augments Statement for Table Indexing
The table's `augments' statement, which is used to supply table The table's `augments' statement, which is used to supply table
indexing information of tables that augment a base table, gets one indexing information of tables that augment a base table, gets one
argument that specifies the identifier of the table to be augmented. argument that specifies the identifier of the table to be augmented.
Note that a table augmentation cannot itself be augmented. Anyhow, a Note that a table augmentation cannot itself be augmented. Anyhow, a
base table may be augmented by multiple table augmentations. base table may be augmented by multiple table augmentations.
A table augmentation makes instances of subordinate columnar objects A table augmentation makes instances of subordinate columnar objects
identified according to the index specification of the base table identified according to the index specification of the base table
corresponding to the table named in the `augments' statement. corresponding to the table named in the `augments' statement.
Further, instances of subordinate columnar objects of a table Further, instances of subordinate columnar objects of a table
augmentation exist according to the same semantics as instances of augmentation exist according to the same semantics as instances of
subordinate columnar objects of the base table being augmented. As subordinate columnar objects of the base table being augmented. As
such, note that creation of a base table row implies the such, note that creation of a base table row implies the
correspondent creation of any table row augmentations. Table correspondent creation of any table row augmentations. Table
augmentations MUST NOT be used in table row creation and deletion augmentations MUST NOT be used in table row creation and deletion
operations. operations.
4.4.2.3 The table's extends Statement for Table Indexing 4.4.2.3 The table's extends Statement for Table Indexing
The table's `extends' statement, which is used to supply table The table's `extends' statement, which is used to supply table
indexing information of tables that sparsely augment a base table, indexing information of tables that sparsely augment a base table,
gets one argument that specifies the identifier of the table to be gets one argument that specifies the identifier of the table to be
sparsely augmented. Note that a sparse table augmentation cannot sparsely augmented. Note that a sparse table augmentation cannot
itself be augmented. Anyhow, a base table may be augmented by itself be augmented. Anyhow, a base table may be augmented by
multiple table augmentations, sparsely or not. multiple table augmentations, sparsely or not.
A sparse table augmentation makes instances of subordinate columnar A sparse table augmentation makes instances of subordinate columnar
objects identified, if present, according to the index specification objects identified, if present, according to the index specification
of the base table corresponding to the table named in the `extends' of the base table corresponding to the table named in the `extends'
statement. Further, instances of subordinate columnar objects of a statement. Further, instances of subordinate columnar objects of a
sparse table augmentation exist according to the semantics as sparse table augmentation exist according to the semantics as
instances of subordinate columnar objects of the base table and the instances of subordinate columnar objects of the base table and the
(non-formal) rules that confine the sparse relationship. As such, (non-formal) rules that confine the sparse relationship. As such,
note that creation of a sparse table row augmentation may be implied note that creation of a sparse table row augmentation may be implied
by the creation of a base table row as well as done by an explicit by the creation of a base table row as well as done by an explicit
creation. However, if a base table row gets deleted, any dependent creation. However, if a base table row gets deleted, any dependent
sparse table row augmentations get also deleted implicitly. sparse table row augmentations get also deleted implicitly.
4.4.2.4 The table's reorders Statement for Table Indexing 4.4.2.4 The table's reorders Statement for Table Indexing
The table's `reorders' statement is used to supply table indexing The table's `reorders' statement is used to supply table indexing
information of tables, that contain exactly the same index objects information of tables, that contain exactly the same index objects of
of a base table, except in another order. It gets at least two a base table, except in another order. It gets at least two
arguments. The first one specifies the identifier of the base table. arguments. The first one specifies the identifier of the base table.
The second one specifies a comma-separated list of exactly those The second one specifies a comma-separated list of exactly those
object identifiers of the base table's `index' statement, but in the object identifiers of the base table's `index' statement, but in the
order to be used in this table. Note that a reordered table cannot order to be used in this table. Note that a reordered table cannot
itself be reordered. Anyhow, a base table may be used for multiple itself be reordered. Anyhow, a base table may be used for multiple
reordered tables. reordered tables.
Under some circumstances, an optional `implied' keyword may be added Under some circumstances, an optional `implied' keyword may be added
in front of the list to indicate a compact encoding of the last in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.2 for details. object in the list. See Section 2.2 for details.
Instances of subordinate columnar objects of a reordered table exist Instances of subordinate columnar objects of a reordered table exist
according to the same semantics as instances of subordinate columnar according to the same semantics as instances of subordinate columnar
objects of the base table. As such, note that creation of a base objects of the base table. As such, note that creation of a base
table row implies the correspondent creation of any related table row implies the correspondent creation of any related reordered
reordered table row. Reordered tables MUST NOT be used in table row table row. Reordered tables MUST NOT be used in table row creation
creation and deletion operations. and deletion operations.
4.4.2.5 The table's expands Statement for Table Indexing 4.4.2.5 The table's expands Statement for Table Indexing
The table's `expands' statement is used to supply table indexing The table's `expands' statement is used to supply table indexing
information of table expansions. Table expansions use exactly the information of table expansions. Table expansions use exactly the
same index objects of another table together with additional same index objects of another table together with additional indexing
indexing objects. Thus, the `expands' statement gets at least two objects. Thus, the `expands' statement gets at least two arguments.
arguments. The first one specifies the identifier of the related The first one specifies the identifier of the related table. The
table. The second one specifies a comma-separated list of the second one specifies a comma-separated list of the additional object
additional object identifiers used for indexing. Note that an identifiers used for indexing. Note that an expanded table may
expanded table may itself be expanded, and related tables may be itself be expanded, and related tables may be used for multiple table
used for multiple table expansions. expansions.
Under some circumstances, an optional `implied' keyword may be added Under some circumstances, an optional `implied' keyword may be added
in front of the list to indicate a compact encoding of the last in front of the list to indicate a compact encoding of the last
object in the list. See Section 2.2 for details. object in the list. See Section 2.2 for details.
4.4.3 The table's create Statement 4.4.3 The table's create Statement
The table's `create' statement, which need not be present, gets no The table's `create' statement, which need not be present, gets no
argument. If the `create' statement is present, table row creation argument. If the `create' statement is present, table row creation
(and deletion) is possible. (and deletion) is possible.
4.4.4 The table's implements Statement 4.4.4 The table's implements Statement
The table's `implements' statement, which must be present at least The table's `implements' statement, which must be present at least
once, makes this table contain columnar objects that are defined by once, makes this table contain columnar objects that are defined by a
a given class. It gets two arguments: the class being implemented given class. It gets two arguments: the class being implemented and
and a statement block that holds detailed information on the a statement block that holds detailed information on the attributes
attributes of that class being implemented in an obligatory order. of that class being implemented in an obligatory order.
Note: It is possible to apply multiple implements statements to a Note: It is possible to apply multiple implements statements to a
single table statement, each specifying a distinct class. However, single table statement, each specifying a distinct class. However,
it is considerable to define a new class containing thoses classes it is considerable to define a new class containing thoses classes
and making the table implement that single container class. and making the table implement that single container class.
4.4.4.1 The implements' object Statement 4.4.4.1 The implements' object Statement
The `object' statement, which must be present at least once, makes a The `object' statement, which must be present at least once, makes a
single attribute of the class being contained as a columnar object single attribute of the class being contained as a columnar object in
in the table. It gets two arguments: the columnar object name and the table. It gets two arguments: the columnar object name and the
the class attribute being implemented. class attribute being implemented.
The object identifier of this columnar object is implicitly The object identifier of this columnar object is implicitly specified
specified by concatenating the table's object identifier, a single by concatenating the table's object identifier, a single sub-
sub-identifier of the value 1 (in SMIv2 this represents the table identifier of the value 1 (in SMIv2 this represents the table entry
entry definition) and the position of the object, starting at 1. definition) and the position of the object, starting at 1. [XXX see
[XXX see open issues: we better use mandatory explicit OID mapping.] open issues: we better use mandatory explicit OID mapping.]
4.4.5 The table's status Statement 4.4.5 The table's status Statement
The table's `status' statement, which need not be present, gets one The table's `status' statement, which must be present, gets one
argument which is used to specify whether this table definition is argument which is used to specify whether this table definition is
current or historic. The value `current' means that the definition current or historic. The value `current' means that the definition
is current and valid. The value `obsolete' means the definition is is current and valid. The value `obsolete' means the definition is
obsolete and should not be implemented and/or can be removed if obsolete and should not be implemented and/or can be removed if
previously implemented. While the value `deprecated' also indicates previously implemented. While the value `deprecated' also indicates
an obsolete definition, it permits new/continued implementation in an obsolete definition, it permits new/continued implementation in
order to foster interoperability with older/existing order to foster interoperability with older/existing implementations.
implementations.
Tables SHOULD NOT be defined as `current' if one or more of their Tables SHOULD NOT be defined as `current' if one or more of their
classes are `deprecated' or `obsolete'. Similarly, they SHOULD NOT classes are `deprecated' or `obsolete'. Similarly, they SHOULD NOT
be defined as `deprecated' if one or more of their classes are be defined as `deprecated' if one or more of their classes are
`obsolete'. Nevertheless, subsequent revisions of used class `obsolete'. Nevertheless, subsequent revisions of used class
definition cannot be avoided, but SHOULD be taken into account in definition cannot be avoided, but SHOULD be taken into account in
subsequent revisions of the local module. subsequent revisions of the local module.
If the `status' statement is omitted the status value `current' is
implied.
4.4.6 The table's description Statement 4.4.6 The table's description Statement
The table's `description' statement, which must be present, gets one The table's `description' statement, which must be present, gets one
argument which is used to specify a high-level textual description argument which is used to specify a high-level textual description of
of this table. this table.
It is RECOMMENDED to include all semantic definitions necessary for It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this scalar group. the implementation of this scalar group.
4.4.7 The table's reference Statement 4.4.7 The table's reference Statement
The table's `reference' statement, which need not be present, gets The table's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related some other document, either another module which defines related
definitions, or some other document which provides additional definitions, or some other document which provides additional
skipping to change at page 19, line 43 skipping to change at page 18, line 36
4.4.8 Usage Example 4.4.8 Usage Example
table ifTable { table ifTable {
oid interfaces.2; oid interfaces.2;
index (ifIndex); index (ifIndex);
implements Interface { implements Interface {
object ifIndex index; object ifIndex index;
object ifDescr description; object ifDescr description;
// ... // ...
} }
status current;
description description
"This table implements the Interface class."; "This table implements the Interface class.";
}; };
4.5 The notification Statement 4.5 The notification Statement
The `notification' statement is used to map events of classes to The `notification' statement is used to map events of classes to SNMP
SNMP notifications. The statement gets two arguments: a lower-case notifications. The statement gets two arguments: a lower-case
notification identifier and a statement block that holds detailed notification identifier and a statement block that holds detailed
notification information in an obligatory order. notification information in an obligatory order.
See the `notificationStatement' rule of the SMIng grammar (Section See the `notificationStatement' rule of the SMIng grammar (Section 5)
5) for the formal syntax of the `notification' statement. for the formal syntax of the `notification' statement.
4.5.1 The notification's oid Statement 4.5.1 The notification's oid Statement
The notification's `oid' statement, which must be present, gets one The notification's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is argument which specifies the object identifier value that is assigned
assigned to this notification. to this notification.
4.5.2 The notification's signals Statement 4.5.2 The notification's signals Statement
The notification's `signals' statement, which must be present, The notification's `signals' statement, which must be present,
denotes the event that is signaled by this notification. The denotes the event that is signaled by this notification. The
statement gets two argument: the event to be signaled (in the statement gets two argument: the event to be signaled (in the
qualifed form `Class.event') and a statement block that holds qualifed form `Class.event') and a statement block that holds
detailed information on the objects transmitted with this detailed information on the objects transmitted with this
notification in an obligatory order. notification in an obligatory order.
4.5.2.1 The signals' object Statement 4.5.2.1 The signals' object Statement
The signals' `object' statement, which can be present zero, one or The signals' `object' statement, which can be present zero, one or
multiple times, makes a single instance of a class attribute be multiple times, makes a single instance of a class attribute be
contained in this notification. It gets one argument: the specific contained in this notification. It gets one argument: the specific
class attribute. The namespace of attributes not specified by class attribute. The namespace of attributes not specified by
qualified names is the namespace of the event's class specified in qualified names is the namespace of the event's class specified in
the `signals' statement. the `signals' statement.
4.5.3 The notification's status Statement 4.5.3 The notification's status Statement
The notification's `status' statement, which need not be present, The notification's `status' statement, which must be present, gets
gets one argument which is used to specify whether this notification one argument which is used to specify whether this notification
definition is current or historic. The value `current' means that definition is current or historic. The value `current' means that
the definition is current and valid. The value `obsolete' means the the definition is current and valid. The value `obsolete' means the
definition is obsolete and should not be implemented and/or can be definition is obsolete and should not be implemented and/or can be
removed if previously implemented. While the value `deprecated' removed if previously implemented. While the value `deprecated' also
also indicates an obsolete definition, it permits new/continued indicates an obsolete definition, it permits new/continued
implementation in order to foster interoperability with implementation in order to foster interoperability with
older/existing implementations. older/existing implementations.
If the `status' statement is omitted, the status value `current' is
implied.
4.5.4 The notification's description Statement 4.5.4 The notification's description Statement
The notification's `description' statement, which need not be The notification's `description' statement, which need not be
present, gets one argument which is used to specify a high-level present, gets one argument which is used to specify a high-level
textual description of this notification. textual description of this notification.
It is RECOMMENDED to include all semantics and purposes of this It is RECOMMENDED to include all semantics and purposes of this
notification. notification.
4.5.5 The notification's reference Statement 4.5.5 The notification's reference Statement
skipping to change at page 21, line 23 skipping to change at page 20, line 18
4.5.6 Usage Example 4.5.6 Usage Example
notification linkDown { notification linkDown {
oid snmpTraps.3; oid snmpTraps.3;
signals Interface.linkDown { signals Interface.linkDown {
object ifIndex; object ifIndex;
object ifAdminStatus; object ifAdminStatus;
object ifOperStatus; object ifOperStatus;
}; };
status current;
description description
"This notification signals the linkDown event "This notification signals the linkDown event
of the Interface class."; of the Interface class.";
}; };
4.6 The group Statement 4.6 The group Statement
The `group' statement is used to define a group of arbitrary nodes The `group' statement is used to define a group of arbitrary nodes in
in the object identifier tree. It gets two arguments: a lower-case the object identifier tree. It gets two arguments: a lower-case
group identifier and a statement block that holds detailed group group identifier and a statement block that holds detailed group
information in an obligatory order. information in an obligatory order.
Note that the primary application of groups are compliance Note that the primary application of groups are compliance
statements, although they might be referred in other formal or statements, although they might be referred in other formal or
informal documents. informal documents.
See the `groupStatement' rule of the SMIng grammar (Section 5) for See the `groupStatement' rule of the SMIng grammar (Section 5) for
the formal syntax of the `group' statement. the formal syntax of the `group' statement.
4.6.1 The group's oid Statement 4.6.1 The group's oid Statement
The group's `oid' statement, which must be present, gets one The group's `oid' statement, which must be present, gets one argument
argument which specifies the object identifier value that is which specifies the object identifier value that is assigned to this
assigned to this group. group.
4.6.2 The group's members Statement 4.6.2 The group's members Statement
The group's `members' statement, which must be present, gets one The group's `members' statement, which must be present, gets one
argument which specifies the list of nodes by their identifiers to argument which specifies the list of nodes by their identifiers to be
be contained in this group. The list of nodes has to be contained in this group. The list of nodes has to be comma-separated
comma-separated and enclosed in parenthesis. and enclosed in parenthesis.
4.6.3 The group's status Statement 4.6.3 The group's status Statement
The group's `status' statement, which need not be present, gets one The group's `status' statement, which must be present, gets one
argument which is used to specify whether this group definition is argument which is used to specify whether this group definition is
current or historic. The value `current' means that the definition current or historic. The value `current' means that the definition
is current and valid. The value `obsolete' means the definition is is current and valid. The value `obsolete' means the definition is
obsolete and the group should no longer be used. While the value obsolete and the group should no longer be used. While the value
`deprecated' also indicates an obsolete definition, it permits `deprecated' also indicates an obsolete definition, it permits
new/continued use of this group. new/continued use of this group.
If the `status' statement is omitted the status value `current' is
implied.
4.6.4 The group's description Statement 4.6.4 The group's description Statement
The group's `description' statement, which must be present, gets one The group's `description' statement, which must be present, gets one
argument which is used to specify a high-level textual description argument which is used to specify a high-level textual description of
of this group. It is RECOMMENDED to include any relation to other this group. It is RECOMMENDED to include any relation to other
groups. groups.
4.6.5 The group's reference Statement 4.6.5 The group's reference Statement
The group's `reference' statement, which need not be present, gets The group's `reference' statement, which need not be present, gets
one argument which is used to specify a textual cross-reference to one argument which is used to specify a textual cross-reference to
some other document, either another module which defines related some other document, either another module which defines related
groups, or some other document which provides additional information groups, or some other document which provides additional information
relevant to this group. relevant to this group.
skipping to change at page 22, line 45 skipping to change at page 21, line 41
The snmpGroup, originally defined in [14], may be described as The snmpGroup, originally defined in [14], may be described as
follows: follows:
group snmpGroup { group snmpGroup {
oid snmpMIBGroups.8; oid snmpMIBGroups.8;
objects (snmpInPkts, snmpInBadVersions, objects (snmpInPkts, snmpInBadVersions,
snmpInASNParseErrs, snmpInASNParseErrs,
snmpSilentDrops, snmpProxyDrops, snmpSilentDrops, snmpProxyDrops,
snmpEnableAuthenTraps); snmpEnableAuthenTraps);
status current;
description description
"A collection of objects providing basic "A collection of objects providing basic
instrumentation and control of an agent."; instrumentation and control of an agent.";
}; };
4.7 The compliance Statement 4.7 The compliance Statement
The `compliance' statement is used to define a set of compliance The `compliance' statement is used to define a set of compliance
requirements, named a `compliance statement'. It gets two arguments: requirements, named a `compliance statement'. It gets two arguments:
a lower-case compliance identifier and a statement block that holds a lower-case compliance identifier and a statement block that holds
detailed compliance information in an obligatory order. detailed compliance information in an obligatory order.
See the `complianceStatement' rule of the SMIng grammar (Section 5) See the `complianceStatement' rule of the SMIng grammar (Section 5)
for the formal syntax of the `compliance' statement. for the formal syntax of the `compliance' statement.
4.7.1 The compliance's oid Statement 4.7.1 The compliance's oid Statement
The compliance's `oid' statement, which must be present, gets one The compliance's `oid' statement, which must be present, gets one
argument which specifies the object identifier value that is argument which specifies the object identifier value that is assigned
assigned to this compliance statement. to this compliance statement.
4.7.2 The compliance's status Statement 4.7.2 The compliance's status Statement
The compliance's `status' statement, which need not be present, gets The compliance's `status' statement, which must be present, gets one
one argument which is used to specify whether this compliance argument which is used to specify whether this compliance statement
statement is current or historic. The value `current' means that the is current or historic. The value `current' means that the
definition is current and valid. The value `obsolete' means the definition is current and valid. The value `obsolete' means the
definition is obsolete and no longer specifies a valid definition of definition is obsolete and no longer specifies a valid definition of
conformance. While the value `deprecated' also indicates an conformance. While the value `deprecated' also indicates an obsolete
obsolete definition, it permits new/continued use of the compliance definition, it permits new/continued use of the compliance
specification. specification.
If the `status' statement is omitted the status value `current' is
implied.
4.7.3 The compliance's description Statement 4.7.3 The compliance's description Statement
The compliance's `description' statement, which must be present, The compliance's `description' statement, which must be present, gets
gets one argument which is used to specify a high-level textual one argument which is used to specify a high-level textual
description of this compliance statement. description of this compliance statement.
4.7.4 The compliance's reference Statement 4.7.4 The compliance's reference Statement
The compliance's `reference' statement, which need not be present, The compliance's `reference' statement, which need not be present,
gets one argument which is used to specify a textual cross-reference gets one argument which is used to specify a textual cross-reference
to some other document, either another module which defines related to some other document, either another module which defines related
compliance statements, or some other document which provides compliance statements, or some other document which provides
additional information relevant to this compliance statement. additional information relevant to this compliance statement.
4.7.5 The compliance's mandatory Statement 4.7.5 The compliance's mandatory Statement
The compliance's `mandatory' statement, which need not be present, The compliance's `mandatory' statement, which need not be present,
gets one argument which is used to specify a comma-separated list of gets one argument which is used to specify a comma-separated list of
one or more groups (Section 4.6) of objects and/or notifications one or more groups (Section 4.6) of objects and/or notifications
enclosed in parenthesis. These groups are unconditionally mandatory enclosed in parenthesis. These groups are unconditionally mandatory
for implementation. for implementation.
If an agent claims compliance to a MIB module then it must implement If an agent claims compliance to a MIB module then it must implement
each and every object and notification within each group listed the each and every object and notification within each group listed the
`mandatory' statement(s) of the compliance statement(s) of that `mandatory' statement(s) of the compliance statement(s) of that
module. module.
4.7.6 The compliance's optional Statement 4.7.6 The compliance's optional Statement
The compliance's `optional' statement, which need not be present, is The compliance's `optional' statement, which need not be present, is
repeatedly used to name each group which is conditionally mandatory repeatedly used to name each group which is conditionally mandatory
for compliance to the module. It can also be used to name for compliance to the module. It can also be used to name
unconditionally optional groups. A group named in an `optional' unconditionally optional groups. A group named in an `optional'
statement MUST be absent from the correspondent `mandatory' statement MUST be absent from the correspondent `mandatory'
statement. The `optional' statement gets two arguments: a lower-case statement. The `optional' statement gets two arguments: a lower-case
group identifier and a statement block that holds detailed group identifier and a statement block that holds detailed compliance
compliance information on that group. information on that group.
Conditionally mandatory groups include those which are mandatory Conditionally mandatory groups include those which are mandatory only
only if a particular protocol is implemented, or only if another if a particular protocol is implemented, or only if another group is
group is implemented. The `description' statement specifies the implemented. The `description' statement specifies the conditions
conditions under which the group is conditionally mandatory. under which the group is conditionally mandatory.
A group which is named in neither a `mandatory' statement nor an A group which is named in neither a `mandatory' statement nor an
`optional' statement, is unconditionally optional for compliance to `optional' statement, is unconditionally optional for compliance to
the module. the module.
See the `optionalStatement' rule of the SMIng grammar (Section 5) See the `optionalStatement' rule of the SMIng grammar (Section 5) for
for the formal syntax of the `optional' statement. the formal syntax of the `optional' statement.
4.7.6.1 The optional's description Statement 4.7.6.1 The optional's description Statement
The optional's `description' statement, which must be present, gets The optional's `description' statement, which must be present, gets
one argument which is used to specify a high-level textual one argument which is used to specify a high-level textual
description of the conditions under which this group is description of the conditions under which this group is conditionally
conditionally mandatory or unconditionally optional. mandatory or unconditionally optional.
4.7.7 The compliance's refine Statement 4.7.7 The compliance's refine Statement
The compliance's `refine' statement, which need not be present, is The compliance's `refine' statement, which need not be present, is
repeatedly used to specify each object for which compliance has a repeatedly used to specify each object for which compliance has a
refined requirement with respect to the module definition. The refined requirement with respect to the module definition. The
object must be present in one of the conformance groups named in the object must be present in one of the conformance groups named in the
correspondent `mandatory' or `optional' statements. The `refine' correspondent `mandatory' or `optional' statements. The `refine'
statement gets two arguments: a lower-case identifier of a scalar or statement gets two arguments: a lower-case identifier of a scalar or
columnar object and a statement block that holds detailed refinement columnar object and a statement block that holds detailed refinement
information on that object. information on that object.
See the `refineStatement' rule of the SMIng grammar (Section 5) for See the `refineStatement' rule of the SMIng grammar (Section 5) for
the formal syntax of the `refine' statement. the formal syntax of the `refine' statement.
4.7.7.1 The refine's type Statement 4.7.7.1 The refine's type Statement
The refine's `type' statement, which need not be present, gets one The refine's `type' statement, which need not be present, gets one
argument that is used to provide a refined type for the argument that is used to provide a refined type for the correspondent
correspondent object. Type restrictions may be applied by appending object. Type restrictions may be applied by appending subtyping
subtyping information according to the rules of the base type. See information according to the rules of the base type. See [1] for
[1] for SMIng base types and their type restrictions. In case of SMIng base types and their type restrictions. In case of enumeration
enumeration or bitset types the order of named numbers is not or bitset types the order of named numbers is not significant.
significant.
Note that if a `type' and a `writetype' statement are both present Note that if a `type' and a `writetype' statement are both present
then this type only applies when instances of the correspondent then this type only applies when instances of the correspondent
object are read. object are read.
4.7.7.2 The refine's writetype Statement 4.7.7.2 The refine's writetype Statement
The refine's `writetype' statement, which need not be present, gets The refine's `writetype' statement, which need not be present, gets
one argument that is used to provide a refined type for the one argument that is used to provide a refined type for the
correspondent object, only when instances of that object are correspondent object, only when instances of that object are written.
written. Type restrictions may be applied by appending subtyping Type restrictions may be applied by appending subtyping information
information according to the rules of the base type. See [1] for according to the rules of the base type. See [1] for SMIng base
SMIng base types and their type restrictions. In case of enumeration types and their type restrictions. In case of enumeration or bitset
or bitset types the order of named numbers is not significant. types the order of named numbers is not significant.
4.7.7.3 The refine's access Statement 4.7.7.3 The refine's access Statement
The refine's `access' statement, which need not be present, gets one The refine's `access' statement, which need not be present, gets one
argument that is used to specify the minimal level of access that argument that is used to specify the minimal level of access that the
the correspondent object must implement in the sense of its original correspondent object must implement in the sense of its original
`access' statement. Hence, the refine's `access' statement MUST NOT `access' statement. Hence, the refine's `access' statement MUST NOT
specify a greater level of access than is specified in the specify a greater level of access than is specified in the
correspondent object definition. correspondent object definition.
An implementation is compliant if the level of access it provides is An implementation is compliant if the level of access it provides is
greater or equal to the minimal level in the refine's `access' 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 statement and less or equal to the maximal level in the object's
`access' statement. `access' statement.
4.7.7.4 The refine's description Statement 4.7.7.4 The refine's description Statement
The refine's `description' statement, which must be present, gets The refine's `description' statement, which must be present, gets one
one argument which is used to specify a high-level textual argument which is used to specify a high-level textual description of
description of the refined compliance requirement. the refined compliance requirement.
4.7.8 Usage Example 4.7.8 Usage Example
The compliance statement contained in the SNMPv2-MIB, converted to The compliance statement contained in the SNMPv2-MIB, converted to
SMIng: SMIng:
compliance snmpBasicCompliance { compliance snmpBasicCompliance {
oid snmpMIBCompliances.2; oid snmpMIBCompliances.2;
status current;
description description
"The compliance statement for SNMPv2 entities which "The compliance statement for SNMPv2 entities which
implement the SNMPv2 MIB."; implement the SNMPv2 MIB.";
mandatory (snmpGroup, snmpSetGroup, systemGroup, mandatory (snmpGroup, snmpSetGroup, systemGroup,
snmpBasicNotificationsGroup); snmpBasicNotificationsGroup);
optional snmpCommunityGroup { optional snmpCommunityGroup {
description description
"This group is mandatory for SNMPv2 entities which "This group is mandatory for SNMPv2 entities which
support community-based authentication."; support community-based authentication.";
}; };
}; };
5. IETF-SMING-SNMP-EXT 5. IETF-SMING-SNMP-EXT
The grammar of the SNMP mapping SMIng extension conforms to the The grammar of the SNMP mapping SMIng extension conforms to the
Augmented Backus-Naur Form (ABNF)[11]. It is included in the abnf Augmented Backus-Naur Form (ABNF) [11]. It is included in the abnf
statement of the snmp SMIng extension definition in the statement of the snmp SMIng extension definition in the IETF-SMING-
IETF-SMING-SNMP-EXT module below. SNMP-EXT module below.
module IETF-SMING-SNMP-EXT { module IETF-SMING-SNMP-EXT {
organization "IETF Next Generation Structure of organization "IETF Next Generation Structure of
Management Information Working Group (SMING)"; Management Information Working Group (SMING)";
contact "Frank Strauss contact "Frank Strauss
TU Braunschweig TU Braunschweig
Bueltenweg 74/75 Bueltenweg 74/75
skipping to change at page 27, line 53 skipping to change at page 26, line 21
extension snmp { extension snmp {
description description
"The snmp statement maps SMIng definitions to SNMP "The snmp statement maps SMIng definitions to SNMP
conformant definitions."; conformant definitions.";
abnf " abnf "
;; ;;
;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF ;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF
;; notation (RFC 2234). ;; notation (RFC 2234).
;; ;;
;; @(#) $Id: sming-snmp.abnf,v 1.7 2000/11/25 10:10:47 strauss Exp $ ;; @(#) $Id: sming-snmp.abnf,v 1.8 2001/03/07 15:06:56 strauss Exp $
;; ;;
;; Copyright (C) The Internet Society (2001). All Rights Reserved. ;; Copyright (C) The Internet Society (2001). All Rights Reserved.
;; ;;
;; ;;
;; Statement rules. ;; Statement rules.
;; ;;
snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep
"{" stmtsep '{' stmtsep
*1(oidStatement stmtsep) *1(oidStatement stmtsep)
*(nodeStatement stmtsep) *(nodeStatement stmtsep)
*(scalarsStatement stmtsep) *(scalarsStatement stmtsep)
*(tableStatement stmtsep) *(tableStatement stmtsep)
*(notificationStatement stmtsep) *(notificationStatement stmtsep)
*(groupStatement stmtsep) *(groupStatement stmtsep)
*(complianceStatement stmtsep) *(complianceStatement stmtsep)
*1(statusStatement stmtsep) *1(statusStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" '}' optsep ';'
nodeStatement = nodeKeyword sep lcIdentifier optsep nodeStatement = nodeKeyword sep lcIdentifier optsep
"{" stmtsep '{' stmtsep
oidStatement stmtsep oidStatement stmtsep
*1(representsStatement stmtsep) *1(representsStatement stmtsep)
*1(statusStatement stmtsep) *1(statusStatement stmtsep)
*1(descriptionStatement stmtsep) *1(descriptionStatement stmtsep)
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" '}' optsep ';'
representsStatement = representsKeyword sep representsStatement = representsKeyword sep
qucIdentifier optsep ";" qucIdentifier optsep ';'
scalarsStatement = scalarsKeyword sep lcIdentifier optsep scalarsStatement = scalarsKeyword sep lcIdentifier optsep
"{" stmtsep '{' stmtsep
oidStatement stmtsep oidStatement stmtsep
1*(implementsStatement stmtsep) 1*(implementsStatement stmtsep)
*1(statusStatement stmtsep) *1(statusStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" '}' optsep ';'
tableStatement = tableKeyword sep lcIdentifier optsep tableStatement = tableKeyword sep lcIdentifier optsep
"{" stmtsep '{' stmtsep
oidStatement stmtsep oidStatement stmtsep
anyIndexStatement stmtsep anyIndexStatement stmtsep
*1(createStatement stmtsep) *1(createStatement stmtsep)
1*(implementsStatement stmtsep) 1*(implementsStatement stmtsep)
*1(statusStatement stmtsep) *1(statusStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" '}' optsep ';'
implementsStatement = implementsKeyword sep qucIdentifier optsep implementsStatement = implementsKeyword sep qucIdentifier optsep
"{" stmtsep '{' stmtsep
1*(implObjectStatement stmtsep) 1*(implObjectStatement stmtsep)
"}" optsep ";" '}' optsep ';'
implObjectStatement = objectKeyword sep implObjectStatement = objectKeyword sep
lcIdentifier sep lcIdentifier sep
attrIdentifier optsep; attrIdentifier optsep;
notificationStatement = notificationKeyword sep lcIdentifier notificationStatement = notificationKeyword sep lcIdentifier
optsep "{" stmtsep optsep '{' stmtsep
oidStatement stmtsep oidStatement stmtsep
signalsStatement stmtsep signalsStatement stmtsep
*1(statusStatement stmtsep) *1(statusStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" '}' optsep ';'
signalsStatement = signalsKeyword sep qattrIdentifier signalsStatement = signalsKeyword sep qattrIdentifier
optsep "{" stmtsep optsep '{' stmtsep
*(signalsObjectStatement) *(signalsObjectStatement)
"}" optsep ";" '}' optsep ';'
signalsObjectStatement = objectKeyword sep signalsObjectStatement = objectKeyword sep
qattrIdentifier optsep ";" qattrIdentifier optsep ';'
groupStatement = groupKeyword sep lcIdentifier optsep groupStatement = groupKeyword sep lcIdentifier optsep
"{" stmtsep '{' stmtsep
oidStatement stmtsep oidStatement stmtsep
membersStatement stmtsep membersStatement stmtsep
*1(statusStatement stmtsep) *1(statusStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" '}' optsep ';'
complianceStatement = complianceKeyword sep lcIdentifier optsep complianceStatement = complianceKeyword sep lcIdentifier optsep
"{" stmtsep '{' stmtsep
oidStatement stmtsep oidStatement stmtsep
*1(statusStatement stmtsep) *1(statusStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
*1(mandatoryStatement stmtsep) *1(mandatoryStatement stmtsep)
*(optionalStatement stmtsep) *(optionalStatement stmtsep)
*(refineStatement stmtsep) *(refineStatement stmtsep)
'}' optsep ';'
"}" optsep ";"
anyIndexStatement = indexStatement / anyIndexStatement = indexStatement /
augmentsStatement / augmentsStatement /
reordersStatement / reordersStatement /
extendsStatement / extendsStatement /
expandsStatement expandsStatement
indexStatement = indexKeyword *1(sep impliedKeyword) optsep indexStatement = indexKeyword *1(sep impliedKeyword) optsep
"(" optsep qlcIdentifierList '(' optsep qlcIdentifierList
optsep ")" optsep ";" optsep ')' optsep ';'
augmentsStatement = augmentsKeyword sep qlcIdentifier augmentsStatement = augmentsKeyword sep qlcIdentifier
optsep ";" optsep ';'
reordersStatement = reordersKeyword sep qlcIdentifier reordersStatement = reordersKeyword sep qlcIdentifier
*1(sep impliedKeyword) *1(sep impliedKeyword)
optsep "(" optsep optsep '(' optsep
qlcIdentifierList optsep ")" qlcIdentifierList optsep ')'
optsep ";" optsep ';'
extendsStatement = extendsKeyword sep qlcIdentifier optsep ";" extendsStatement = extendsKeyword sep qlcIdentifier optsep ';'
expandsStatement = expandsKeyword sep qlcIdentifier expandsStatement = expandsKeyword sep qlcIdentifier
*1(sep impliedKeyword) *1(sep impliedKeyword)
optsep "(" optsep optsep '(' optsep
qlcIdentifierList optsep ")" qlcIdentifierList optsep ')'
optsep ";" optsep ';'
createStatement = createKeyword optsep ";"
membersStatement = membersKeyword optsep "(" optsep createStatement = createKeyword optsep ';'
membersStatement = membersKeyword optsep '(' optsep
qlcIdentifierList optsep qlcIdentifierList optsep
")" optsep ";" ')' optsep ';'
mandatoryStatement = mandatoryKeyword optsep "(" optsep mandatoryStatement = mandatoryKeyword optsep '(' optsep
qlcIdentifierList optsep qlcIdentifierList optsep
")" optsep ";" ')' optsep ';'
optionalStatement = optionalKeyword sep qlcIdentifier optsep optionalStatement = optionalKeyword sep qlcIdentifier optsep
"{" descriptionStatement stmtsep '{' descriptionStatement stmtsep
"}" optsep ";" '}' optsep ';'
refineStatement = refineKeyword sep qlcIdentifier optsep "{" refineStatement = refineKeyword sep qlcIdentifier optsep '{'
*1(typeStatement stmtsep) *1(typeStatement stmtsep)
*1(writetypeStatement stmtsep) *1(writetypeStatement stmtsep)
*1(accessStatement stmtsep) *1(accessStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
"}" optsep ";" '}' optsep ';'
typeStatement = typeKeyword sep typeStatement = typeKeyword sep
(refinedBaseType / refinedType) (refinedBaseType / refinedType)
optsep ";" optsep ';'
writetypeStatement = writetypeKeyword sep writetypeStatement = writetypeKeyword sep
(refinedBaseType / refinedType) (refinedBaseType / refinedType)
optsep ";" optsep ';'
oidStatement = oidKeyword sep objectIdentifier optsep ";" oidStatement = oidKeyword sep objectIdentifier optsep ';'
;; ;;
;; ;;
;; ;;
objectIdentifier = (qlcIdentifier / subid) *127("." subid) objectIdentifier = (qlcIdentifier / subid) *127('.' subid)
subid = decimalNumber subid = decimalNumber
;; ;;
;; Statement keywords. ;; Statement keywords.
;; ;;
snmpKeyword = %x73 %x6E %x6D %x70 snmpKeyword = %x73 %x6E %x6D %x70
nodeKeyword = %x6E %x6F %x64 %x65 nodeKeyword = %x6E %x6F %x64 %x65
representsKeyword = %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6E %x74 representsKeyword = %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6E %x74
skipping to change at page 48, line 9 skipping to change at page 45, line 34
This type does not allow a zero-length TAddress value." This type does not allow a zero-length TAddress value."
}; };
}; };
7. Security Considerations 7. Security Considerations
This document presents an extension of the SMIng data definition This document presents an extension of the SMIng data definition
langauge which support the mapping of SMIng data definitions so that langauge which support the mapping of SMIng data definitions so that
they can be used with the SNMP management framework. The language they can be used with the SNMP management framework. The language
extension and the mapping itself has no security impact on the extension and the mapping itself has no security impact on the
Internet. Internet.
8. Acknowledgements 8. Acknowledgements
Since SMIng started as a close successor of SMIv2, some paragraphs Since SMIng started as a close successor of SMIv2, some paragraphs
and phrases are directly taken from the SMIv2 specifications [5], and phrases are directly taken from the SMIv2 specifications [5],
[6], [7] written by Jeff Case, Keith McCloghrie, David Perkins, [6], [7] written by Jeff Case, Keith McCloghrie, David Perkins,
Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser. Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser.
The authors would like to thank all participants of the 7th NMRG The authors would like to thank all participants of the 7th NMRG
meeting held in Schloss Kleinheubach from 6-8 September 2000, which meeting held in Schloss Kleinheubach from 6-8 September 2000, which
was a major step towards the current status of this memo, namely was a major step towards the current status of this memo, namely
Heiko Dassow, David Durham, and Bert Wijnen. Heiko Dassow, David Durham, and Bert Wijnen.
Marshall T. Rose's work on an XML framework for RFC authors [15] Marshall T. Rose's work on an XML framework for RFC authors [15]
made the writing of an Internet standards document much more made the writing of an Internet standards document much more
comfortable. comfortable.
References References
[1] Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng - Next [1] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Generation Structure of Management Information", Structure of Management Information", draft-ietf-sming-02.txt,
draft-ietf-sming-01.txt, March 2001. July 2001.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[3] Case, J., Mundy, R., Partain, D., Stewart, B., "Introduction to [3] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
Version 3 of the Internet-standard Network Management to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999. Framework", RFC 2570, April 1999.
[4] Harrington, D., Presuhn, R., Wijnen, B., "An Architecture for [4] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999. Describing SNMP Management Frameworks", RFC 2571, April 1999.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., Waldbusser, S., "Structure of Management Information M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. Version 2 (SMIv2)", RFC 2578, STD 58, April 1999.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., Waldbusser, S., "Textual Conventions for SMIv2", RFC 2579, M. and S. Waldbusser, "Textual Conventions for SMIv2", RFC
STD 59, April 1999. 2579, STD 59, April 1999.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., Waldbusser, S., "Conformance Statements for SMIv2", RFC M. and S. Waldbusser, "Conformance Statements for SMIv2", RFC
2580, STD 60, April 1999. 2580, STD 60, April 1999.
[8] Rose, M., McCloghrie, K., "Structure and Identification of [8] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155, Management Information for TCP/IP-based Internets", RFC 1155,
STD 16, May 1990. STD 16, May 1990.
[9] Rose, M., McCloghrie, K., "Concise MIB Definitions", RFC 1212, [9] Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC
STD 16, March 1991. 1212, STD 16, March 1991.
[10] Rose, M., "A Convention for Defining Traps for use with the [10] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991. SNMP", RFC 1215, March 1991.
[11] Crocker, D., Overell, P., "Augmented BNF for Syntax [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[12] International Organization for Standardization, "Specification [12] International Organization for Standardization, "Specification
of Abstract Syntax Notation One (ASN.1)", International of Abstract Syntax Notation One (ASN.1)", International
Standard 8824, December 1987. Standard 8824, December 1987.
[13] Institute of Electrical and Electronics Engineers, "IEEE [13] Institute of Electrical and Electronics Engineers, "IEEE
Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
Standard 754-1985, August 1985. Standard 754-1985, August 1985.
[14] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Management Information Base for Version 2 of the Simple "Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1907, January 1996. Network Management Protocol (SNMPv2)", RFC 1907, January 1996.
[15] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June [15] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999. 1999.
[16] Presuhn, R., Case, J., McCloghrie, K., Rose, M., Waldbusser, [16] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
S., "Version 2 of the Protocol Operations for the Simple Waldbusser, "Version 2 of the Protocol Operations for the
Network Management Protocol", Simple Network Management Protocol", draft-ietf-snmpv3-update-
draft-ietf-snmpv3-update-proto-05.txt, August 2000. proto-06.txt, July 2001.
Authors' Addresses Authors' Addresses
Frank Strauss Frank Strauss
TU Braunschweig TU Braunschweig
Bueltenweg 74/75 Bueltenweg 74/75
38106 Braunschweig 38106 Braunschweig
Germany Germany
Phone: +49 531 391-3266 Phone: +49 531 391-3266
skipping to change at page 51, line 39 skipping to change at page 47, line 41
Juergen Schoenwaelder Juergen Schoenwaelder
TU Braunschweig TU Braunschweig
Bueltenweg 74/75 Bueltenweg 74/75
38106 Braunschweig 38106 Braunschweig
Germany Germany
Phone: +49 531 391-3289 Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/ URI: http://www.ibr.cs.tu-bs.de/
Keith McCloghrie
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Phone: +1 408 526 5260
EMail: kzm@cisco.com
URI: http://www.cisco.com/
Appendix A. SMIng SNMP Mapping ABNF Grammar Appendix A. SMIng SNMP Mapping ABNF Grammar
The grammar of the SMIng SNMP mapping conforms to the Augmented The grammar of the SMIng SNMP mapping conforms to the Augmented
Backus-Naur Form (ABNF)[11]. Backus-Naur Form (ABNF) [11].
;; ;;
;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF ;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF
;; notation (RFC 2234). ;; notation (RFC 2234).
;; ;;
;; @(#) $Id: sming-snmp.abnf,v 1.7 2000/11/25 10:10:47 strauss Exp $ ;; @(#) $Id: sming-snmp.abnf,v 1.9 2001/07/20 14:13:10 strauss Exp $
;; ;;
;; Copyright (C) The Internet Society (2001). All Rights Reserved. ;; Copyright (C) The Internet Society (2001). All Rights Reserved.
;; ;;
;; ;;
;; Statement rules. ;; Statement rules.
;; ;;
snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep
"{" stmtsep "{" stmtsep
*1(oidStatement stmtsep) *1(oidStatement stmtsep)
*(nodeStatement stmtsep) *(nodeStatement stmtsep)
*(scalarsStatement stmtsep) *(scalarsStatement stmtsep)
*(tableStatement stmtsep) *(tableStatement stmtsep)
*(notificationStatement stmtsep) *(notificationStatement stmtsep)
*(groupStatement stmtsep) *(groupStatement stmtsep)
*(complianceStatement stmtsep) *(complianceStatement stmtsep)
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
nodeStatement = nodeKeyword sep lcIdentifier optsep nodeStatement = nodeKeyword sep lcIdentifier optsep
"{" stmtsep "{" stmtsep
oidStatement stmtsep oidStatement stmtsep
*1(representsStatement stmtsep) *1(representsStatement stmtsep)
*1(statusStatement stmtsep) statusStatement stmtsep
*1(descriptionStatement stmtsep) *1(descriptionStatement stmtsep)
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
representsStatement = representsKeyword sep representsStatement = representsKeyword sep
qucIdentifier optsep ";" qucIdentifier optsep ";"
scalarsStatement = scalarsKeyword sep lcIdentifier optsep scalarsStatement = scalarsKeyword sep lcIdentifier optsep
"{" stmtsep "{" stmtsep
oidStatement stmtsep oidStatement stmtsep
1*(implementsStatement stmtsep) 1*(implementsStatement stmtsep)
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
tableStatement = tableKeyword sep lcIdentifier optsep tableStatement = tableKeyword sep lcIdentifier optsep
"{" stmtsep "{" stmtsep
oidStatement stmtsep oidStatement stmtsep
anyIndexStatement stmtsep anyIndexStatement stmtsep
*1(createStatement stmtsep) *1(createStatement stmtsep)
1*(implementsStatement stmtsep) 1*(implementsStatement stmtsep)
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
implementsStatement = implementsKeyword sep qucIdentifier optsep implementsStatement = implementsKeyword sep qucIdentifier optsep
"{" stmtsep "{" stmtsep
1*(implObjectStatement stmtsep) 1*(implObjectStatement stmtsep)
"}" optsep ";" "}" optsep ";"
implObjectStatement = objectKeyword sep implObjectStatement = objectKeyword sep
lcIdentifier sep lcIdentifier sep
attrIdentifier optsep; attrIdentifier optsep;
notificationStatement = notificationKeyword sep lcIdentifier notificationStatement = notificationKeyword sep lcIdentifier
optsep "{" stmtsep optsep "{" stmtsep
oidStatement stmtsep oidStatement stmtsep
signalsStatement stmtsep signalsStatement stmtsep
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
signalsStatement = signalsKeyword sep qattrIdentifier signalsStatement = signalsKeyword sep qattrIdentifier
optsep "{" stmtsep optsep "{" stmtsep
*(signalsObjectStatement) *(signalsObjectStatement)
"}" optsep ";" "}" optsep ";"
signalsObjectStatement = objectKeyword sep signalsObjectStatement = objectKeyword sep
qattrIdentifier optsep ";" qattrIdentifier optsep ";"
groupStatement = groupKeyword sep lcIdentifier optsep groupStatement = groupKeyword sep lcIdentifier optsep
"{" stmtsep "{" stmtsep
oidStatement stmtsep oidStatement stmtsep
membersStatement stmtsep membersStatement stmtsep
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
complianceStatement = complianceKeyword sep lcIdentifier optsep complianceStatement = complianceKeyword sep lcIdentifier optsep
"{" stmtsep "{" stmtsep
oidStatement stmtsep oidStatement stmtsep
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
*1(mandatoryStatement stmtsep) *1(mandatoryStatement stmtsep)
*(optionalStatement stmtsep) *(optionalStatement stmtsep)
*(refineStatement stmtsep) *(refineStatement stmtsep)
"}" optsep ";" "}" optsep ";"
anyIndexStatement = indexStatement / anyIndexStatement = indexStatement /
augmentsStatement / augmentsStatement /
reordersStatement / reordersStatement /
skipping to change at page 57, line 8 skipping to change at page 52, line 19
refineKeyword = %x72 %x65 %x66 %x69 %x6E %x65 refineKeyword = %x72 %x65 %x66 %x69 %x6E %x65
writetypeKeyword = %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65 writetypeKeyword = %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65
;; ;;
;; EOF ;; EOF
;; ;;
Appendix B. OPEN ISSUES Appendix B. OPEN ISSUES
Pointers - We don't know how to express assiciations/relations to Pointers - We don't know how to express assiciations/relations to
class instances or attribute instances. If we should define a class instances or attribute instances. If we should define a
`Pointer' base type, it would probably be mapped to OIDs. One can `Pointer' base type, it would probably be mapped to OIDs. One can
argue to generalize the concept of pointers so that they can be argue to generalize the concept of pointers so that they can be
used to model relationships that are not necessarily realized by used to model relationships that are not necessarily realized by
OID pointers. OID pointers.
Associations - In general, the modeling of associations between Associations - In general, the modeling of associations between
instances may need better supported at the SMIng data definition instances may need better supported at the SMIng data definition
level so that SNMP table interrelationships just map these level so that SNMP table interrelationships just map these
instance-level associations. instance-level associations.
Mapping to SNMPv1 - The data type mapping is currently only defined Mapping to SNMPv1 - The data type mapping is currently only defined
for SNMPv2c and SNMPv3. A straight-forward extension is possible for SNMPv2c and SNMPv3. A straight-forward extension is possible
to also support SNMPv1. to also support SNMPv1.
Conversion SMIng -> SMIv2 - It may be useful to define the Conversion SMIng -> SMIv2 - It may be useful to define the
conversion from SMIng to SMIv2. conversion from SMIng to SMIv2.
Conversion SMIv2 -> SMIng - It may be useful to define the Conversion SMIv2 -> SMIng - It may be useful to define the
conversion from SMIv2 to SMIng. conversion from SMIv2 to SMIng.
Revision of IETF-SMING-SNMP - The IETF-SMING-SNMP needs a serious Revision of IETF-SMING-SNMP - The IETF-SMING-SNMP needs a serious
review to see which wordings must be adapted to the new review to see which wordings must be adapted to the new
terminology. Perhaps some new classes should be added (such as a terminology. Perhaps some new classes should be added (such as a
grouping of RowStatus and StorageType). grouping of RowStatus and StorageType).
Document Structure - There are some parts in this document which Document Structure - There are some parts in this document which
will also be needed by the COPS-PR mapping. Does it make sense to will also be needed by the COPS-PR mapping. Does it make sense to
separate them out? separate them out?
SNMP access Statement - There must be an SNMP access statement SNMP access Statement - There must be an SNMP access statement which
which provides the semantics known from SMIv2. provides the semantics known from SMIv2.
Implicit Entry Definitions - Is it ok to have table row nodes Implicit Entry Definitions - Is it ok to have table row nodes
(Entries) implicitly defined (e.g., naming conventions)? (Entries) implicitly defined (e.g., naming conventions)?
Order of `object' arguments - The order of the arguments in the Order of `object' arguments - The order of the arguments in the
objects statement is not intuitive. objects statement is not intuitive.
`implements' keyword - The `implements' statement is confusing - `implements' keyword - The `implements' statement is confusing -
need a better keyword name. need a better keyword name.
Implicit OID Assignments considered harmful - Implicit OID Implicit OID Assignments considered harmful - Implicit OID
assignments are a potential source of problems. It might be assignments are a potential source of problems. It might be
better to explicitly assign OIDs. better to explicitly assign OIDs.
SNMP Mapping Identifiers - What's the scope of identifiers defined SNMP Mapping Identifiers - What's the scope of identifiers defined
by SNMP mapping? Do we need to import such identifiers in SNMP by SNMP mapping? Do we need to import such identifiers in SNMP
mapping modules? mapping modules?
`extends' vs. `expands' - These two keyword seem to be confusing? `extends' vs. `expands' - These two keyword seem to be confusing?
Any proposals? Any proposals?
Special Table Relationships - Dave Perkins noted that RMON2 has a Special Table Relationships - Dave Perkins noted that RMON2 has a
table relationship which is not covered by what we have. table relationship which is not covered by what we have.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 222 change blocks. 
497 lines changed or deleted 473 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/