Network Working Group F. Strauss Internet-Draft J. Schoenwaelder Expires: May 11, 2001 TU Braunschweig K. McCloghrie Cisco Systems, Inc. November 10, 2000 SMIng Mappings to SNMP draft-irtf-nmrg-sming-snmp-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 11, 2001. Abstract This memo presents an SMIng language extension that supports the mapping of SMIng definitions to their application in the SNMP framework. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Strauss, et. al. Expires May 11, 2001 [Page 1] Internet-Draft SMIng SNMP Mapping November 2000 Table of Contents 1. TODO . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Scalar and Columnar Objects' Instances . . . . . . . . . . 5 1.3 Kinds of Nodes . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Object Identifier Hierarchy . . . . . . . . . . . . . . . 7 2. The snmp Extension Statement . . . . . . . . . . . . . . . 9 2.1 The oid Statement . . . . . . . . . . . . . . . . . . . . 9 2.2 The node Statement . . . . . . . . . . . . . . . . . . . . 9 2.2.1 The node's oid Statement . . . . . . . . . . . . . . . . . 9 2.2.2 The node's represents Statement . . . . . . . . . . . . . 9 2.2.3 The node's status Statement . . . . . . . . . . . . . . . 9 2.2.4 The node's description Statement . . . . . . . . . . . . . 10 2.2.5 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 10 2.3 The scalars Statement . . . . . . . . . . . . . . . . . . 10 2.3.1 The scalars' oid Statement . . . . . . . . . . . . . . . . 10 2.3.2 The scalars' implements Statement . . . . . . . . . . . . 11 2.3.2.1 The implements' object Statement . . . . . . . . . . . . . 11 2.3.3 The scalars' status Statement . . . . . . . . . . . . . . 11 2.3.4 The scalars' description Statement . . . . . . . . . . . . 11 2.3.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . 12 2.4 The table Statement . . . . . . . . . . . . . . . . . . . 12 2.4.1 The table's oid Statement . . . . . . . . . . . . . . . . 12 2.4.2 Table Indexing Statements . . . . . . . . . . . . . . . . 12 2.4.2.1 The table's index Statement for Table Indexing . . . . . . 12 2.4.2.2 The table's augments Statement for Table Indexing . . . . 13 2.4.2.3 The table's extends Statement for Table Indexing . . . . . 13 2.4.2.4 The table's reorders Statement for Table Indexing . . . . 13 2.4.2.5 The table's expands Statement for Table Indexing . . . . . 14 2.4.3 The table's create Statement . . . . . . . . . . . . . . . 14 2.4.4 The table's implements Statement . . . . . . . . . . . . . 14 2.4.4.1 The implements' object Statement . . . . . . . . . . . . . 14 2.4.5 The table's status Statement . . . . . . . . . . . . . . . 15 2.4.6 The table's description Statement . . . . . . . . . . . . 15 2.4.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . 16 2.5 The notification Statement . . . . . . . . . . . . . . . . 16 2.5.1 The notification's oid Statement . . . . . . . . . . . . . 16 2.5.2 The notification's signals Statement . . . . . . . . . . . 16 2.5.2.1 The signals' object Statement . . . . . . . . . . . . . . 16 2.5.3 The notification's status Statement . . . . . . . . . . . 17 2.5.4 The notification's description Statement . . . . . . . . . 17 2.5.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . 17 2.6 The group Statement . . . . . . . . . . . . . . . . . . . 17 2.6.1 The group's oid Statement . . . . . . . . . . . . . . . . 18 2.6.2 The group's members Statement . . . . . . . . . . . . . . 18 2.6.3 The group's status Statement . . . . . . . . . . . . . . . 18 2.6.4 The group's description Statement . . . . . . . . . . . . 18 2.6.5 The group's reference Statement . . . . . . . . . . . . . 18 Strauss, et. al. Expires May 11, 2001 [Page 2] Internet-Draft SMIng SNMP Mapping November 2000 2.6.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 18 2.7 The compliance Statement . . . . . . . . . . . . . . . . . 19 2.7.1 The compliance's oid Statement . . . . . . . . . . . . . . 19 2.7.2 The compliance's status Statement . . . . . . . . . . . . 19 2.7.3 The compliance's description Statement . . . . . . . . . . 19 2.7.4 The compliance's reference Statement . . . . . . . . . . . 20 2.7.5 The compliance's mandatory Statement . . . . . . . . . . . 20 2.7.6 The compliance's optional Statement . . . . . . . . . . . 20 2.7.6.1 The optional's description Statement . . . . . . . . . . . 20 2.7.7 The compliance's refine Statement . . . . . . . . . . . . 21 2.7.7.1 The refine's type Statement . . . . . . . . . . . . . . . 21 2.7.7.2 The refine's writetype Statement . . . . . . . . . . . . . 21 2.7.7.3 The refine's access Statement . . . . . . . . . . . . . . 21 2.7.7.4 The refine's description Statement . . . . . . . . . . . . 22 2.7.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . 22 3. Module Conversions . . . . . . . . . . . . . . . . . . . . 23 3.1 Converting SMIv2 to SMIng . . . . . . . . . . . . . . . . 23 3.2 Converting SMIng to SMIv2 . . . . . . . . . . . . . . . . 23 3.3 SMIv1 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4. IRTF-NMRG-SMING-SNMP-MAPPING . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . 25 References . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 27 A. The SNMP mapping ABNF grammar . . . . . . . . . . . . . . 28 Strauss, et. al. Expires May 11, 2001 [Page 3] Internet-Draft SMIng SNMP Mapping November 2000 1. TODO 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3]. 1.2 Scalar and Columnar Objects' Instances Instances of managed objects are identified by appending an instance-identifier to the object's object identifier. Scalar objects and columnar objects use different ways to construct the instance-identifier. Scalar objects have zero or one object instance. If it exists, it is identified by appending a single `0' sub-identifier to the object identifier of the scalar object. Within tables, different instances of the same columnar object are identified by appending a sequence of one or more sub-identifiers to the object identifier of the columnar object which consists of the values of object instances that unambiguously distinguish a table row. These indexing objects can be columnar objects of the same and/or another table, but MUST NOT be scalar objects. Multiple applications of the same object in a single table indexing specification are strongly discouraged. The base types of the indexing objects indicate how to form the instance-identifier: o integer-valued or enumeration-valued: a single sub-identifier taking the integer value (this works only for non-negative integers and integers of a size of up to 32 bits), o string-valued, fixed-length strings (or variable-length with compact encoding): `n' sub-identifiers, where `n' is the length of the string (each octet of the string is encoded in a separate sub-identifier), o string-valued, variable-length strings or bits-valued: `n+1' sub-identifiers, where `n' is the length of the string or bits encoding (the first sub-identifier is `n' itself, following this, each octet of the string or bits is encoded in a separate sub-identifier), o object identifier-valued (with compact encoding): `n' sub-identifiers, where `n' is the number of sub-identifiers in the value (each sub-identifier of the value is copied into a Strauss, et. al. Expires May 11, 2001 [Page 4] Internet-Draft SMIng SNMP Mapping November 2000 separate sub-identifier), o object identifier-valued: `n+1' sub-identifiers, where `n' is the number of sub-identifiers in the value (the first sub-identifier is `n' itself, following this, each sub-identifier in the value is copied), Note that compact encoding can only be applied to an object having a variable-length syntax (e.g., variable-length strings, bits objects or object identifier-valued objects). Further, compact encoding can only be associated with the last object in a list of indexing objects. Finally, compact encoding MUST NOT be used on a variable-length string object if that string might have a value of zero-length. Instances identified by use of integer-valued or enumeration-valued objects are RECOMMENDED to be numbered starting from one (i.e., not from zero). Integer objects that allow negative values, Unsigned64 objects, Integer64 objects and floating point objects MUST NOT be used for table indexing. Objects which are both specified for indexing in a row and also columnar objects of the same row are termed auxiliary objects. Auxiliary objects SHOULD be non-accessible, except in the following circumstances: o within a MIB module originally written to conform to SMIv1, or o a row must contain at least one columnar object which is not an auxiliary object. In the event that all of a row's columnar objects are also specified to be indexing objects then one of them MUST be accessible. (Note that this situation does not arise for a row allowing create access, since such a row will have a status column which will not be an auxiliary object.) 1.3 Kinds of Nodes Each node in the object identifier tree may be of a single kind which may represent management information or not: o simple nodes, that do not represent management information, but may be used for grouping nodes in a subtree, o nodes representing the identity of a module to allow references to a module in other objects of type `ObjectIdentifier', o scalar objects, which have zero or one object instance and no child nodes. See Section 1.2 for scalar objects' instances, Strauss, et. al. Expires May 11, 2001 [Page 5] Internet-Draft SMIng SNMP Mapping November 2000 o tables, which represent the root node of a collection of information structured in table rows. A table node SHOULD have no more child nodes than the single row node of this table, o rows, which belong to a table (that is, the table's full object identifier is a prefix of the row's object identifier) and represent a sequence of one or more columnar objects. Those columnar objects MUST be the only child nodes of a table row. A row's object identifier MUST be constructed by appending a `1' sub-identifier to the table's object identifier, o columnar objects, which belong to a row (that is, the row's full object identifier is a prefix of the columnar objects' object identifier) and have zero or more object instances and no child nodes. Each columnar object's object identifier MUST be constructed by appending a single sub-identifier to the row's object identifier. See Section 1.2 for columnar objects' instances, o notifications, which represent information that is sent by agents within unsolicited transmissions. A notification's object identifier SHOULD not have any child node, o groups of objects and notifications, which may be used for compliance statements or other purposes, o compliance statements which define requirements for MIB module implementations, o other nodes, that may be used to identify arbitrary information. 1.4 Object Identifier Hierarchy The layers of the object identifier tree near the root are well defined and organized by standardization bodies. The first level next to the root has three nodes: 0: ccitt 1: iso 2: joint-iso-ccitt Note that the renaming of the Commite Consultatif International de Telegraphique et Telephonique (CCITT) to International Telecommunications Union (ITU) had no consequence on the names used in the object identifier tree. The root of the subtree administered by the Internet Assigned Strauss, et. al. Expires May 11, 2001 [Page 6] Internet-Draft SMIng SNMP Mapping November 2000 Numbers Authority (IANA) for the Internet is `1.3.6.1' which is assigned with the identifier `internet'. That is, the Internet subtree of object identifiers starts with the prefix `1.3.6.1.'. Several branches underneath this subtree are used for network management: The `mgmt' (internet.2) subtree is used to identify "standard" information. The `experimental' (internet.3) subtree is used to identify information being designed by working groups of the IETF or IRTF. If a module produced by a working group becomes a "standard" module then at the very beginning of its entry onto the Internet standards track, the information is moved under the mgmt subtree. The `private' (internet.4) subtree is used to identify information defined unilaterally. The `enterprises' (private.1) subtree beneath private is used, among other things, to permit providers of networking subsystems to register models of their products. These and some other nodes are defined in the SMIng standard module IRTF-NMRG-SMING[2]. Strauss, et. al. Expires May 11, 2001 [Page 7] Internet-Draft SMIng SNMP Mapping November 2000 2. The snmp Extension Statement The `snmp' statement is the main statement of the SNMP mapping specification. It gets two arguments: a lower-case identifier that specifies a node that represents the module's identity, and a statement block that contains all details of the SNMP mapping. All information of an SNMP mapping are mapped to an SNMP conformant module of the same name as the containing SMIng module. A single SMIng module must not contain more than one `snmp' statement. 2.1 The oid Statement The snmp's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this module's identity node. 2.2 The node Statement The `node' statement is used to name and describe a node in the object identifier tree, without associating any class or attribute information with this node. This may be useful to group definitions in a subtree of related management information, or to uniquely define an SMIng `identity' to be referenced in attributes of type Pointer. The `node' statement gets two arguments: a lower-case node identifier and a statement block that holds detailed node information in an obligatory order. See the `nodeStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `node' statement. 2.2.1 The node's oid Statement The node's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this node. 2.2.2 The node's represents Statement The node's `represents' statement, which need not be present, makes this node represent an SMIng identity, so that objects of type Pointer can reference that identity. The statement gets one argument which specifies the identity name. 2.2.3 The node's status Statement The node's `status' statement, which need not be present, gets one argument which is used to specify whether this node definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is Strauss, et. al. Expires May 11, 2001 [Page 8] Internet-Draft SMIng SNMP Mapping November 2000 obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. If the `status' statement is omitted, the status value `current' is implied. 2.2.4 The node's description Statement The node's `description' statement, which need not be present, gets one argument which is used to specify a high-level textual description of this node. It is RECOMMENDED to include all semantics and purposes of this node. 2.2.5 Usage Examples node iso { oid 1; }; node org { oid iso.3; }; node dod { oid org.6; }; node internet { oid dod.1; }; node zeroDotZero { oid 0.0; represents Null; description "A value used for null identifiers."; }; 2.3 The scalars Statement 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 common parent node. The `scalars' statement gets two arguments: a lower-case scalar group identifier and a statement block that holds detailed mapping information of this scalar group in an obligatory order. See the `scalarsStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `scalars' statement. 2.3.1 The scalars' oid Statement The scalars' `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to the common parent node of this scalar group. Strauss, et. al. Expires May 11, 2001 [Page 9] Internet-Draft SMIng SNMP Mapping November 2000 2.3.2 The scalars' implements Statement The scalars' `implements' statement, which must be present at least once, makes this scalar group contain scalar objects that are defined by a given class. It gets two arguments: the class being implemented and a statement block that holds detailed information on the attributes of that class being implemented in an obligatory order. 2.3.2.1 The implements' object Statement The `object' statement, which must be present at least once, makes a 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 class attribute being implemented. The object identifier of this scalar object is implicitly specified by concatenating the scalar group's object identifier and the position of the object, starting at 1. [XXX optional explicit OID specification.] 2.3.3 The scalars' status Statement The scalars' `status' statement, which need not be present, gets one argument which is used to specify whether this scalar group definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. Scalar groups SHOULD NOT be defined as `current' if one or more of their classes are `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if one or more of their classes are `obsolete'. Nevertheless, subsequent revisions of used class definition cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module. If the `status' statement is omitted the status value `current' is implied. 2.3.4 The scalars' description Statement The scalars' `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this scalar group. It is RECOMMENDED to include all semantic definitions necessary for the implementation of this scalar group. Strauss, et. al. Expires May 11, 2001 [Page 10] Internet-Draft SMIng SNMP Mapping November 2000 2.3.5 Usage Example scalars ip { oid mib-2.4; implements Ip { object ipForwarding forwarding; object ipDefaultTTL defaultTTL; // ... } description "This scalar group implements the Ip class."; }; 2.4 The table Statement The `table' statement is used to define the mapping of one or more classes to a single SNMP table of columnar managed objects. The `table' statement gets two arguments: a lower-case table identifier and a statement block that holds detailed mapping information of this table in an obligatory order. See the `tableStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `table' statement. 2.4.1 The table's oid Statement The table's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this table's node. 2.4.2 Table Indexing Statements SNMP table mappings offers five methods to supply table indexing information: ordinary tables, table augmentations, sparse table augmentations, table expansions, and reordered tables use different statements to denote their indexing information. Each table definition must contain exactly one of the following indexing statements. 2.4.2.1 The table's index Statement for Table Indexing The table's `index' statement, which is used to supply table indexing information of base tables, gets one argument that specifies a comma-separated list of objects, that are used for table indexing, enclosed in parenthesis. Under some circumstances, an optional `implied' keyword may be added in front of the list to indicate a compact encoding of the last object in the list. See Section 1.2 for details. Strauss, et. al. Expires May 11, 2001 [Page 11] Internet-Draft SMIng SNMP Mapping November 2000 2.4.2.2 The table's augments Statement for Table Indexing The table's `augments' statement, which is used to supply table indexing information of tables that augment a base table, gets one argument that specifies the identifier of the table [XXX do we need the row?] to be augmented. Note that a table augmentation cannot itself be augmented. Anyhow, a base table may be augmented by multiple table augmentations. A table augmentation makes instances of subordinate columnar objects identified according to the index specification of the base table corresponding to the table named in the `augments' statement. Further, instances of subordinate columnar objects of a table augmentation exist according to the same semantics as instances of subordinate columnar objects of the base table being augmented. As such, note that creation of a base table row implies the correspondent creation of any table row augmentations. Table augmentations MUST NOT be used in table row creation and deletion operations. 2.4.2.3 The table's extends Statement for Table Indexing The table's `extends' statement, which is used to supply table indexing information of tables that sparsely augment a base table, gets one argument that specifies the identifier of the table to be sparsely augmented. Note that a sparse table augmentation cannot itself be augmented. Anyhow, a base table may be augmented by multiple table augmentations, sparsely or not. A sparse table augmentation makes instances of subordinate columnar objects identified, if present, according to the index specification of the base table corresponding to the table named in the `extends' statement. Further, instances of subordinate columnar objects of a sparse table augmentation exist according to the semantics as instances of subordinate columnar objects of the base table and the (non-formal) rules that confine the sparse relationship. As such, 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 creation. However, if a base table row gets deleted, any dependent sparse table row augmentations get also deleted implicitly. 2.4.2.4 The table's reorders Statement for Table Indexing The table's `reorders' statement is used to supply table indexing information of tables, that contain exactly the same index objects of a base table, except in another order. It gets at least two arguments. The first one specifies the identifier of the base table. The second one specifies a comma-separated list of exactly those object identifiers of the base table's `index' statement, but in the Strauss, et. al. Expires May 11, 2001 [Page 12] Internet-Draft SMIng SNMP Mapping November 2000 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 reordered tables. Under some circumstances, an optional `implied' keyword may be added in front of the list to indicate a compact encoding of the last object in the list. See Section 1.2 for details. Instances of subordinate columnar objects of a reordered table exist according to the same semantics as instances of subordinate columnar objects of the base table. As such, note that creation of a base table row implies the correspondent creation of any related reordered table row. Reordered tables MUST NOT be used in table row creation and deletion operations. 2.4.2.5 The table's expands Statement for Table Indexing The table's `expands' statement is used to supply table indexing information of table expansions. Table expansions use exactly the same index objects of another table together with additional indexing objects. Thus, the `expands' statement gets at least two arguments. The first one specifies the identifier of the related table. The second one specifies a comma-separated list of the additional object identifiers used for indexing. Note that an expanded table may itself be expanded, and related tables may be used for multiple table expansions. Under some circumstances, an optional `implied' keyword may be added in front of the list to indicate a compact encoding of the last object in the list. See Section 1.2 for details. 2.4.3 The table's create Statement The table's `create' statement, which need not be present, gets no argument. If the `create' statement is present, table row creation (and deletion) is possible. 2.4.4 The table's implements Statement The table's `implements' statement, which must be present at least once, makes this table contain columnar objects that are defined by a given class. It gets two arguments: the class being implemented and a statement block that holds detailed information on the attributes of that class being implemented in an obligatory order. 2.4.4.1 The implements' object Statement The `object' statement, which must be present at least once, makes a single attribute of the class being contained as a columnar object Strauss, et. al. Expires May 11, 2001 [Page 13] Internet-Draft SMIng SNMP Mapping November 2000 in the table. It gets two arguments: the columnar object name and the class attribute being implemented. The object identifier of this columnar object is implicitly specified by concatenating the table's object identifier a single sub-identifier of the value 1 (in SMIv2 this represents the table entry definition) [XXX optional explicit entry oid and name specification] and the position of the object, starting at 1. [XXX optional explicit OID specification.] 2.4.5 The table's status Statement The table's `status' statement, which need not be present, gets one argument which is used to specify whether this table definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. Tables SHOULD NOT be defined as `current' if one or more of their classes are `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if one or more of their classes are `obsolete'. Nevertheless, subsequent revisions of used class definition cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module. If the `status' statement is omitted the status value `current' is implied. 2.4.6 The table's description Statement The table's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this table. It is RECOMMENDED to include all semantic definitions necessary for the implementation of this scalar group. Strauss, et. al. Expires May 11, 2001 [Page 14] Internet-Draft SMIng SNMP Mapping November 2000 2.4.7 Usage Example table ifTable { oid interfaces.2; index (ifIndex); implements Interface { object ifIndex index; object ifDescr description; // ... } description "This table implements the Interface class."; }; 2.5 The notification Statement The `notification' statement is used to map events of classes to SNMP notifications. The statement gets two arguments: a lower-case notification identifier and a statement block that holds detailed notification information in an obligatory order. See the `notificationStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `notification' statement. 2.5.1 The notification's oid Statement The notification's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this notification. 2.5.2 The notification's signals Statement The notification's `signals' statement, which must be present, denotes the event that is signaled by this notification. The statement gets two argument: the event to be signaled (in the qualifed form `Class.event') and a statement block that holds detailed information on the objects transmitted with this notification in an obligatory order. 2.5.2.1 The signals' object Statement The signals' `object' statement, which can be present zero, one or multiple times, makes a single instance of a class attribute be contained in this notification. It gets one argument: the specific class attribute. The namespace of attributes not specified by qualified names is the namespace of the event's class specified in the `signals' statement. Strauss, et. al. Expires May 11, 2001 [Page 15] Internet-Draft SMIng SNMP Mapping November 2000 2.5.3 The notification's status Statement The notification's `status' statement, which need not be present, gets one argument which is used to specify whether this notification definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. If the `status' statement is omitted, the status value `current' is implied. 2.5.4 The notification's description Statement The notification's `description' statement, which need not be present, gets one argument which is used to specify a high-level textual description of this notification. It is RECOMMENDED to include all semantics and purposes of this notification. 2.5.5 Usage Example notification linkDown { oid snmpTraps.3; signals Interface.linkDown { object ifIndex; object ifAdminStatus; object ifOperStatus; }; description "This notification signals the linkDown event of the Interface class. [XXX this notification does not use the event definition at all. Is this what we want?!]"; }; 2.6 The group Statement The `group' statement is used to define a group of arbitrary nodes in the object identifier tree. It gets two arguments: a lower-case group identifier and a statement block that holds detailed group information in an obligatory order. Note that the primary application of groups are compliance statements, although they might be referred in other formal or Strauss, et. al. Expires May 11, 2001 [Page 16] Internet-Draft SMIng SNMP Mapping November 2000 informal documents. See the `groupStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `group' statement. 2.6.1 The group's oid Statement The group's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this group. 2.6.2 The group's members Statement The group's `members' statement, which must be present, gets one argument which specifies the list of nodes by their identifiers to be contained in this group. The list of nodes has to be comma-separated and enclosed in parenthesis. 2.6.3 The group's status Statement The group's `status' statement, which need not be present, gets one argument which is used to specify whether this group definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and the group should no longer be used. While the value `deprecated' also indicates an obsolete definition, it permits new/continued use of this group. If the `status' statement is omitted the status value `current' is implied. 2.6.4 The group's description Statement The group's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this group. It is RECOMMENDED to include any relation to other groups. 2.6.5 The group's reference Statement The group's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related groups, or some other document which provides additional information relevant to this group. 2.6.6 Usage Example The snmpGroup, originally defined in [15], may be described as Strauss, et. al. Expires May 11, 2001 [Page 17] Internet-Draft SMIng SNMP Mapping November 2000 follows: group snmpGroup { oid snmpMIBGroups.8; objects (snmpInPkts, snmpInBadVersions, snmpInASNParseErrs, snmpSilentDrops, snmpProxyDrops, snmpEnableAuthenTraps); description "A collection of objects providing basic instrumentation and control of an agent."; }; 2.7 The compliance Statement The `compliance' statement is used to define a set of compliance requirements, named a `compliance statement'. It gets two arguments: a lower-case compliance identifier and a statement block that holds detailed compliance information in an obligatory order. See the `complianceStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `compliance' statement. 2.7.1 The compliance's oid Statement The compliance's `oid' statement, which must be present, gets one argument which specifies the object identifier value that is assigned to this compliance statement. 2.7.2 The compliance's status Statement The compliance's `status' statement, which need not be present, gets one argument which is used to specify whether this compliance statement is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and no longer specifies a valid definition of conformance. While the value `deprecated' also indicates an obsolete definition, it permits new/continued use of the compliance specification. If the `status' statement is omitted the status value `current' is implied. 2.7.3 The compliance's description Statement The compliance's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this compliance statement. Strauss, et. al. Expires May 11, 2001 [Page 18] Internet-Draft SMIng SNMP Mapping November 2000 2.7.4 The compliance's reference Statement The compliance's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related compliance statements, or some other document which provides additional information relevant to this compliance statement. 2.7.5 The compliance's mandatory Statement The compliance's `mandatory' statement, which need not be present, gets one argument which is used to specify a comma-separated list of one or more groups (Section 2.6) of objects and/or notifications enclosed in parenthesis. These groups are unconditionally mandatory for implementation. If an agent claims compliance to a MIB module then it must implement each and every object and notification within each group listed the `mandatory' statement(s) of the compliance statement(s) of that module. 2.7.6 The compliance's optional Statement The compliance's `optional' statement, which need not be present, is repeatedly used to name each group which is conditionally mandatory for compliance to the module. It can also be used to name unconditionally optional groups. A group named in an `optional' statement MUST be absent from the correspondent `mandatory' statement. The `optional' statement gets two arguments: a lower-case group identifier and a statement block that holds detailed compliance information on that group. Conditionally mandatory groups include those which are mandatory only if a particular protocol is implemented, or only if another group is implemented. The `description' statement specifies the conditions under which the group is conditionally mandatory. A group which is named in neither a `mandatory' statement nor an `optional' statement, is unconditionally optional for compliance to the module. See the `optionalStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `optional' statement. 2.7.6.1 The optional's description Statement The optional's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the conditions under which this group is Strauss, et. al. Expires May 11, 2001 [Page 19] Internet-Draft SMIng SNMP Mapping November 2000 conditionally mandatory or unconditionally optional. 2.7.7 The compliance's refine Statement The compliance's `refine' statement, which need not be present, is repeatedly used to specify each object for which compliance has a refined requirement with respect to the module definition. The object must be present in one of the conformance groups named in the correspondent `mandatory' or `optional' statements. The `refine' statement gets two arguments: a lower-case identifier of a scalar or columnar object and a statement block that holds detailed refinement information on that object. See the `refineStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `refine' statement. 2.7.7.1 The refine's type Statement The refine's `type' statement, which need not be present, gets one argument that is used to provide a refined type for the correspondent object. Type restrictions may be applied by appending subtyping information according to the rules of the base type. See [1] for SMIng base types and their type restrictions. In case of enumeration or bitset types the order of named numbers is not significant. Note that if a `type' and a `writetype' statement are both present then this type only applies when instances of the correspondent object are read. 2.7.7.2 The refine's writetype Statement The refine's `writetype' statement, which need not be present, gets one argument that is used to provide a refined type for the correspondent object, only when instances of that object are written. Type restrictions may be applied by appending subtyping information according to the rules of the base type. See [1] for SMIng base types and their type restrictions. In case of enumeration or bitset types the order of named numbers is not significant. 2.7.7.3 The refine's access Statement The refine's `access' statement, which need not be present, gets one argument that is used to specify the minimal level of access that the correspondent object must implement in the sense of its original `access' statement. Hence, the refine's `access' statement MUST NOT specify a greater level of access than is specified in the correspondent object definition. Strauss, et. al. Expires May 11, 2001 [Page 20] Internet-Draft SMIng SNMP Mapping November 2000 An implementation is compliant if the level of access it provides is greater or equal to the minimal level in the refine's `access' statement and less or equal to the maximal level in the object's `access' statement. 2.7.7.4 The refine's description Statement The refine's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the refined compliance requirement. 2.7.8 Usage Example The compliance statement contained in the SNMPv2-MIB, converted to SMIng: compliance snmpBasicCompliance { oid snmpMIBCompliances.2; description "The compliance statement for SNMPv2 entities which implement the SNMPv2 MIB."; mandatory (snmpGroup, snmpSetGroup, systemGroup, snmpBasicNotificationsGroup); optional snmpCommunityGroup { description "This group is mandatory for SNMPv2 entities which support community-based authentication."; }; }; Strauss, et. al. Expires May 11, 2001 [Page 21] Internet-Draft SMIng SNMP Mapping November 2000 3. Module Conversions 3.1 Converting SMIv2 to SMIng 3.2 Converting SMIng to SMIv2 3.3 SMIv1 Strauss, et. al. Expires May 11, 2001 [Page 22] Internet-Draft SMIng SNMP Mapping November 2000 4. IRTF-NMRG-SMING-SNMP-MAPPING IRTF-NMRG-SMING-SNMP-MAPPING DEFINITIONS ::= BEGIN -- This document introduces some additional ASN.1 definitions for -- using the data types newly introduced by the SMIng with SNMPv1, -- SNMPv2c and SNMPv3. Values of the ASN.1 types defined below are BER -- encoded and wrapped in an Opaque when used with SNMPv1, SNMPv2c or -- SNMPv3. -- The following two definitions are consistent with the same SPPI -- definitions. Integer64 ::= [APPLICATION 7] IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) Unsigned64 [APPLICATION 8] IMPLICIT INTEGER (0..18446744073709551615) -- The following three definitions are new in order to support IEEE -- single, double and quadruple floating point values. The encoding of -- values follows the "IEEE Standard for Binary Floating-Point -- Arithmetic" as defined in ANSI/IEEE Standard 754-1985. Float32 [APPLICATION 9] IMPLICIT OCTET STRING (SIZE (4)) Float64 [APPLICATION 10] IMPLICIT OCTET STRING (SIZE (8)) Float128 [APPLICATION 11] IMPLICIT OCTET STRING (SIZE (16)) END Strauss, et. al. Expires May 11, 2001 [Page 23] Internet-Draft SMIng SNMP Mapping November 2000 5. Security Considerations [XXX] This document is a companion of [1] See also the security considerations of that document for further information. Strauss, et. al. Expires May 11, 2001 [Page 24] Internet-Draft SMIng SNMP Mapping November 2000 References [1] Strauss, F., "SMIng - A new Structure of Management Information", November 2000. [2] Strauss, F., "SMIng Core Modules", November 2000. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., Waldbusser, S., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., Waldbusser, S., "Textual Conventions for SMIv2", RFC 2579, STD 59, April 1999. [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., Waldbusser, S., "Conformance Statements for SMIv2", RFC 2580, STD 60, April 1999. [7] Rose, M., McCloghrie, K., "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, STD 16, May 1990. [8] Rose, M., McCloghrie, K., "Concise MIB Definitions", RFC 1212, STD 16, March 1991. [9] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [10] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [11] International Organization for Standardization, "Specification of Abstract Syntax Notation One (ASN.1)", International Standard 8824, December 1987. [12] Harrington, D., Presuhn, R., Wijnen, B., "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1999. [13] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985. [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Strauss, et. al. Expires May 11, 2001 [Page 25] Internet-Draft SMIng SNMP Mapping November 2000 [15] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1996. [16] Wijnen, B., Levi, D., "V2ToV1 - Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent", RFC 2089, January 1997. [17] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Authors' Addresses Frank Strauss TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3266 EMail: strauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/ Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3266 EMail: schoenw@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/ Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 EMail: kzm@cisco.com URI: http://www.cisco.com/ Strauss, et. al. Expires May 11, 2001 [Page 26] Internet-Draft SMIng SNMP Mapping November 2000 Appendix A. The SNMP mapping ABNF grammar The grammar of the SNMP mapping SMIng extension conforms to the Augmented Backus-Naur Form (ABNF)[10]. XXX One exception: For readability, keywords are represented as quoted strings, although ABNF would declare these strings to be case-insensitive. Anyhow, SMIng keyword are meant to be case-sensitive. ;; ;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF notation (RFC 2234). ;; ;; @(#) $Id: sming-snmp.abnf,v 1.2 2000/11/10 16:41:20 strauss Exp $ ;; ;; Copyright (C) The Internet Society (1999,2000). All Rights Reserved. ;; ;; ;; Statement rules. ;; snmpStatement = snmpKeyword sep lcIdentifier optsep "{" stmtsep oidStatement stmtsep *(nodeStatement stmtsep) *(scalarsStatement stmtsep) *(tableStatement stmtsep) *(notificationStatement stmtsep) *(groupStatement stmtsep) *(complianceStatement stmtsep) *1(statusStatement stmtsep) descriptionStatement stmtsep "}" optsep ";" nodeStatement = nodeKeyword sep lcIdentifier optsep "{" stmtsep oidStatement stmtsep *1(representsStatement stmtsep) *1(statusStatement stmtsep) *1(descriptionStatement stmtsep) "}" optsep ";" representsStatement = representsKeyword sep qucIdentifier optsep ";" scalarsStatement = scalarsKeyword sep lcIdentifier optsep "{" stmtsep oidStatement stmtsep 1*(implementsStatement stmtsep) *1(statusStatement stmtsep) Strauss, et. al. Expires May 11, 2001 [Page 27] Internet-Draft SMIng SNMP Mapping November 2000 descriptionStatement stmtsep "}" optsep ";" tableStatement = tableKeyword sep lcIdentifier optsep "{" stmtsep oidStatement stmtsep anyIndexStatement stmtsep *1(createStatement stmtsep) 1*(implementsStatement stmtsep) *1(statusStatement stmtsep) descriptionStatement stmtsep "}" optsep ";" implementsStatement = implementsKeyword sep qucIdentifier optsep "{" stmtsep 1*(implObjectStatement stmtsep) "}" optsep ";" implObjectStatement = objectKeyword sep lcIdentifier sep attrIdentifier optsep; notificationStatement = notificationKeyword sep lcIdentifier optsep "{" stmtsep oidStatement stmtsep signalsStatement stmtsep *1(statusStatement stmtsep) descriptionStatement stmtsep "}" optsep ";" signalsStatement = signalsKeyword sep qattrIdentifier optsep "{" stmtsep *(signalsObjectStatement) "}" optsep ";" signalsObjectStatement = objectKeyword sep qattrIdentifier optsep ";" groupStatement = groupKeyword sep lcIdentifier optsep "{" stmtsep oidStatement stmtsep membersStatement stmtsep *1(statusStatement stmtsep) descriptionStatement stmtsep "}" optsep ";" complianceStatement = complianceKeyword sep lcIdentifier optsep "{" stmtsep oidStatement stmtsep Strauss, et. al. Expires May 11, 2001 [Page 28] Internet-Draft SMIng SNMP Mapping November 2000 *1(statusStatement stmtsep) descriptionStatement stmtsep *1(mandatoryStatement stmtsep) *(optionalStatement stmtsep) *(refineStatement stmtsep) "}" optsep ";" anyIndexStatement = indexStatement / augmentsStatement / reordersStatement / extendsStatement / expandsStatement indexStatement = indexKeyword *1(sep impliedKeyword) optsep "(" optsep qlcIdentifierList optsep ")" optsep ";" augmentsStatement = augmentsKeyword sep qlcIdentifier optsep ";" reordersStatement = reordersKeyword sep qlcIdentifier *1(sep impliedKeyword) optsep "(" optsep qlcIdentifierList optsep ")" optsep ";" extendsStatement = extendsKeyword sep qlcIdentifier optsep ";" expandsStatement = expandsKeyword sep qlcIdentifier *1(sep impliedKeyword) optsep "(" optsep qlcIdentifierList optsep ")" optsep ";" createStatement = createKeyword optsep ";" membersStatement = membersKeyword optsep "(" optsep qlcIdentifierList optsep ")" optsep ";" mandatoryStatement = mandatoryKeyword optsep "(" optsep qlcIdentifierList optsep ")" optsep ";" optionalStatement = optionalKeyword sep qlcIdentifier optsep "{" descriptionStatement stmtsep "}" optsep ";" refineStatement = refineKeyword sep qlcIdentifier optsep "{" Strauss, et. al. Expires May 11, 2001 [Page 29] Internet-Draft SMIng SNMP Mapping November 2000 *1(typeStatement stmtsep) *1(writetypeStatement stmtsep) *1(accessStatement stmtsep) descriptionStatement stmtsep "}" optsep ";" typeStatement = typeKeyword sep (refinedBaseType / refinedType) optsep ";" writetypeStatement = writetypeKeyword sep (refinedBaseType / refinedType) optsep ";" oidStatement = oidKeyword sep objectIdentifier optsep ";" ;; ;; ;; objectIdentifier = (qlcIdentifier / subid) *127("." subid) subid = decimalNumber ;; ;; Statement keywords. ;; snmpKeyword = "snmp" nodeKeyword = "node" representsKeyword = "represents" scalarsKeyword = "scalars" tableKeyword = "table" implementsKeyword = "implements" objectKeyword = "object" notificationKeyword = "notification" signalsKeyword = "signals" oidKeyword = "oid" groupKeyword = "group" complianceKeyword = "compliance" impliedKeyword = "implied" indexKeyword = "index" augmentsKeyword = "augments" reordersKeyword = "reorders" extendsKeyword = "extends" expandsKeyword = "expands" createKeyword = "create" membersKeyword = "members" mandatoryKeyword = "mandatory" Strauss, et. al. Expires May 11, 2001 [Page 30] Internet-Draft SMIng SNMP Mapping November 2000 optionalKeyword = "optional" refineKeyword = "refine" writetypeKeyword = "writetype" ;; ;; EOF ;; Strauss, et. al. Expires May 11, 2001 [Page 31] Internet-Draft SMIng SNMP Mapping November 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Strauss, et. al. Expires May 11, 2001 [Page 32]