< draft-ietf-sming-01.txt   draft-ietf-sming-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 - Next Generation Structure of Management Information SMIng - Next Generation Structure of Management Information
draft-ietf-sming-01 draft-ietf-sming-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 object-oriented data definition language for This memo presents an object-oriented data definition language for
the specification of various kinds of management information. It is the specification of various kinds of management information. It is
independent of management protocols and applications. Protocol independent of management protocols and applications. Protocol
mappings are defined as extensions to this language in separate mappings are defined as extensions to this language in separate
memos. The language builds on experiences gained with the SMIv2 and memos. The language builds on experiences gained with the SMIv2 and
its derivate SPPI. It is expected that the language presented in its derivate SPPI. It is expected that the language presented in
this memo along with its protocol mappings will replace the SMIv2 this memo along with its protocol mappings will replace the SMIv2 and
and the SPPI in the long term. the SPPI in the long term.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. SMIng Data Modelling . . . . . . . . . . . . . . . . . . . . 6 2. SMIng Data Modelling . . . . . . . . . . . . . . . . . . . . 5
2.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Base Types and Derived Types . . . . . . . . . . . . . . . . 9 3. Base Types and Derived Types . . . . . . . . . . . . . . . . 7
3.1 OctetString . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 OctetString . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Integer32 . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Object Identifier . . . . . . . . . . . . . . . . . . . . . 9
3.4 Integer64 . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Integer32 . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5 Integer64 . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6 Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.7 Float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.7 Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.8 Float64 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.8 Float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.9 Float128 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.9 Float64 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.10 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . 17 3.10 Float128 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.11 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . 16
3.12 Display Formats . . . . . . . . . . . . . . . . . . . . . . 18 3.12 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. The SMIng File Structure . . . . . . . . . . . . . . . . . . 21 3.13 Display Formats . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4. The SMIng File Structure . . . . . . . . . . . . . . . . . . 20
4.2 Statements and Arguments . . . . . . . . . . . . . . . . . . 21 4.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. The module Statement . . . . . . . . . . . . . . . . . . . . 22 4.2 Statements and Arguments . . . . . . . . . . . . . . . . . . 20
5.1 The module's import Statement . . . . . . . . . . . . . . . 22 5. The module Statement . . . . . . . . . . . . . . . . . . . . 20
5.2 The module's organization Statement . . . . . . . . . . . . 23 5.1 The module's import Statement . . . . . . . . . . . . . . . 21
5.3 The module's contact Statement . . . . . . . . . . . . . . . 23 5.2 The module's organization Statement . . . . . . . . . . . . 22
5.4 The module's description Statement . . . . . . . . . . . . . 23 5.3 The module's contact Statement . . . . . . . . . . . . . . . 22
5.5 The module's reference Statement . . . . . . . . . . . . . . 23 5.4 The module's description Statement . . . . . . . . . . . . . 22
5.6 The module's revision Statement . . . . . . . . . . . . . . 23 5.5 The module's reference Statement . . . . . . . . . . . . . . 22
5.6.1 The revision's date Statement . . . . . . . . . . . . . . . 23 5.6 The module's revision Statement . . . . . . . . . . . . . . 22
5.6.2 The revision's description Statement . . . . . . . . . . . . 24 5.6.1 The revision's date Statement . . . . . . . . . . . . . . . 22
5.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 24 5.6.2 The revision's description Statement . . . . . . . . . . . . 23
6. The extension Statement . . . . . . . . . . . . . . . . . . 26 5.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 23
6.1 The extension's status Statement . . . . . . . . . . . . . . 26 6. The extension Statement . . . . . . . . . . . . . . . . . . 24
6.2 The extension's description Statement . . . . . . . . . . . 26 6.1 The extension's status Statement . . . . . . . . . . . . . . 24
6.3 The extension's reference Statement . . . . . . . . . . . . 26 6.2 The extension's description Statement . . . . . . . . . . . 24
6.4 The extension's abnf Statement . . . . . . . . . . . . . . . 27 6.3 The extension's reference Statement . . . . . . . . . . . . 24
6.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 27 6.4 The extension's abnf Statement . . . . . . . . . . . . . . . 25
7. The typedef Statement . . . . . . . . . . . . . . . . . . . 28 6.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 25
7.1 The typedef's type Statement . . . . . . . . . . . . . . . . 28 7. The typedef Statement . . . . . . . . . . . . . . . . . . . 25
7.2 The typedef's default Statement . . . . . . . . . . . . . . 28 7.1 The typedef's type Statement . . . . . . . . . . . . . . . . 25
7.3 The typedef's format Statement . . . . . . . . . . . . . . . 28 7.2 The typedef's default Statement . . . . . . . . . . . . . . 26
7.4 The typedef's units Statement . . . . . . . . . . . . . . . 29 7.3 The typedef's format Statement . . . . . . . . . . . . . . . 26
7.5 The typedef's status Statement . . . . . . . . . . . . . . . 29 7.4 The typedef's units Statement . . . . . . . . . . . . . . . 26
7.6 The typedef's description Statement . . . . . . . . . . . . 29 7.5 The typedef's status Statement . . . . . . . . . . . . . . . 27
7.7 The typedef's reference Statement . . . . . . . . . . . . . 30 7.6 The typedef's description Statement . . . . . . . . . . . . 27
7.8 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 30 7.7 The typedef's reference Statement . . . . . . . . . . . . . 27
8. The identity Statement . . . . . . . . . . . . . . . . . . . 32 7.8 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 27
8.1 The identity's status Statement . . . . . . . . . . . . . . 32 8. The identity Statement . . . . . . . . . . . . . . . . . . . 28
8.2 The identity' description Statement . . . . . . . . . . . . 32 8.1 The identity's status Statement . . . . . . . . . . . . . . 29
8.3 The identity's reference Statement . . . . . . . . . . . . . 33 8.2 The identity' description Statement . . . . . . . . . . . . 29
8.4 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 33 8.3 The identity's reference Statement . . . . . . . . . . . . . 29
9. The class Statement . . . . . . . . . . . . . . . . . . . . 34 8.4 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 30
9.1 The class' attribute Statement . . . . . . . . . . . . . . . 34 9. The class Statement . . . . . . . . . . . . . . . . . . . . 30
9.1.1 The attribute's access Statement . . . . . . . . . . . . . . 34 9.1 The class' attribute Statement . . . . . . . . . . . . . . . 30
9.1.2 The attribute's default Statement . . . . . . . . . . . . . 35 9.1.1 The attribute's access Statement . . . . . . . . . . . . . . 31
9.1.3 The attribute's format Statement . . . . . . . . . . . . . . 35 9.1.2 The attribute's default Statement . . . . . . . . . . . . . 31
9.1.4 The attribute's units Statement . . . . . . . . . . . . . . 35 9.1.3 The attribute's format Statement . . . . . . . . . . . . . . 31
9.1.5 The attribute's status Statement . . . . . . . . . . . . . . 36 9.1.4 The attribute's units Statement . . . . . . . . . . . . . . 32
9.1.6 The attribute's description Statement . . . . . . . . . . . 36 9.1.5 The attribute's status Statement . . . . . . . . . . . . . . 32
9.1.7 The attribute's reference Statement . . . . . . . . . . . . 36 9.1.6 The attribute's description Statement . . . . . . . . . . . 32
9.2 The class' unique Statement . . . . . . . . . . . . . . . . 36 9.1.7 The attribute's reference Statement . . . . . . . . . . . . 33
9.3 The class' event Statement . . . . . . . . . . . . . . . . . 37 9.2 The class' unique Statement . . . . . . . . . . . . . . . . 33
9.3.1 The event's status Statement . . . . . . . . . . . . . . . . 37 9.3 The class' event Statement . . . . . . . . . . . . . . . . . 33
9.3.2 The event's description Statement . . . . . . . . . . . . . 37 9.3.1 The event's status Statement . . . . . . . . . . . . . . . . 33
9.3.3 The event's reference Statement . . . . . . . . . . . . . . 38 9.3.2 The event's description Statement . . . . . . . . . . . . . 34
9.4 The class' status Statement . . . . . . . . . . . . . . . . 38 9.3.3 The event's reference Statement . . . . . . . . . . . . . . 34
9.5 The class' description Statement . . . . . . . . . . . . . . 38 9.4 The class' status Statement . . . . . . . . . . . . . . . . 34
9.6 The class's reference Statement . . . . . . . . . . . . . . 38 9.5 The class' description Statement . . . . . . . . . . . . . . 34
9.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 39 9.6 The class's reference Statement . . . . . . . . . . . . . . 35
10. Extending a Module . . . . . . . . . . . . . . . . . . . . . 40 9.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 35
11. SMIng Language Extensibility . . . . . . . . . . . . . . . . 42 10. Extending a Module . . . . . . . . . . . . . . . . . . . . . 36
12. Security Considerations . . . . . . . . . . . . . . . . . . 44 11. SMIng Language Extensibility . . . . . . . . . . . . . . . . 37
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 12. Security Considerations . . . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 47 References . . . . . . . . . . . . . . . . . . . . . . . . . 40
A. SMIng ABNF Grammar . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41
B. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 58 A. SMIng ABNF Grammar . . . . . . . . . . . . . . . . . . . . . 41
B. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 51
Full Copyright Statement . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
In traditional management systems management information is viewed In traditional management systems management information is viewed as
as a collection of managed objects, residing in a virtual a collection of managed objects, residing in a virtual information
information store, termed the Management Information Base (MIB). store, termed the Management Information Base (MIB). Collections of
Collections of related objects are defined in MIB modules. These related objects are defined in MIB modules. These modules are
modules are written conforming to a specification language, the written conforming to a specification language, the Structure of
Structure of Management Information (SMI). There are different Management Information (SMI). There are different versions of the
versions of the SMI. The SMI version 1 (SMIv1) is defined in [9], SMI. The SMI version 1 (SMIv1) is defined in [9], [10], [11] and the
[10], [11] and the SMI version 2 (SMIv2) in [5], [6], [7]. Both are SMI version 2 (SMIv2) in [5], [6], [7]. Both are based on adapted
based on adapted subsets of OSI's Abstract Syntax Notation One, subsets of OSI's Abstract Syntax Notation One, ASN.1 [13].
ASN.1 [13].
In a similar fashion policy provisioning information is viewed as a In a similar fashion policy provisioning information is viewed as a
collection of Provisioning Classes (PRCs) and Provisioning Instances collection of Provisioning Classes (PRCs) and Provisioning Instances
(PRIs) residing in a virtual information store, termed the Policy (PRIs) residing in a virtual information store, termed the Policy
Information Base (PIB). Collections of related Provisioning Classes Information Base (PIB). Collections of related Provisioning Classes
are defined in PIB modules. PIB modules are written using the are defined in PIB modules. PIB modules are written using the
Structure of Policy Provisioning Information (SPPI) [8] which is an Structure of Policy Provisioning Information (SPPI) [8] which is an
adapted subset of SMIv2. adapted subset of SMIv2.
The SMIv1 and the SMIv2 are bound to the Simple Network Management The SMIv1 and the SMIv2 are bound to the Simple Network Management
Protocol (SNMP) while the the SPPI is bound to the Common Open Protocol (SNMP) while the the SPPI is bound to the Common Open Policy
Policy Service Provisioning (COPS-PR) protocol. Even though the Service Provisioning (COPS-PR) protocol. Even though the languages
languages have common rules, it is hard to use common data have common rules, it is hard to use common data definitions with
definitions with both protocols. It is the purpose of this document both protocols. It is the purpose of this document to define a
to define a common object-oriented data definition language, named common object-oriented data definition language, named SMIng, that
SMIng, that allows to formally specify data models independent of allows to formally specify data models independent of specific
specific protocols and applications. Companion documents contain protocols and applications. Companion documents contain
o core modules that supply common SMIng definitions [1][2], o core modules that supply common SMIng definitions [1][2],
o a SMIng language extension to define SNMP specific mappings of o a SMIng language extension to define SNMP specific mappings of
SMIng definitions in way compatible to SMIv2 MIBs [3], and SMIng definitions in way compatible to SMIv2 MIBs [3], and
o a SMIng language extension to define COPS-PR specific mappings of o a SMIng language extension to define COPS-PR specific mappings of
SMIng definition in a way compatible to SPPI PIBs. SMIng definition in a way compatible to SPPI PIBs.
Section 2 gives an overview of the basic concepts of data modelling Section 2 gives an overview of the basic concepts of data modelling
using SMIng while the subsequent sections present the concepts of using SMIng while the subsequent sections present the concepts of the
the SMIng language in detail: the base types, the SMIng file SMIng language in detail: the base types, the SMIng file structure,
structure, and all SMIng core statements. and all SMIng core statements.
The remainder of the document describes extensibility features of The remainder of the document describes extensibility features of the
the language and rules to follow when changes are applied to a language and rules to follow when changes are applied to a module.
module. Appendix A contains the grammar of SMIng in ABNF [12] Appendix A contains the grammar of SMIng in ABNF [12] notation.
notation.
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 [4]. document are to be interpreted as described in [4].
2. SMIng Data Modelling 2. SMIng Data Modelling
SMIng is a language designed to specify management information in a SMIng is a language designed to specify management information in a
structured way readable to computer programs, e.g. MIB compilers, as structured way readable to computer programs, e.g. MIB compilers, as
well as to human readers. well as to human readers.
Management information is modeled in classes in an object-oriented Management information is modeled in classes in an object-oriented
manner. Classes can be defined from scratch or by inheritance from a manner. Classes can be defined from scratch or by inheritance from a
parent class. Multiple inheritence is not possible. The concept of parent class. Multiple inheritence is not possible. The concept of
classes is described in Section 9. classes is described in Section 9.
Each class has a number of attributes. Each attribute represents an Each class has a number of attributes. Each attribute represents an
atomic piece of information of a base type, a sub-type of a base atomic piece of information of a base type, a sub-type of a base
type, or another class. The concept of attributes is described in type, or another class. The concept of attributes is described in
Section 9.1. Section 9.1.
The base types of SMIng include signed and unsigned integers, octet The base types of SMIng include signed and unsigned integers, octet
strings, enumeration types, bitset types, and pointers. Pointers are strings, enumeration types, bitset types, and pointers. Pointers are
references to class instances, attributes of class instances, or references to class instances, attributes of class instances, or
arbitrary identities. The SMIng type system is described in Section arbitrary identities. The SMIng type system is described in Section
3. 3.
Related class and type definitions are defined in modules. A module Related class and type definitions are defined in modules. A module
may refer to definitions from other modules by importing identifiers may refer to definitions from other modules by importing identifiers
from those modules. Each module may serve one or multiple purposes: from those modules. Each module may serve one or multiple purposes:
o the definition of management classes, o the definition of management classes,
o the definition of events, o the definition of events,
o the definition of derived types, o the definition of derived types,
o the definition of arbitrary untyped identities serving as values o the definition of arbitrary untyped identities serving as values
of pointers, of pointers,
o the definition of SMIng extensions to allow the local module or o the definition of SMIng extensions to allow the local module or
other modules to specify information beyond the scope of the base other modules to specify information beyond the scope of the base
SMIng in a machine readable notation. Some extensions for the SMIng in a machine readable notation. Some extensions for the
application of SMIng in the SNMP framework are defined in [3], application of SMIng in the SNMP framework are defined in [3],
o the definition of information beyond the scope of the base SMIng o the definition of information beyond the scope of the base SMIng
statements, based on locally defined or imported SMIng statements, based on locally defined or imported SMIng extensions.
extensions.
Each module is identified by an upper-case identifier. The names of Each module is identified by an upper-case identifier. The names of
all standard modules must be unique (but different versions of the all standard modules must be unique (but different versions of the
same module should have the same name). Developers of enterprise same module should have the same name). Developers of enterprise
modules are encouraged to choose names for their modules that will modules are encouraged to choose names for their modules that will
have a low probability of colliding with standard or other have a low probability of colliding with standard or other enterprise
enterprise modules, e.g. by using the enterprise or organization modules, e.g. by using the enterprise or organization name as a
name as a prefix. prefix.
2.1 Identifiers 2.1 Identifiers
Identifiers are used to identify different kinds of SMIng items by Identifiers are used to identify different kinds of SMIng items by
name. Each identifier is valid in a namespace which depends on the name. Each identifier is valid in a namespace which depends on the
type of the SMIng item being defined: type of the SMIng item being defined:
o The global namespace contains all module identifiers. o The global namespace contains all module identifiers.
o Each module defines a new namespace. A module's namespace may o Each module defines a new namespace. A module's namespace may
contain definitions of extension identifiers, derived type contain definitions of extension identifiers, derived type
identifiers, identity identifiers, and class identifiers. identifiers, identity identifiers, and class identifiers.
Furthermore, a module may import identifiers of these kinds from Furthermore, a module may import identifiers of these kinds from
other modules. All these identifiers are also visible within all other modules. All these identifiers are also visible within all
inner namespaces of the module. inner namespaces of the module.
o Each class within a module defines a new namespace. A class' o Each class within a module defines a new namespace. A class'
namespace may contain definitions of attribute identifiers and namespace may contain definitions of attribute identifiers and
event identifiers. event identifiers.
o Each enumeration type and bitset type defines a new namespace of o Each enumeration type and bitset type defines a new namespace of
its named numbers. These named numbers are visible in each its named numbers. These named numbers are visible in each
expression of a corresponding value, e.g., default values and expression of a corresponding value, e.g., default values and sub-
sub-typing restrictions. typing restrictions.
o Extensions may define additional namespaces and have additional o Extensions may define additional namespaces and have additional
rules of other namespaces' visibilty. rules of other namespaces' visibilty.
Within every namespace each identifier MUST be unique. Within every namespace each identifier MUST be unique.
Each identifier starts with an upper-case or lower-case character, Each identifier starts with an upper-case or lower-case character,
dependent on the kind of SMIng item, followed by zero or more dependent on the kind of SMIng item, followed by zero or more
letters, digits and hyphens. letters, digits and hyphens.
All identifiers defined in a namespace MUST be unique and SHOULD NOT All identifiers defined in a namespace MUST be unique and SHOULD NOT
only differ in case. Identifiers MUST NOT exceed 64 characters in only differ in case. Identifiers MUST NOT exceed 64 characters in
length. Furthermore, the set of all identifiers defined in all length. Furthermore, the set of all identifiers defined in all
modules of a single standardization body or organization SHOULD be modules of a single standardization body or organization SHOULD be
unique and mnemonic. This promotes a common language for humans to unique and mnemonic. This promotes a common language for humans to
use when discussing a module. use when discussing a module.
To reference an item that is defined in the local module, its To reference an item that is defined in the local module, its
definition MUST sequentially precede the reference. Thus, there MUST definition MUST sequentially precede the reference. Thus, there MUST
NOT be any forward references. NOT be any forward references.
To reference an item, that is defined in an external module it MUST To reference an item, that is defined in an external module it MUST
be imported into the local module's namespace (Section 5.1). be imported into the local module's namespace (Section 5.1).
Identifiers that are neither defined nor imported MUST NOT be visible
Identifiers that are neither defined nor imported MUST NOT be in the local module. On the other hand, all items defined in a
visible in the local module. On the other hand, all items defined in module are implicitly exported.
a module are implicitly exported.
When identifiers from external modules are referenced, there is the When identifiers from external modules are referenced, there is the
possibility of name collisions. As such, if different items with the possibility of name collisions. As such, if different items with the
same identifier are imported or if imported identifiers collide with same identifier are imported or if imported identifiers collide with
identifiers of locally defined items, then this ambiguity is identifiers of locally defined items, then this ambiguity is resolved
resolved by prefixing those identifiers with the names of their by prefixing those identifiers with the names of their modules and
modules and the namespace operator `::', i.e. `Module::item'. Of the namespace operator `::', i.e. `Module::item'. Of course, this
course, this notation can be used to refer to identifiers even when notation can be used to refer to identifiers even when there is no
there is no name collision. name collision.
Note that SMIng core language keywords MUST NOT be imported. See the Note that SMIng core language keywords MUST NOT be imported. See the
`...Keyword' rules of the SMIng ABNF grammar in Appendix A for a `...Keyword' rules of the SMIng ABNF grammar in Appendix A for a list
list of those keywords. of those keywords.
3. Base Types and Derived Types 3. Base Types and Derived Types
SMIng has a minimal but complete set of base types, similar to those SMIng has a minimal but complete set of base types, similar to those
of many programming languages, but with some differences due to of many programming languages, but with some differences due to
special requirements from the management information model. special requirements from the management information model.
Additional types may be defined, derived from those base types or Additional types may be defined, derived from those base types or
from other derived types. Derived types may use subtyping to from other derived types. Derived types may use subtyping to
formally restrict the set of possible values. An initial set of formally restrict the set of possible values. An initial set of
commonly used derived types is defined in the SMIng standard module commonly used derived types is defined in the SMIng standard module
IETF-SMING[1]. IETF-SMING [1].
The different base types and their derived types allow different The different base types and their derived types allow different
kinds of subtyping, namely size restrictions and range restrictions. kinds of subtyping, namely size restrictions and range restrictions.
See the following sections on base types (Section 3.1 through See the following sections on base types (Section 3.1 through Section
Section 3.11) for details. 3.12) for details.
3.1 OctetString 3.1 OctetString
The OctetString base type represents arbitrary binary or textual The OctetString base type represents arbitrary binary or textual
data. Although SMIng has a theoretical size limitation of 2^16-1 data. Although SMIng has a theoretical size limitation of 2^16-1
(65535) octets for this base type, module designers should realize (65535) octets for this base type, module designers should realize
that there may be implementation and interoperability limitations that there may be implementation and interoperability limitations for
for sizes in excess of 255 octets. sizes in excess of 255 octets.
Values of octet strings may be denoted as textual data enclosed in Values of octet strings may be denoted as textual data enclosed in
double quotes or as arbitrary binary data denoted as a `0x'-prefixed double quotes or as arbitrary binary data denoted as a `0x'-prefixed
hexadecimal value of an even number of at least two hexadecimal hexadecimal value of an even number of at least two hexadecimal
digits, where each pair of hexadecimal digits represents a single digits, where each pair of hexadecimal digits represents a single
octet. Letters in hexadecimal values MAY be upper-case but octet. Letters in hexadecimal values MAY be upper-case but lower-
lower-case characters are RECOMMENDED. Textual data may contain any case characters are RECOMMENDED. Textual data may contain any number
number (possibly zero) of any 7-bit displayable ASCII characters (possibly zero) of any 7-bit displayable ASCII characters except
except double quote `"', including tab characters, spaces and line double quote `"', including tab characters, spaces and line
terminator characters (nl or cr & nl). Textual data may span terminator characters (nl or cr & nl). Textual data may span
multiple lines, where each subsequent line prefix containing only multiple lines, where each subsequent line prefix containing only
white space up to the column where the first line's data starts white space up to the column where the first line's data starts
SHOULD be skipped by parsers for a better text formatting. SHOULD be skipped by parsers for a better text formatting.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
OctetString base type, the size in octets may be restricted by OctetString base type, the size in octets may be restricted by
appending a list of size ranges or explicit size values, separated appending a list of size ranges or explicit size values, separated by
by pipe `|' characters and the whole list enclosed in parenthesis. A pipe `|' characters and the whole list enclosed in parenthesis. A
size range consists of a lower bound, two consecutive dots `..' and size range consists of a lower bound, two consecutive dots `..' and
an upper bound. Each value can be given in decimal or `0x'-prefixed an upper bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. Size restricting values MUST NOT be of at least two digits. Size restricting values MUST NOT be
negative. If multiple values or ranges are given, they all MUST be negative. If multiple values or ranges are given, they all MUST be
disjoint and MUST be in ascending order. If a size restriction is disjoint and MUST be in ascending order. If a size restriction is
applied to an already size restricted octet string the new applied to an already size restricted octet string the new
restriction MUST be equal or more limiting, that is raising the restriction MUST be equal or more limiting, that is raising the lower
lower bounds, reducing the upper bounds, removing explicit size bounds, reducing the upper bounds, removing explicit size values or
values or ranges, or splitting ranges into multiple ranges with ranges, or splitting ranges into multiple ranges with intermediate
intermediate gaps. gaps.
Value Examples: Value Examples:
"This is a multiline "This is a multiline
textual data example." // legal textual data example." // legal
"This is "illegally" quoted." // illegal quotes "This is "illegally" quoted." // illegal quotes
"But this is 'ok'." // legal apostrophe quoting "But this is 'ok'." // legal apostrophe quoting
"" // legal zero length "" // legal zero length
0x123 // illegal odd hex length 0x123 // illegal odd hex length
0x534d496e670a // legal octet string 0x534d496e670a // legal octet string
Restriction Examples: Restriction Examples:
OctetString (0 | 4..255) // legal size spec OctetString (0 | 4..255) // legal size spec
OctetString (4) // legal exact size OctetString (4) // legal exact size
OctetString (-1 | 1) // illegal negative size OctetString (-1 | 1) // illegal negative size
OctetString (5 | 0) // illegal ordering OctetString (5 | 0) // illegal ordering
OctetString (1 | 1..10) // illegal overlapping OctetString (1 | 1..10) // illegal overlapping
3.2 Identity 3.2 Pointer
The Identity base type represents values that reference an identity The Pointer base type represents values that reference class
which has been defined by an identity statement (Section 8). Values instances, attributes of class instances, or arbitrary identities.
of the Identity type are denoted as identifiers of identities.
The only values of the Pointer type that can be present in a module
can refer to identities. They are denoted as identifiers of the
concerned identities.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Identity base type, the values may be restricted to a specific Pointer base type, the values may be restricted to a specific class,
identity and all (directly or indirectly) derived identities by attribute or identity and all (directly or indirectly) derived items
appending the identity enclosed in parenthesis. thereof by appending the identifier of the appropriate construct
enclosed in parenthesis.
Value Examples: Value Examples:
null // legal identity name null // legal identity name
snmpUDPDomain // legal identity name
Restriction Examples: Restriction Examples:
Identity (snmpTransportDomain) // legal restriction Pointer (snmpTransportDomain) // legal restriction
3.3 Integer32 3.3 Object Identifier
The Integer32 base type represents integer values between -2^31 The ObjectIdentifier base type represents administratively assigned
(-2147483648) and 2^31-1 (2147483647). names for use with SNMP and COPS-PR. This type SHOULD NOT be used in
protocol independant SMIng modules. It is meant to be used in SNMP
and COPS-PR mappings of attributes of type Pointer (Section 3.2).
Values of this type may be denoted as a sequence of numerical non-
negative sub-identifier values which each MUST NOT exceed 2^32-1
(4294967295). Sub-identifiers may be denoted decimal or `0x'-
prefixed hexadecimal. They are separated by single dots and without
any intermediate white space. Alternatively (and preferred in most
cases), the first element may be a previously defined or imported
lower-case identifier, representing a static object identifier
prefix. The total number of sub-identifiers MUST NOT exceed 128
including the expanded identifier.
Object identifier derived types cannot be restricted in any way.
Value Examples:
1.3.6.1 // legal numerical oid
mib-2.1 // legal oid with identifier prefix
internet.4.1.0x0627.0x01 // legal oid with hex subids
iso.-1 // illegal negative subid
iso.org.6 // illegal non-heading identifier
IF-MIB::ifNumber.0 // legel fully quallified instance oid
3.4 Integer32
The Integer32 base type represents integer values between -2^31 (-
2147483648) and 2^31-1 (2147483647).
Values of type Integer32 may be denoted as decimal or hexadecimal Values of type Integer32 may be denoted as decimal or hexadecimal
numbers, where only decimal numbers can be negative. Decimal numbers numbers, where only decimal numbers can be negative. Decimal numbers
other than zero MUST NOT have leading zero digits. Hexadecimal other than zero MUST NOT have leading zero digits. Hexadecimal
numbers are prefixed by `0x' and MUST have an even number of at numbers are prefixed by `0x' and MUST have an even number of at least
least two hexadecimal digits, where letters MAY be upper-case but two hexadecimal digits, where letters MAY be upper-case but lower-
lower-case characters are RECOMMENDED. case characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Integer32 base type, the set of possible values may be restricted by Integer32 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|' appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given they of at least two digits. If multiple values or ranges are given they
all MUST be disjoint and MUST be in ascending order. If a value all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type the new restriction is applied to an already restricted type the new
restriction MUST be equal or more limiting, that is raising the restriction MUST be equal or more limiting, that is raising the lower
lower bounds, reducing the upper bounds, removing explicit values or bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate ranges, or splitting ranges into multiple ranges with intermediate
gaps. gaps.
Value Examples: Value Examples:
015 // illegal leading zero 015 // illegal leading zero
-123 // legal negative value -123 // legal negative value
- 1 // illegal intermediate space - 1 // illegal intermediate space
0xabc // illegal hexadecimal value length 0xabc // illegal hexadecimal value length
-0xff // illegal sign on hex value -0xff // illegal sign on hex value
0x80000000 // illegal value, too large 0x80000000 // illegal value, too large
0xf00f // legal hexadecimal value 0xf00f // legal hexadecimal value
Restriction Examples: Restriction Examples:
Integer32 (0 | 5..10) // legal range spec Integer32 (0 | 5..10) // legal range spec
Integer32 (5..10 | 2..3) // illegal ordering Integer32 (5..10 | 2..3) // illegal ordering
Integer32 (4..8 | 5..10) // illegal overlapping Integer32 (4..8 | 5..10) // illegal overlapping
3.4 Integer64 3.5 Integer64
The Integer64 base type represents integer values between -2^63 The Integer64 base type represents integer values between -2^63 (-
(-9223372036854775808) and 2^63-1 (9223372036854775807). 9223372036854775808) and 2^63-1 (9223372036854775807).
Values of type Integer64 may be denoted as decimal or hexadecimal Values of type Integer64 may be denoted as decimal or hexadecimal
numbers, where only decimal numbers can be negative. Decimal numbers numbers, where only decimal numbers can be negative. Decimal numbers
other than zero MUST NOT have leading zero digits. Hexadecimal other than zero MUST NOT have leading zero digits. Hexadecimal
numbers are prefixed by `0x' and MUST have an even number of numbers are prefixed by `0x' and MUST have an even number of
hexadecimal digits, where letters MAY be upper-case but lower-case hexadecimal digits, where letters MAY be upper-case but lower-case
characters are RECOMMENDED. characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Integer64 base type, the set of possible values may be restricted by Integer64 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|' appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given they of at least two digits. If multiple values or ranges are given they
all MUST be disjoint and MUST be in ascending order. If a value all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type the new restriction is applied to an already restricted type the new
restriction MUST be equal or more limiting, that is raising the restriction MUST be equal or more limiting, that is raising the lower
lower bounds, reducing the upper bounds, removing explicit values or bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate ranges, or splitting ranges into multiple ranges with intermediate
gaps. gaps.
Value Examples: Value Examples:
015 // illegal leading zero 015 // illegal leading zero
-123 // legal negative value -123 // legal negative value
- 1 // illegal intermediate space - 1 // illegal intermediate space
0xabc // illegal hexadecimal value length 0xabc // illegal hexadecimal value length
-0xff // illegal sign on hex value -0xff // illegal sign on hex value
0x80000000 // legal value 0x80000000 // legal value
Restriction Examples: Restriction Examples:
Integer64 (0 | 5..10) // legal range spec Integer64 (0 | 5..10) // legal range spec
Integer64 (5..10 | 2..3) // illegal ordering Integer64 (5..10 | 2..3) // illegal ordering
Integer64 (4..8 | 5..10) // illegal overlapping Integer64 (4..8 | 5..10) // illegal overlapping
3.5 Unsigned32 3.6 Unsigned32
The Unsigned32 base type represents positive integer values between The Unsigned32 base type represents positive integer values between 0
0 and 2^32-1 (4294967295). and 2^32-1 (4294967295).
Values of type Unsigned32 may be denoted as decimal or hexadecimal Values of type Unsigned32 may be denoted as decimal or hexadecimal
numbers. Decimal numbers other than zero MUST NOT have leading zero numbers. Decimal numbers other than zero MUST NOT have leading zero
digits. Hexadecimal numbers are prefixed by `0x' and MUST have an digits. Hexadecimal numbers are prefixed by `0x' and MUST have an
even number of hexadecimal digits, where letters MAY be upper-case even number of hexadecimal digits, where letters MAY be upper-case
but lower-case characters are RECOMMENDED. but lower-case characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Unsigned32 base type, the set of possible values may be restricted Unsigned32 base type, the set of possible values may be restricted by
by appending a list of ranges or explicit values, separated by pipe appending a list of ranges or explicit values, separated by pipe `|'
`|' characters and the whole list enclosed in parenthesis. A range characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given they of at least two digits. If multiple values or ranges are given they
all MUST be disjoint and MUST be in ascending order. If a value all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type the new restriction is applied to an already restricted type the new
restriction MUST be equal or more limiting, that is raising the restriction MUST be equal or more limiting, that is raising the lower
lower bounds, reducing the upper bounds, removing explicit values or bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate ranges, or splitting ranges into multiple ranges with intermediate
gaps. gaps.
Value Examples: Value Examples:
015 // illegal leading zero 015 // illegal leading zero
-123 // illegal negative value -123 // illegal negative value
0xabc // illegal hexadecimal value length 0xabc // illegal hexadecimal value length
0x80000000 // legal hexadecimal value 0x80000000 // legal hexadecimal value
0x8080000000 // illegal value, too large 0x8080000000 // illegal value, too large
Restriction Examples: Restriction Examples:
Unsigned32 (0 | 5..10) // legal range spec Unsigned32 (0 | 5..10) // legal range spec
Unsigned32 (5..10 | 2..3) // illegal ordering Unsigned32 (5..10 | 2..3) // illegal ordering
Unsigned32 (4..8 | 5..10) // illegal overlapping Unsigned32 (4..8 | 5..10) // illegal overlapping
3.6 Unsigned64 3.7 Unsigned64
The Unsigned64 base type represents positive integer values between The Unsigned64 base type represents positive integer values between 0
0 and 2^64-1 (18446744073709551615). and 2^64-1 (18446744073709551615).
Values of type Unsigned64 may be denoted as decimal or hexadecimal Values of type Unsigned64 may be denoted as decimal or hexadecimal
numbers. Decimal numbers other than zero MUST NOT have leading zero numbers. Decimal numbers other than zero MUST NOT have leading zero
digits. Hexadecimal numbers are prefixed by `0x' and MUST have an digits. Hexadecimal numbers are prefixed by `0x' and MUST have an
even number of hexadecimal digits, where letters MAY be upper-case even number of hexadecimal digits, where letters MAY be upper-case
but lower-case characters are RECOMMENDED. but lower-case characters are RECOMMENDED.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Unsigned64 base type, the set of possible values may be restricted Unsigned64 base type, the set of possible values may be restricted by
by appending a list of ranges or explicit values, separated by pipe appending a list of ranges or explicit values, separated by pipe `|'
`|' characters and the whole list enclosed in parenthesis. A range characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper consists of a lower bound, two consecutive dots `..' and an upper
bound. Each value can be given in decimal or `0x'-prefixed bound. Each value can be given in decimal or `0x'-prefixed
hexadecimal notation. Hexadecimal numbers must have an even number hexadecimal notation. Hexadecimal numbers must have an even number
of at least two digits. If multiple values or ranges are given they of at least two digits. If multiple values or ranges are given they
all MUST be disjoint and MUST be in ascending order. If a value all MUST be disjoint and MUST be in ascending order. If a value
restriction is applied to an already restricted type the new restriction is applied to an already restricted type the new
restriction MUST be equal or more limiting, that is raising the restriction MUST be equal or more limiting, that is raising the lower
lower bounds, reducing the upper bounds, removing explicit values or bounds, reducing the upper bounds, removing explicit values or
ranges, or splitting ranges into multiple ranges with intermediate ranges, or splitting ranges into multiple ranges with intermediate
gaps. gaps.
Value Examples: Value Examples:
015 // illegal leading zero 015 // illegal leading zero
-123 // illegal negative value -123 // illegal negative value
0xabc // illegal hexadecimal value length 0xabc // illegal hexadecimal value length
0x8080000000 // legal hexadecimal value 0x8080000000 // legal hexadecimal value
Restriction Examples: Restriction Examples:
Unsigned64 (1..10000000000) // legal range spec Unsigned64 (1..10000000000) // legal range spec
Unsigned64 (5..10 | 2..3) // illegal ordering Unsigned64 (5..10 | 2..3) // illegal ordering
3.7 Float32 3.8 Float32
The Float32 base type represents floating point values of single The Float32 base type represents floating point values of single
precision as described by [15]. precision as described by [15].
Values of type Float32 may be denoted as a decimal fraction with an Values of type Float32 may be denoted as a decimal fraction with an
optional exponent as known from many programming languages. See the optional exponent as known from many programming languages. See the
grammar rule `floatValue' of Appendix A for the detailed syntax. grammar rule `floatValue' of Appendix A for the detailed syntax.
Special values are `snan' (signaling Not-a-Number), `qnan' (quiet Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
Not-a-Number), `neginf' (negative infinity), and `posinf' (positive Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
infinity). Note that -0.0 and +0.0 are different floating point infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0. values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Float32 base type, the set of possible values may be restricted by Float32 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|' appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper consists of a lower bound, two consecutive dots `..' and an upper
bound. If multiple values or ranges are given they all MUST be bound. If multiple values or ranges are given they all MUST be
disjoint and MUST be in ascending order. If a value restriction is disjoint and MUST be in ascending order. If a value restriction is
applied to an already restricted type the new restriction MUST be applied to an already restricted type the new restriction MUST be
equal or more limiting, that is raising the lower bounds, reducing equal or more limiting, that is raising the lower bounds, reducing
the upper bounds, removing explicit values or ranges, or splitting the upper bounds, removing explicit values or ranges, or splitting
ranges into multiple ranges with intermediate gaps. The special ranges into multiple ranges with intermediate gaps. The special
values `snan', `qnan', `neginf', and `posinf' must be explicitly values `snan', `qnan', `neginf', and `posinf' must be explicitly
listed in restrictions if they shall be included, where `snan' and listed in restrictions if they shall be included, where `snan' and
`qnan' cannot be used in ranges. `qnan' cannot be used in ranges.
Note that encoding is not subject to this specification. It has to Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float32. be described by protocols that transport objects of type Float32.
Note also that most floating point encodings disallow the Note also that most floating point encodings disallow the
representation of many values that can be written as decimal representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore, fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be explicit values in floating point type restrictions should be handled
handled with care. with care.
Value Examples: Value Examples:
00.1 // illegal leading zero 00.1 // illegal leading zero
3.1415 // legal value 3.1415 // legal value
-2.5E+3 // legal negative exponential value -2.5E+3 // legal negative exponential value
Restriction Examples: Restriction Examples:
Float32 (-1.0..1.0) // legal range spec Float32 (-1.0..1.0) // legal range spec
Float32 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 Float32 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float32 (neginf..-0.0) // legal range spec Float32 (neginf..-0.0) // legal range spec
Float32 (-10.0..10.0 | 0) // illegal overlapping Float32 (-10.0..10.0 | 0) // illegal overlapping
3.8 Float64 3.9 Float64
The Float64 base type represents floating point values of double The Float64 base type represents floating point values of double
precision as described by [15]. precision as described by [15].
Values of type Float64 may be denoted as a decimal fraction with an Values of type Float64 may be denoted as a decimal fraction with an
optional exponent as known from many programming languages. See the optional exponent as known from many programming languages. See the
grammar rule `floatValue' of Appendix A for the detailed syntax. grammar rule `floatValue' of Appendix A for the detailed syntax.
Special values are `snan' (signaling Not-a-Number), `qnan' (quiet Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
Not-a-Number), `neginf' (negative infinity), and `posinf' (positive Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
infinity). Note that -0.0 and +0.0 are different floating point infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0. values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Float64 base type, the set of possible values may be restricted by Float64 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|' appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper consists of a lower bound, two consecutive dots `..' and an upper
bound. If multiple values or ranges are given they all MUST be bound. If multiple values or ranges are given they all MUST be
disjoint and MUST be in ascending order. If a value restriction is disjoint and MUST be in ascending order. If a value restriction is
applied to an already restricted type the new restriction MUST be applied to an already restricted type the new restriction MUST be
equal or more limiting, that is raising the lower bounds, reducing equal or more limiting, that is raising the lower bounds, reducing
the upper bounds, removing explicit values or ranges, or splitting the upper bounds, removing explicit values or ranges, or splitting
ranges into multiple ranges with intermediate gaps. The special ranges into multiple ranges with intermediate gaps. The special
values `snan', `qnan', `neginf', and `posinf' must be explicitly values `snan', `qnan', `neginf', and `posinf' must be explicitly
listed in restrictions if they shall be included, where `snan' and listed in restrictions if they shall be included, where `snan' and
`qnan' cannot be used in ranges. `qnan' cannot be used in ranges.
Note that encoding is not subject to this specification. It has to Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float64. be described by protocols that transport objects of type Float64.
Note also that most floating point encodings disallow the Note also that most floating point encodings disallow the
representation of many values that can be written as decimal representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore, fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be explicit values in floating point type restrictions should be handled
handled with care. with care.
Value Examples: Value Examples:
00.1 // illegal leading zero 00.1 // illegal leading zero
3.1415 // legal value 3.1415 // legal value
-2.5E+3 // legal negative exponential value -2.5E+3 // legal negative exponential value
Restriction Examples: Restriction Examples:
Float64 (-1.0..1.0) // legal range spec Float64 (-1.0..1.0) // legal range spec
Float64 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 Float64 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float64 (neginf..-0.0) // legal range spec Float64 (neginf..-0.0) // legal range spec
Float64 (-10.0..10.0 | 0) // illegal overlapping Float64 (-10.0..10.0 | 0) // illegal overlapping
3.9 Float128 3.10 Float128
The Float128 base type represents floating point values of quadruple The Float128 base type represents floating point values of quadruple
precision as described by [15]. precision as described by [15].
Values of type Float128 may be denoted as a decimal fraction with an Values of type Float128 may be denoted as a decimal fraction with an
optional exponent as known from many programming languages. See the optional exponent as known from many programming languages. See the
grammar rule `floatValue' of Appendix A for the detailed syntax. grammar rule `floatValue' of Appendix A for the detailed syntax.
Special values are `snan' (signaling Not-a-Number), `qnan' (quiet Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
Not-a-Number), `neginf' (negative infinity), and `posinf' (positive Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
infinity). Note that -0.0 and +0.0 are different floating point infinity). Note that -0.0 and +0.0 are different floating point
values. 0.0 is equal to +0.0. values. 0.0 is equal to +0.0.
When defining a type derived (directly or indirectly) from the When defining a type derived (directly or indirectly) from the
Float128 base type, the set of possible values may be restricted by Float128 base type, the set of possible values may be restricted by
appending a list of ranges or explicit values, separated by pipe `|' appending a list of ranges or explicit values, separated by pipe `|'
characters and the whole list enclosed in parenthesis. A range characters and the whole list enclosed in parenthesis. A range
consists of a lower bound, two consecutive dots `..' and an upper consists of a lower bound, two consecutive dots `..' and an upper
bound. If multiple values or ranges are given they all MUST be bound. If multiple values or ranges are given they all MUST be
disjoint and MUST be in ascending order. If a value restriction is disjoint and MUST be in ascending order. If a value restriction is
applied to an already restricted type the new restriction MUST be applied to an already restricted type the new restriction MUST be
equal or more limiting, that is raising the lower bounds, reducing equal or more limiting, that is raising the lower bounds, reducing
the upper bounds, removing explicit values or ranges, or splitting the upper bounds, removing explicit values or ranges, or splitting
ranges into multiple ranges with intermediate gaps. The special ranges into multiple ranges with intermediate gaps. The special
values `snan', `qnan', `neginf', and `posinf' must be explicitly values `snan', `qnan', `neginf', and `posinf' must be explicitly
listed in restrictions if they shall be included, where `snan' and listed in restrictions if they shall be included, where `snan' and
`qnan' cannot be used in ranges. `qnan' cannot be used in ranges.
Note that encoding is not subject to this specification. It has to Note that encoding is not subject to this specification. It has to
be described by protocols that transport objects of type Float128. be described by protocols that transport objects of type Float128.
Note also that most floating point encodings disallow the Note also that most floating point encodings disallow the
representation of many values that can be written as decimal representation of many values that can be written as decimal
fractions as used in SMIng for human readability. Therefore, fractions as used in SMIng for human readability. Therefore,
explicit values in floating point type restrictions should be explicit values in floating point type restrictions should be handled
handled with care. with care.
Value Examples: Value Examples:
00.1 // illegal leading zero 00.1 // illegal leading zero
3.1415 // legal value 3.1415 // legal value
-2.5E+3 // legal negative exponential value -2.5E+3 // legal negative exponential value
Restriction Examples: Restriction Examples:
Float128 (-1.0..1.0) // legal range spec Float128 (-1.0..1.0) // legal range spec
Float128 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 Float128 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3
Float128 (neginf..-0.0) // legal range spec Float128 (neginf..-0.0) // legal range spec
Float128 (-10.0..10.0 | 0) // illegal overlapping Float128 (-10.0..10.0 | 0) // illegal overlapping
3.10 Enumeration 3.11 Enumeration
The Enumeration base type represents values from a set of integers The Enumeration base type represents values from a set of integers in
in the range between -2^31 (-2147483648) and 2^31-1 (2147483647), the range between -2^31 (-2147483648) and 2^31-1 (2147483647), where
where each value has an assigned name. The list of those named each value has an assigned name. The list of those named numbers has
numbers has to be comma-separated, enclosed in parenthesis and to be comma-separated, enclosed in parenthesis and appended to the
appended to the `Enumeration' keyword. Each named number is denoted `Enumeration' keyword. Each named number is denoted by its lower-
by its lower-case identifier followed by the assigned integer value, case identifier followed by the assigned integer value, denoted as a
denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis.
in parenthesis. Hexadecimal numbers must have an even number of at Hexadecimal numbers must have an even number of at least two digits.
least two digits. Every name and every number in an enumeration type Every name and every number in an enumeration type MUST be unique.
MUST be unique. It is RECOMMENDED that values are positive and start It is RECOMMENDED that values are positive and start at 1 and be
at 1 and be numbered contiguously. All named numbers MUST be given numbered contiguously. All named numbers MUST be given in ascending
in ascending order. order.
Values of enumeration types may be denoted as decimal or Values of enumeration types may be denoted as decimal or `0x'-
`0x'-prefixed hexadecimal numbers or preferably as their assigned prefixed hexadecimal numbers or preferably as their assigned names.
names. Hexadecimal numbers must have an even number of at least two Hexadecimal numbers must have an even number of at least two digits.
digits.
When defining a type derived (directly or indirectly) from an When defining a type derived (directly or indirectly) from an
enumeration type, the set of named numbers may be equal or enumeration type, the set of named numbers may be equal or restricted
restricted by removing one or more named numbers. But no named by removing one or more named numbers. But no named numbers may be
numbers may be added or changed regarding its name, value, or both. added or changed regarding its name, value, or both.
Type and Value Examples: Type and Value Examples:
Enumeration (up(1), down(2), testing(3)) Enumeration (up(1), down(2), testing(3))
Enumeration (down(2), up(1)) // illegal order Enumeration (down(2), up(1)) // illegal order
0 // legal (though not recommended) value 0 // legal (though not recommended) value
up // legal value given by name up // legal value given by name
2 // legal value given by number 2 // legal value given by number
3.11 Bits 3.12 Bits
The Bits base type represents bit sets. That is, a Bits value is a The Bits base type represents bit sets. That is, a Bits value is a
set of flags identified by small integer numbers starting at 0. Each set of flags identified by small integer numbers starting at 0. Each
bit number has an assigned name. The list of those named numbers has bit number has an assigned name. The list of those named numbers has
to be comma-separated, enclosed in parenthesis and appended to the to be comma-separated, enclosed in parenthesis and appended to the
`Bits' keyword. Each named number is denoted by its lower-case `Bits' keyword. Each named number is denoted by its lower-case
identifier followed by the assigned integer value, denoted as a identifier followed by the assigned integer value, denoted as a
decimal or `0x'-prefixed hexadecimal number, enclosed in decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis.
parenthesis. Hexadecimal numbers must have an even number of at Hexadecimal numbers must have an even number of at least two digits.
least two digits. Every name and every number in a bits type MUST be Every name and every number in a bits type MUST be unique. It is
unique. It is RECOMMENDED that numbers start at 0 and be numbered RECOMMENDED that numbers start at 0 and be numbered contiguously.
contiguously. Negative numbers are forbidden. All named numbers Negative numbers are forbidden. All named numbers MUST be given in
MUST be given in ascending order. ascending order.
Values of bits types may be denoted as a comma-separated list of Values of bits types may be denoted as a comma-separated list of
decimal or `0x'-prefixed hexadecimal numbers or preferably their decimal or `0x'-prefixed hexadecimal numbers or preferably their
assigned names enclosed in parenthesis. Hexadecimal numbers must assigned names enclosed in parenthesis. Hexadecimal numbers must
have an even number of at least two digits. There MUST NOT be any have an even number of at least two digits. There MUST NOT be any
element (by name or number) listed more than once. Elements MUST be element (by name or number) listed more than once. Elements MUST be
listed in ascending order. listed in ascending order.
When defining a type derived (directly or indirectly) from a bits When defining a type derived (directly or indirectly) from a bits
type, the set of named numbers may be restricted by removing one or type, the set of named numbers may be restricted by removing one or
more named numbers. But no named numbers may be added or changed more named numbers. But no named numbers may be added or changed
regarding its name, value, or both. regarding its name, value, or both.
Type and Value Examples: Type and Value Examples:
Bits (readable(0), writeable(1), executable(2)) Bits (readable(0), writeable(1), executable(2))
Bits (writeable(1), readable(0) // illegal order Bits (writeable(1), readable(0) // illegal order
() // legal empty value () // legal empty value
(readable, writeable, 2) // legal value (readable, writeable, 2) // legal value
(0, readable, executable) // illegal, readable(0) appears twice (0, readable, executable) // illegal, readable(0) appears twice
(writeable, 4) // illegal, element 4 out of range (writeable, 4) // illegal, element 4 out of range
3.12 Display Formats 3.13 Display Formats
Attribute definitions and type definitions allow the specification Attribute definitions and type definitions allow the specification of
of a format to be used, when a value of that attribute or an a format to be used, when a value of that attribute or an attribute
attribute of that type is displayed. Format specifications are of that type is displayed. Format specifications are represented as
represented as textual data. textual data.
When the attribute or type has an underlying base type of Integer32, When the attribute or type has an underlying base type of Integer32,
Integer64, Unsigned32, or Unsigned64, the format consists of an Integer64, Unsigned32, or Unsigned64, the format consists of an
integer-format specification, containing two parts. The first part integer-format specification, containing two parts. The first part
is a single character suggesting a display format, either: `x' for is a single character suggesting a display format, either: `x' for
hexadecimal, or `d' for decimal, or `o' for octal, or `b' for hexadecimal, or `d' for decimal, or `o' for octal, or `b' for binary.
binary. For all types, when rendering the value, leading zeros are For all types, when rendering the value, leading zeros are omitted,
omitted, and for negative values, a minus sign is rendered and for negative values, a minus sign is rendered immediately before
immediately before the digits. The second part is always omitted the digits. The second part is always omitted for `x', `o' and `b',
for `x', `o' and `b', and need not be present for `d'. If present, and need not be present for `d'. If present, the second part starts
the second part starts with a hyphen and is followed by a decimal with a hyphen and is followed by a decimal number, which defines the
number, which defines the implied decimal point when rendering the implied decimal point when rendering the value. For example `d-2'
value. For example `d-2' suggests that a value of 1234 be rendered suggests that a value of 1234 be rendered as `12.34'.
as `12.34'.
When the attribute or type has an underlying base type of When the attribute or type has an underlying base type of
OctetString, the format consists of one or more octet-format OctetString, the format consists of one or more octet-format
specifications. Each specification consists of five parts, with specifications. Each specification consists of five parts, with each
each part using and removing zero or more of the next octets from part using and removing zero or more of the next octets from the
the value and producing the next zero or more characters to be value and producing the next zero or more characters to be displayed.
displayed. The octets within the value are processed in order of The octets within the value are processed in order of significance,
significance, most significant first. most significant first.
The five parts of a octet-format specification are: The five parts of a octet-format specification are:
1. the (optional) repeat indicator; if present, this part is a `*', 1. the (optional) repeat indicator; if present, this part is a `*',
and indicates that the current octet of the value is to be used and indicates that the current octet of the value is to be used
as the repeat count. The repeat count is an unsigned integer as the repeat count. The repeat count is an unsigned integer
(which may be zero) which specifies how many times the remainder (which may be zero) which specifies how many times the remainder
of this octet-format specification should be successively of this octet-format specification should be successively
applied. If the repeat indicator is not present, the repeat applied. If the repeat indicator is not present, the repeat
count is one. count is one.
2. the octet length: one or more decimal digits specifying the 2. the octet length: one or more decimal digits specifying the
number of octets of the value to be used and formatted by this number of octets of the value to be used and formatted by this
octet-specification. Note that the octet length can be zero. octet-specification. Note that the octet length can be zero. If
If less than this number of octets remain in the value, then the less than this number of octets remain in the value, then the
lesser number of octets are used. lesser number of octets are used.
3. the display format, either: `x' for hexadecimal, `d' for 3. the display format, either: `x' for hexadecimal, `d' for decimal,
decimal, `o' for octal, `a' for ASCII, or `t' for UTF-8 [16]. If `o' for octal, `a' for ASCII, or `t' for UTF-8 [16]. If the
the octet length part is greater than one, and the display octet length part is greater than one, and the display format
format part refers to a numeric format, then network part refers to a numeric format, then network byte-ordering (big-
byte-ordering (big-endian encoding) is used interpreting the endian encoding) is used interpreting the octets in the value.
octets in the value. The octets processed by the `t' display The octets processed by the `t' display format do not necessarily
format do not necessarily form an integral number of UTF-8 form an integral number of UTF-8 characters. Trailing octets
characters. Trailing octets which do not form a valid UTF-8 which do not form a valid UTF-8 encoded character are discarded.
encoded character are discarded.
4. the (optional) display separator character; if present, this 4. the (optional) display separator character; if present, this part
part is a single character which is produced for display after is a single character which is produced for display after each
each application of this octet-specification; however, this application of this octet-specification; however, this character
character is not produced for display if it would be immediately is not produced for display if it would be immediately followed
followed by the display of the repeat terminator character for by the display of the repeat terminator character for this octet
this octet specification. This character can be any character specification. This character can be any character other than a
other than a decimal digit and a `*'. decimal digit and a `*'.
5. the (optional) repeat terminator character, which can be present 5. the (optional) repeat terminator character, which can be present
only if the display separator character is present and this only if the display separator character is present and this octet
octet specification begins with a repeat indicator; if present, specification begins with a repeat indicator; if present, this
this part is a single character which is produced after all the part is a single character which is produced after all the zero
zero or more repeated applications (as given by the repeat or more repeated applications (as given by the repeat count) of
count) of this octet specification. This character can be any this octet specification. This character can be any character
character other than a decimal digit and a `*'. other than a decimal digit and a `*'.
Output of a display separator character or a repeat terminator Output of a display separator character or a repeat terminator
character is suppressed if it would occur as the last character of character is suppressed if it would occur as the last character of
the display. the display.
If the octets of the value are exhausted before all the octet format If the octets of the value are exhausted before all the octet format
specification have been used, then the excess specifications are specification have been used, then the excess specifications are
ignored. If additional octets remain in the value after ignored. If additional octets remain in the value after interpreting
interpreting all the octet format specifications, then the last all the octet format specifications, then the last octet format
octet format specification is re-interpreted to process the specification is re-interpreted to process the additional octets,
additional octets, until no octets remain in the value. until no octets remain in the value.
Note that for some types no format specifications are defined and Note that for some types no format specifications are defined and
SHOULD be omitted. Implementations MUST ignore format specifications SHOULD be omitted. Implementations MUST ignore format specifications
they cannot interpret. Also note that the SMIng grammar (Appendix A) they cannot interpret. Also note that the SMIng grammar (Appendix A)
does not specify the syntax of format specifications. does not specify the syntax of format specifications.
Display Format Examples: Display Format Examples:
Base Type Format Example Value Rendered Value Base Type Format Example Value Rendered Value
----------- ------------------- ---------------- ----------------- ----------- ------------------- ---------------- -----------------
OctetString 255a "Hello World." Hello World. OctetString 255a "Hello World." Hello World.
OctetString 1x: "Hello!" 48:65:6c:6c:6f:21 OctetString 1x: "Hello!" 48:65:6c:6c:6f:21
OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0 OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0
OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024 OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024
OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee
Integer32 d-2 1234 12.34 Integer32 d-2 1234 12.34
4. The SMIng File Structure 4. The SMIng File Structure
The topmost container of SMIng information is a file. An SMIng file The topmost container of SMIng information is a file. An SMIng file
may contain zero, one or more modules. It is RECOMMENDED to separate may contain zero, one or more modules. It is RECOMMENDED to separate
modules into files named by their modules, where possible. Though, modules into files named by their modules, where possible. Though,
for dedicated purposes it may be reasonable to collect several for dedicated purposes it may be reasonable to collect several
modules in a single file. modules in a single file.
The top level SMIng construct is the `module' statement (Section 5) The top level SMIng construct is the `module' statement (Section 5)
that defines a single SMIng module. A module contains a sequence of that defines a single SMIng module. A module contains a sequence of
sections in an obligatory order with different kinds of definitions. sections in an obligatory order with different kinds of definitions.
Whether these sections contain statements or remain empty mainly Whether these sections contain statements or remain empty mainly
depends on the purpose of the module. depends on the purpose of the module.
4.1 Comments 4.1 Comments
Comments can be included at any position in an SMIng file, except in Comments can be included at any position in an SMIng file, except in
between the characters of a single token like those of a quoted between the characters of a single token like those of a quoted
string. However, it is RECOMMENDED that all substantive string. However, it is RECOMMENDED that all substantive descriptions
descriptions be placed within an appropriate description clause, so be placed within an appropriate description clause, so that the
that the information is available to SMIng parsers. information is available to SMIng parsers.
Comments commence with a pair of adjacent slashes `//' and end at Comments commence with a pair of adjacent slashes `//' and end at the
the end of the line. end of the line.
4.2 Statements and Arguments 4.2 Statements and Arguments
SMIng has a very small set of basic grammar rules based on the SMIng has a very small set of basic grammar rules based on the
concept of statements. Each statement starts with a lower-case concept of statements. Each statement starts with a lower-case
keyword identifying the statement followed by a number (possibly keyword identifying the statement followed by a number (possibly
zero) of arguments. An argument may be quoted text, an identifier, a zero) of arguments. An argument may be quoted text, an identifier, a
value of any base type, a list of identifiers enclosed in value of any base type, a list of identifiers enclosed in parenthesis
parenthesis `( )' or a statement block enclosed in curly braces `{ `( )' or a statement block enclosed in curly braces `{ }'. Since
}'. Since statement blocks are valid arguments, it is possible to statement blocks are valid arguments, it is possible to nest
nest statement sequences. Each statement is terminated by a statement sequences. Each statement is terminated by a semicolon
semicolon `;'. `;'.
The core set of statements may be extended using the SMIng The core set of statements may be extended using the SMIng
`extension' statement. See Section 6 and Section 11 for details. `extension' statement. See Section 6 and Section 11 for details.
At places where a statement is expected, but an unknown lower-case At places where a statement is expected, but an unknown lower-case
word is read, those statements MUST be skipped up to the proper word is read, those statements MUST be skipped up to the proper
semicolon, including nested statement blocks. semicolon, including nested statement blocks.
5. The module Statement 5. The module Statement
The `module' statement is used as a container of all definitions of The `module' statement is used as a container of all definitions of a
a single SMIng module. It gets two arguments: an upper-case module single SMIng module. It gets two arguments: an upper-case module
name and a statement block that contains mandatory and optional name and a statement block that contains mandatory and optional
statements and sections of statements in an obligatory order: statements and sections of statements in an obligatory order:
module <MODULE-NAME> { module <MODULE-NAME> {
<optional import statements> <optional import statements>
<organization statement> <organization statement>
<contact statement> <contact statement>
<description statement> <description statement>
<optional reference statement> <optional reference statement>
skipping to change at page 22, line 32 skipping to change at page 21, line 27
<optional typedef statements> <optional typedef statements>
<optional class statements> <optional class statements>
}; };
The optional `import' statements are followed by the mandatory The optional `import' statements are followed by the mandatory
`organization', `contact', and `description' statements and the `organization', `contact', and `description' statements and the
optional `reference' statement, which in turn are followed by the optional `reference' statement, which in turn are followed by the
mandatory `revision' statements. This part defines the module's meta mandatory `revision' statements. This part defines the module's meta
information while the following sections contain its main information while the following sections contain its main
definitions. definitions.
See the `moduleStatement' rule of the SMIng grammar (Appendix A) for See the `moduleStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `module' statement. the formal syntax of the `module' statement.
5.1 The module's import Statement 5.1 The module's import Statement
The optional module's `import' statement is used to import The optional module's `import' statement is used to import
identifiers from external modules into the local module's namespace. identifiers from external modules into the local module's namespace.
It gets two arguments: the name of the external module and a It gets two arguments: the name of the external module and a comma-
comma-separated list of one or more identifiers to be imported separated list of one or more identifiers to be imported enclosed in
enclosed in parenthesis. parenthesis.
Multiple `import' statements for the same module but with disjoint Multiple `import' statements for the same module but with disjoint
lists of identifiers are allowed, though NOT RECOMMENDED. Anyhow, lists of identifiers are allowed, though NOT RECOMMENDED. Anyhow,
the same identifier from the same module MUST NOT be imported the same identifier from the same module MUST NOT be imported
multiple times. To import identifiers with the same name from multiple times. To import identifiers with the same name from
different modules might be necessary and is allowed. To distinguish different modules might be necessary and is allowed. To distinguish
them in the local module, they have to be referred by qualified them in the local module, they have to be referred by qualified
names. It is NOT RECOMMENDED to import identifiers not used in the names. It is NOT RECOMMENDED to import identifiers not used in the
local module. local module.
See the `importStatement' rule of the SMIng grammar (Appendix A) for See the `importStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `import' statement. the formal syntax of the `import' statement.
5.2 The module's organization Statement 5.2 The module's organization Statement
The module's `organization' statement, which must be present, gets The module's `organization' statement, which must be present, gets
one argument which is used to specify a textual description of the one argument which is used to specify a textual description of the
organization(s) under whose auspices this module was developed. organization(s) under whose auspices this module was developed.
5.3 The module's contact Statement 5.3 The module's contact Statement
The module's `contact' statement, which must be present, gets one The module's `contact' statement, which must be present, gets one
argument which is used to specify the name, postal address, argument which is used to specify the name, postal address, telephone
telephone number, and electronic mail address of the person to whom number, and electronic mail address of the person to whom technical
technical queries concerning this module should be sent. queries concerning this module should be sent.
5.4 The module's description Statement 5.4 The module's description Statement
The module's `description' statement, which must be present, gets The module'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 contents of this module. the contents of this module.
5.5 The module's reference Statement 5.5 The module's reference Statement
The module's `reference' statement, which need not be present, gets The module'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
management information, or some other document which provides management information, or some other document which provides
additional information relevant to this module. additional information relevant to this module.
5.6 The module's revision Statement 5.6 The module's revision Statement
The module's `revision' statement is repeatedly used to specify the The module's `revision' statement is repeatedly used to specify the
editorial revisions of the module, including the initial revision. editorial revisions of the module, including the initial revision.
It gets one argument which is a statement block that holds detailed It gets one argument which is a statement block that holds detailed
information in an obligatory order. A module MUST have at least one information in an obligatory order. A module MUST have at least one
initial `revision' statement. For every editorial change, a new one initial `revision' statement. For every editorial change, a new one
MUST be added in front of the revisions sequence, so that all MUST be added in front of the revisions sequence, so that all
revisions are in reverse chronological order. revisions are in reverse chronological order.
See the `revisionStatement' rule of the SMIng grammar (Appendix A) See the `revisionStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `revision' statement. for the formal syntax of the `revision' statement.
5.6.1 The revision's date Statement 5.6.1 The revision's date Statement
The revision's `date' statement, which must be present, gets one The revision's `date' statement, which must be present, gets one
argument which is used to specify the date and time of the revision argument which is used to specify the date and time of the revision
in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the
time `00:00'. The time is always given in UTC. time `00:00'. The time is always given in UTC.
See the `date' rule of the SMIng grammar (Appendix A) for the formal See the `date' rule of the SMIng grammar (Appendix A) for the formal
syntax of the revision's `date' statement. syntax of the revision's `date' statement.
5.6.2 The revision's description Statement 5.6.2 The revision's description Statement
The revision's `description' statement, which must be present, gets The revision'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 revision. description of the revision.
skipping to change at page 26, line 7 skipping to change at page 24, line 7
description description
"Initial revision, published as RFC XXXX."; "Initial revision, published as RFC XXXX.";
}; };
// ... further definitions ... // ... further definitions ...
}; // end of module FIZBIN. }; // end of module FIZBIN.
6. The extension Statement 6. The extension Statement
The `extension' statement is used to define new statements to be The `extension' statement is used to define new statements to be used
used in the local module following this extension statement in the local module following this extension statement definition or
definition or in external modules that may import this extension in external modules that may import this extension statement
statement definition. The `extension' statement gets two arguments: definition. The `extension' statement gets two arguments: a lower-
a lower-case extension statement identifier and a statement block case extension statement identifier and a statement block that holds
that holds detailed extension information in an obligatory order. detailed extension information in an obligatory order.
Extension statement identifiers SHOULD NOT contain any upper-case Extension statement identifiers SHOULD NOT contain any upper-case
characters. characters.
Note that the SMIng extension feature does not allow to formally Note that the SMIng extension feature does not allow to formally
specify the context, argument syntax and semantics of an extension. specify the context, argument syntax and semantics of an extension.
Its only purpose is to declare the existence of an extension and to Its only purpose is to declare the existence of an extension and to
allow a unique reference to an extension. See Section 11 for allow a unique reference to an extension. See Section 11 for
detailed information on extensions and [3] for mappings of SMIng detailed information on extensions and [3] for mappings of SMIng
definitions to SNMP which is formally defined as an extension. definitions to SNMP which is formally defined as an extension.
See the `extensionStatement' rule of the SMIng grammar (Appendix A) See the `extensionStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `extension' statement. for the formal syntax of the `extension' statement.
6.1 The extension's status Statement 6.1 The extension's status Statement
The extension's `status' statement, which need not be present, gets The extension's `status' statement, which must be present, gets one
one argument which is used to specify whether this extension argument which is used to specify whether this extension definition
definition is current or historic. The value `current' means that is current or historic. The value `current' means that the
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 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.
6.2 The extension's description Statement 6.2 The extension's description Statement
The extension's `description' statement, which must be present, gets The extension'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 extension statement. description of the extension statement.
It is RECOMMENDED to include information on the extension's context, It is RECOMMENDED to include information on the extension's context,
its semantics, and implementation conditions. See also Section 11. its semantics, and implementation conditions. See also Section 11.
6.3 The extension's reference Statement 6.3 The extension's reference Statement
The extension's `reference' statement, which need not be present, The extension'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
extension definitions, or some other document which provides extension definitions, or some other document which provides
additional information relevant to this extension. additional information relevant to this extension.
6.4 The extension's abnf Statement 6.4 The extension's abnf Statement
The extension's `abnf' statement, which need not be present, gets The extension's `abnf' statement, which need not be present, gets one
one argument which is used to specify a formal ABNF [12] grammar argument which is used to specify a formal ABNF [12] grammar
definition of the extension. This grammar can reference rule names definition of the extension. This grammar can reference rule names
from the core SMIng grammar Appendix A. from the core SMIng grammar Appendix A.
Note that the `abnf' statement should contain only pure ABNF and no Note that the `abnf' statement should contain only pure ABNF and no
additional text, though comments prefixed by semicolon are allowed additional text, though comments prefixed by semicolon are allowed
but should probably be moved to the description statement. Note that but should probably be moved to the description statement. Note that
double quotes are not allowed inside textual descriptions which are double quotes are not allowed inside textual descriptions which are
itself enclosed in double quotes. So they have to be replaced by itself enclosed in double quotes. So they have to be replaced by
single quotes. single quotes.
6.5 Usage Example 6.5 Usage Example
extension severity { extension severity {
status current;
description description
"The optional severity extension statement can only "The optional severity extension statement can only
be applied to the statement block of an SMIng class' be applied to the statement block of an SMIng class'
event definition. If it is present it denotes the event definition. If it is present it denotes the
severity level of the event in a range from 0 severity level of the event in a range from 0
(emergency) to 7 (debug)."; (emergency) to 7 (debug).";
abnf abnf
"severityStatement = severityKeyword sep number optsep ';' "severityStatement = severityKeyword sep number optsep ';'
severityKeyword = 'severity'"; severityKeyword = 'severity'";
}; };
7. The typedef Statement 7. The typedef Statement
The `typedef' statement is used to define new data types to be used The `typedef' statement is used to define new data types to be used
in the local module or in external modules. It gets two arguments: in the local module or in external modules. It gets two arguments:
an upper-case type identifier and a statement block that holds an upper-case type identifier and a statement block that holds
detailed type information in an obligatory order. detailed type information in an obligatory order.
Type identifiers SHOULD NOT consist of all upper-case characters and Type identifiers SHOULD NOT consist of all upper-case characters and
SHOULD NOT contain hyphens. SHOULD NOT contain hyphens.
See the `typedefStatement' rule of the SMIng grammar (Appendix A) See the `typedefStatement' rule of the SMIng grammar (Appendix A) for
for the formal syntax of the `typedef' statement. the formal syntax of the `typedef' statement.
7.1 The typedef's type Statement 7.1 The typedef's type Statement
The typedef's `type' statement, which must be present, gets one The typedef's `type' statement, which must be present, gets one
argument which is used to specify the type from which this type is argument which is used to specify the type from which this type is
derived. Optionally, type restrictions may be applied to the new derived. Optionally, type restrictions may be applied to the new
type by appending subtyping information according to the rules of type by appending subtyping information according to the rules of the
the base type. See Section 3 for SMIng base types and their type base type. See Section 3 for SMIng base types and their type
restrictions. restrictions.
7.2 The typedef's default Statement 7.2 The typedef's default Statement
The typedef's `default' statement, which need not be present, gets The typedef's `default' statement, which need not be present, gets
one argument which is used to specify an acceptable default value one argument which is used to specify an acceptable default value for
for attributes of this type. A default value may be used when an attributes of this type. A default value may be used when an
attribute instance is created. That is, the value is a "hint" to attribute instance is created. That is, the value is a "hint" to
implementors. implementors.
The value of the `default' statement must, of course, correspond to The value of the `default' statement must, of course, correspond to
the (probably restricted) type specified in the typedef's `type' the (probably restricted) type specified in the typedef's `type'
statement. statement.
The default value of a type may be overwritten by a default value of The default value of a type may be overwritten by a default value of
an attribute of this type. an attribute of this type.
Note that for some types, default values make no sense. Note that for some types, default values make no sense.
7.3 The typedef's format Statement 7.3 The typedef's format Statement
The typedef's `format' statement, which need not be present, gets The typedef's `format' statement, which need not be present, gets one
one argument which is used to give a hint as to how the value of an argument which is used to give a hint as to how the value of an
instance of an attribute of this type might be displayed. See instance of an attribute of this type might be displayed. See
Section 3.12 for a description of format specifications. Section 3.13 for a description of format specifications.
If no format is specified, it is inherited from the type given in If no format is specified, it is inherited from the type given in the
the `type' statement. On the other hand, the format specification `type' statement. On the other hand, the format specification of a
of a type may be semantically refined by a format specification of type may be semantically refined by a format specification of an
an attribute of this type. attribute of this type.
7.4 The typedef's units Statement 7.4 The typedef's units Statement
The typedef's `units' statement, which need not be present, gets one The typedef's `units' statement, which need not be present, gets one
argument which is used to specify a textual definition of the units argument which is used to specify a textual definition of the units
associated with attributes of this type. associated with attributes of this type.
If no units are specified, they are inherited from the type given in If no units are specified, they are inherited from the type given in
the `type' statement. On the other hand, the units specification of the `type' statement. On the other hand, the units specification of
a type may be semantically refined by a units specification of an a type may be semantically refined by a units specification of an
attribute of this type. attribute of this type.
The units specification has to be appropriate for values displayed The units specification has to be appropriate for values displayed
according to the typedef's format specification, if present. E.g., according to the typedef's format specification, if present. E.g.,
if the type defines frequency values of type Unsigned64 measured in if the type defines frequency values of type Unsigned64 measured in
thousands of Hertz, the format specification should be `d-3' and the thousands of Hertz, the format specification should be `d-3' and the
units specification should be `Hertz' or `Hz'. If the format units specification should be `Hertz' or `Hz'. If the format
specification would be omitted, the units specification should be specification would be omitted, the units specification should be
`Milli-Hertz' or `mHz'. Authors of SMIng modules should pay `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay
attention to keep format and units specifications synced. attention to keep format and units specifications synced.
Application implementors MUST NOT implement units specifications Application implementors MUST NOT implement units specifications
without implementing format specifications. without implementing format specifications.
7.5 The typedef's status Statement 7.5 The typedef's status Statement
The typedef's `status' statement, which need not be present, gets The typedef's `status' statement, which must be present, gets one
one argument which is used to specify whether this type definition argument which is used to specify whether this type definition is
is current or historic. The value `current' means that the current or historic. The value `current' means that the definition
definition is current and valid. The value `obsolete' means the is current and valid. The value `obsolete' means the definition is
definition is obsolete and should not be implemented and/or can be obsolete and should not be implemented and/or can be removed if
removed if previously implemented. While the value `deprecated' previously implemented. While the value `deprecated' also indicates
also indicates an obsolete definition, it permits new/continued an obsolete definition, it permits new/continued implementation in
implementation in order to foster interoperability with order to foster interoperability with older/existing implementations.
older/existing implementations.
Derived types SHOULD NOT be defined as `current' if their underlying Derived types SHOULD NOT be defined as `current' if their underlying
type is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be type is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be
defined as `deprecated' if their underlying type is `obsolete'. defined as `deprecated' if their underlying type is `obsolete'.
Nevertheless, subsequent revisions of the underlying type cannot be Nevertheless, subsequent revisions of the underlying type cannot be
avoided, but SHOULD be taken into account in subsequent revisions of avoided, but SHOULD be taken into account in subsequent revisions of
the local module. the local module.
If the `status' statement is omitted, the status value `current' is
implied.
7.6 The typedef's description Statement 7.6 The typedef's description Statement
The typedef's `description' statement, which must be present, gets The typedef'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 newly defined type. description of the newly defined type.
It is RECOMMENDED to include all semantic definitions necessary for It is RECOMMENDED to include all semantic definitions necessary for
implementation, and to embody any information which would otherwise implementation, and to embody any information which would otherwise
be communicated in any commentary annotations associated with this be communicated in any commentary annotations associated with this
type definition. type definition.
7.7 The typedef's reference Statement 7.7 The typedef's reference Statement
The typedef's `reference' statement, which need not be present, gets The typedef'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 type
type definitions, or some other document which provides additional definitions, or some other document which provides additional
information relevant to this type definition. information relevant to this type definition.
7.8 Usage Examples 7.8 Usage Examples
typedef RptrOperStatus { typedef RptrOperStatus {
type Enumeration (other(1), ok(2), rptrFailure(3), type Enumeration (other(1), ok(2), rptrFailure(3),
groupFailure(4), portFailure(5), groupFailure(4), portFailure(5),
generalFailure(6)); generalFailure(6));
default other; // undefined by default. default other; // undefined by default.
status deprecated; status deprecated;
description description
"A type to indicate the operational state "A type to indicate the operational state
of a repeater."; of a repeater.";
reference reference
"[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState."; "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState.";
}; };
typedef SnmpTransportDomain { typedef SnmpTransportDomain {
type Pointer (snmpTransportDomain); type Pointer (snmpTransportDomain);
status current;
description description
"A pointer to an SNMP transport domain identity."; "A pointer to an SNMP transport domain identity.";
}; };
typedef DateAndTime { typedef DateAndTime {
type OctetString (8 | 11); type OctetString (8 | 11);
format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"; format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
status current; // could be omitted status current;
description description
"A date-time specification. "A date-time specification.
... ...
Note that if only local time is known, then timezone Note that if only local time is known, then timezone
information (fields 8-10) is not present."; information (fields 8-10) is not present.";
reference reference
"RFC 2579, SNMPv2-TC.DateAndTime."; "RFC 2579, SNMPv2-TC.DateAndTime.";
}; };
typedef Frequency { typedef Frequency {
type Unsigned64; type Unsigned64;
format "d-3" format "d-3"
units "Hertz"; units "Hertz";
status current;
description description
"A wide-range frequency specification measured "A wide-range frequency specification measured
in thousands of Hertz."; in thousands of Hertz.";
}; };
8. The identity Statement 8. The identity Statement
The `identity' statement is used to define a new abstract and The `identity' statement is used to define a new abstract and untyped
untyped identity. Its only purpose is to denote its name, semantics identity. Its only purpose is to denote its name, semantics and
and existence. An identity can be defined either from scratch or existence. An identity can be defined either from scratch or derived
derived from a parent identity. The `identity' statement gets the from a parent identity. The `identity' statement gets the following
following two or four arguments: The first argument is a lower-case two or four arguments: The first argument is a lower-case identity
identity identifier and the last argument is a statement block that identifier and the last argument is a statement block that holds
holds detailed identity information in an obligatory order. In case detailed identity information in an obligatory order. In case of
of derived identities there are two tokens inbetween: a single colon derived identities there are two tokens inbetween: a single colon `:'
`:' and the identifier of the parent identity. and the identifier of the parent identity.
See the `identityStatement' rule of the SMIng grammar (Appendix A) See the `identityStatement' rule of the SMIng grammar (Appendix A)
for the formal syntax of the `identity' statement. for the formal syntax of the `identity' statement.
8.1 The identity's status Statement 8.1 The identity's status Statement
The identity's `status' statement, which need not be present, gets The identity's `status' statement, which must be present, gets one
one argument which is used to specify whether this identity argument which is used to specify whether this identity definition is
definition is current or historic. The value `current' means that current or historic. The value `current' means that the definition
the definition is current and valid. The value `obsolete' means the is current and valid. The value `obsolete' means the definition is
definition is obsolete and should not be implemented and/or can be obsolete and should not be implemented and/or can be removed if
removed if previously implemented. While the value `deprecated' previously implemented. While the value `deprecated' also indicates
also indicates an obsolete definition, it permits new/continued an obsolete definition, it permits new/continued implementation in
implementation in order to foster interoperability with order to foster interoperability with older/existing implementations.
older/existing implementations.
Derived identities SHOULD NOT be defined as `current' if their
parent identity is `deprecated' or `obsolete'. Similarly, they
SHOULD NOT be defined as `deprecated' if their parent identity is
`obsolete'. Nevertheless, subsequent revisions of the parent
identity 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 Derived identities SHOULD NOT be defined as `current' if their parent
implied. identity is `deprecated' or `obsolete'. Similarly, they SHOULD NOT
be defined as `deprecated' if their parent identity is `obsolete'.
Nevertheless, subsequent revisions of the parent identity cannot be
avoided, but SHOULD be taken into account in subsequent revisions of
the local module.
8.2 The identity' description Statement 8.2 The identity' description Statement
The identity's `description' statement, which must be present, gets The identity'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 newly defined identity. description of the newly defined identity.
It is RECOMMENDED to include all semantic definitions necessary for It is RECOMMENDED to include all semantic definitions necessary for
implementation, and to embody any information which would otherwise implementation, and to embody any information which would otherwise
be communicated in any commentary annotations associated with this be communicated in any commentary annotations associated with this
identity definition. identity definition.
8.3 The identity's reference Statement 8.3 The identity's reference Statement
The identity's `reference' statement, which need not be present, The identity's `reference' statement, which need not be present, gets
gets one argument which is used to specify a textual cross-reference one argument which is used to specify a textual cross-reference to
to some other document, either another module which defines related some other document, either another module which defines related
identity definitions, or some other document which provides identity definitions, or some other document which provides
additional information relevant to this identity definition. additional information relevant to this identity definition.
8.4 Usage Examples 8.4 Usage Examples
identity null { identity null {
status current;
description description
"An identity used to represent null pointer values."; "An identity used to represent null pointer values.";
}; };
identity snmpTransportDomain { identity snmpTransportDomain {
status current;
description description
"A generic SNMP transport domain identity."; "A generic SNMP transport domain identity.";
}; };
identity snmpUDPDomain : snmpTransportDomain { identity snmpUDPDomain : snmpTransportDomain {
status current;
description description
"The SNMP over UDP transport domain."; "The SNMP over UDP transport domain.";
}; };
9. The class Statement 9. The class Statement
The `class' statement is used to define a new class, that represents The `class' statement is used to define a new class, that represents
a container of related attributes and events (Section 9.1, Section a container of related attributes and events (Section 9.1, Section
9.3) in an object-oriented manner. Thus, a class can be defined 9.3) in an object-oriented manner. Thus, a class can be defined
either from scratch or derived from a parent class. A derived class either from scratch or derived from a parent class. A derived class
inherits all attributes and events of the parent class and can be inherits all attributes and events of the parent class and can be
extended by additional attributes and events. Furthermore, parent extended by additional attributes and events. Furthermore, parent
attributes can be refined by new attributes of the same name that attributes can be refined by new attributes of the same name that are
are more specific in their formal type restrictions or their more specific in their formal type restrictions or their semantics
semantics specified in the attribute description clause. Similarly, specified in the attribute description clause. Similarly, parent
parent events can be refined by new events of the same name that are events can be refined by new events of the same name that are more
more specific in their semantics specified in the event description specific in their semantics specified in the event description
clause. clause.
The `class' statement gets the following two or four arguments: The The `class' statement gets the following two or four arguments: The
first argument is an upper-case class identifier and the last first argument is an upper-case class identifier and the last
argument is a statement block that holds detailed class information argument is a statement block that holds detailed class information
in an obligatory order. In case of derived classes there are two in an obligatory order. In case of derived classes there are two
tokens inbetween: a single colon `:' and the identifier of the tokens inbetween: a single colon `:' and the identifier of the parent
parent class. class.
See the `classStatement' rule of the SMIng grammar (Appendix A) for See the `classStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `class' statement. the formal syntax of the `class' statement.
9.1 The class' attribute Statement 9.1 The class' attribute Statement
The class' `attribute' statement, which can be present zero, one or The class' `attribute' statement, which can be present zero, one or
multiple times, gets three arguments: a type or class name, the multiple times, gets three arguments: a type or class name, the
attribute name, and a statement block that holds detailed attribute attribute name, and a statement block that holds detailed attribute
information in an obligatory order. information in an obligatory order.
9.1.1 The attribute's access Statement 9.1.1 The attribute's access Statement
The attribute's `access' statement must be present for attributes The attribute's `access' statement must be present for attributes
typed by a base type or derived type, and must be absent for typed by a base type or derived type, and must be absent for
attributes typed by a class. It gets one argument which is used to attributes typed by a class. It gets one argument which is used to
specify whether it makes sense to read and/or write an instance of specify whether it makes sense to read and/or write an instance of
the attribute, or to include its value in an event. This is the the attribute, or to include its value in an event. This is the
maximal level of access for the attribute. This maximal level of maximal level of access for the attribute. This maximal level of
access is independent of any administrative authorization policy. access is independent of any administrative authorization policy.
The value `readwrite' indicates that read and write access makes The value `readwrite' indicates that read and write access makes
sense. The value `readonly' indicates that read access makes sense, sense. The value `readonly' indicates that read access makes sense,
but write access is never possible. The value `eventonly' indicates but write access is never possible. The value `eventonly' indicates
an object which is accessible only via an event. an object which is accessible only via an event.
These values are ordered, from least to greatest access level: These values are ordered, from least to greatest access level:
`eventonly', `readonly', `readwrite'. `eventonly', `readonly', `readwrite'.
9.1.2 The attribute's default Statement 9.1.2 The attribute's default Statement
The attribute's `default' statement need not be present for The attribute's `default' statement need not be present for
attributes typed by a base type or derived type, and must be absent attributes typed by a base type or derived type, and must be absent
for attributes typed by a class. It gets one argument which is used for attributes typed by a class. It gets one argument which is used
to specify an acceptable default value for this attribute. A default to specify an acceptable default value for this attribute. A default
value may be used when an attribute instance is created. That is, value may be used when an attribute instance is created. That is,
the value is a "hint" to implementors. the value is a "hint" to implementors.
The value of the `default' statement must, of course, correspond to The value of the `default' statement must, of course, correspond to
the (probably restricted) type specified in the attribute's `type' the (probably restricted) type specified in the attribute's `type'
statement. statement.
The attribute's default value overrides the default value of the The attribute's default value overrides the default value of the
underlying type definition if both are present. underlying type definition if both are present.
9.1.3 The attribute's format Statement 9.1.3 The attribute's format Statement
The attribute's `format' statement need not be present for The attribute's `format' statement need not be present for attributes
attributes typed by a base type or derived type, and must be absent typed by a base type or derived type, and must be absent for
for attributes typed by a class. It gets one argument which is used attributes typed by a class. It gets one argument which is used to
to give a hint as to how the value of an instance of this attribute give a hint as to how the value of an instance of this attribute
might be displayed. See Section 3.12 for a description of format might be displayed. See Section 3.13 for a description of format
specifications. specifications.
The attribute's format specification overrides the format The attribute's format specification overrides the format
specification of the underlying type definition if both are present. specification of the underlying type definition if both are present.
9.1.4 The attribute's units Statement 9.1.4 The attribute's units Statement
The attribute's `units' statement need not be present for attributes The attribute's `units' statement need not be present for attributes
typed by a base type or derived type, and must be absent for typed by a base type or derived type, and must be absent for
attributes typed by a class. It gets one argument which is used to attributes typed by a class. It gets one argument which is used to
specify a textual definition of the units associated with this specify a textual definition of the units associated with this
attribute. attribute.
The attribute's units specification overrides the units The attribute's units specification overrides the units specification
specification of the underlying type definition if both are present. of the underlying type definition if both are present.
The units specification has to be appropriate for values displayed The units specification has to be appropriate for values displayed
according to the attribute's format specification if present. E.g., according to the attribute's format specification if present. E.g.,
if the attribute represents a frequency value of type Unsigned64 if the attribute represents a frequency value of type Unsigned64
measured in thousands of Hertz, the format specification should be measured in thousands of Hertz, the format specification should be
`d-3' and the units specification should be `Hertz' or `Hz'. If the `d-3' and the units specification should be `Hertz' or `Hz'. If the
format specification would be omitted the units specification should format specification would be omitted the units specification should
be `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay be `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay
attention to keep format and units specifications of type and attention to keep format and units specifications of type and
attribute definitions synced. Application implementors MUST NOT attribute definitions synced. Application implementors MUST NOT
implement units specifications without implementing format implement units specifications without implementing format
specifications. specifications.
9.1.5 The attribute's status Statement 9.1.5 The attribute's status Statement
The attribute's `status' statement need not be present for The attribute's `status' statement must be present for attributes
attributes typed by a base type or derived type, and must be absent typed by a base type or derived type, and must be absent for
for attributes typed by a class. It gets one argument which is used attributes typed by a class. It gets one argument which is used to
to specify whether this attribute definition is current or historic. specify whether this attribute definition is current or historic.
The value `current' means that the definition is current and valid. The value `current' means that the definition is current and valid.
The value `obsolete' means the definition is obsolete and should not The value `obsolete' means the definition is obsolete and should not
be implemented and/or can be removed if previously implemented. be implemented and/or can be removed if previously implemented.
While the value `deprecated' also indicates an obsolete definition, While the value `deprecated' also indicates an obsolete definition,
it permits new/continued implementation in order to foster it permits new/continued implementation in order to foster
interoperability with older/existing implementations. interoperability with older/existing implementations.
Attributes SHOULD NOT be defined as `current' if their type or their Attributes SHOULD NOT be defined as `current' if their type or their
containing class is `deprecated' or `obsolete'. Similarly, they containing class is `deprecated' or `obsolete'. Similarly, they
SHOULD NOT be defined as `deprecated' if their type or their SHOULD NOT be defined as `deprecated' if their type or their
containting class is `obsolete'. Nevertheless, subsequent revisions containting class is `obsolete'. Nevertheless, subsequent revisions
of used type definition cannot be avoided, but SHOULD be taken into of used type definition cannot be avoided, but SHOULD be taken into
account in subsequent revisions of the local module. account in subsequent revisions of the local module.
If the `status' statement is omitted the status value `current' is
implied.
9.1.6 The attribute's description Statement 9.1.6 The attribute's description Statement
The attribute's `description' statement, which must be present, gets The attribute'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 this attribute. description of this attribute.
It is RECOMMENDED to include all semantic definitions necessary for It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this attribute. the implementation of this attribute.
9.1.7 The attribute's reference Statement 9.1.7 The attribute's reference Statement
skipping to change at page 36, line 50 skipping to change at page 33, line 22
The attribute's `reference' statement, which need not be present, The attribute'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
attribute definitions, or some other document which provides attribute definitions, or some other document which provides
additional information relevant to this attribute definition. additional information relevant to this attribute definition.
9.2 The class' unique Statement 9.2 The class' unique Statement
The class' `unique' statement, which need not be present, gets one The class' `unique' statement, which need not be present, gets one
argument that specifies a comma-separated list of attributes of this argument that specifies a comma-separated list of attributes of this
class, enclosed in parenthesis. If present, this list of attributes class, enclosed in parenthesis. If present, this list of attributes
makes up a unique identification of all possible instances of this makes up a unique identification of all possible instances of this
class. It can be used as a unique key in underlying protocols. class. It can be used as a unique key in underlying protocols.
If the list is empty the class should be regarded as a scalar class If the list is empty the class should be regarded as a scalar class
with only a single static instance. with only a single static instance.
If the `unique' statement is not present the class is not meant to If the `unique' statement is not present the class is not meant to be
be instantiated directly, but just to be contained in other classes instantiated directly, but just to be contained in other classes or
or to be the parent class of other refining classes. This, it can be to be the parent class of other refining classes.
regarded as something similar to an abstract class.
If present, the attribute list must not contain any attribute more If present, the attribute list MUST NOT contain any attribute more
than once and the attributes should be ordered so that the than once and the attributes should be ordered where appropriate so
attributes that are most significant in most situation appear first. that the attributes that are most significant in most situations
appear first.
9.3 The class' event Statement 9.3 The class' event Statement
The class' `event' statement is used to define an event related to The class' `event' statement is used to define an event related to an
an instance of this class that can occur asynchronously. It gets two instance of this class that can occur asynchronously. It gets two
arguments: a lower-case event identifier and a statement block that arguments: a lower-case event identifier and a statement block that
holds detailed information in an obligatory order. holds detailed information in an obligatory order.
See the `eventStatement' rule of the SMIng grammar (Appendix A) for See the `eventStatement' rule of the SMIng grammar (Appendix A) for
the formal syntax of the `event' statement. the formal syntax of the `event' statement.
9.3.1 The event's status Statement 9.3.1 The event's status Statement
The event's `status' statement, which need not be present, gets one The event's `status' statement, which must be present, gets one
argument which is used to specify whether this event definition is argument which is used to specify whether this event 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.
9.3.2 The event's description Statement 9.3.2 The event's description Statement
The event's `description' statement, which must be present, gets one The event'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 event. this event.
It is RECOMMENDED to include all semantic definitions necessary for It is RECOMMENDED to include all semantic definitions necessary for
the implementation of this event. In particular, it SHOULD be the implementation of this event. In particular, it SHOULD be
documented which instance of the class is associated with an event documented which instance of the class is associated with an event of
of this type. this type.
9.3.3 The event's reference Statement 9.3.3 The event's reference Statement
The event's `reference' statement, which need not be present, gets The event'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
event definitions, or some other document which provides additional event definitions, or some other document which provides additional
information relevant to this event definition. information relevant to this event definition.
9.4 The class' status Statement 9.4 The class' status Statement
The class' `status' statement, which need not be present, gets one The class' `status' statement, which must be present, gets one
argument which is used to specify whether this class definition is argument which is used to specify whether this class 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.
Derived classes SHOULD NOT be defined as `current' if their parent Derived classes SHOULD NOT be defined as `current' if their parent
class is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be class is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be
defined as `deprecated' if their parent class is `obsolete'. defined as `deprecated' if their parent class is `obsolete'.
Nevertheless, subsequent revisions of the parent class cannot be Nevertheless, subsequent revisions of the parent class cannot be
avoided, but SHOULD be taken into account in subsequent revisions of avoided, but SHOULD be taken into account in subsequent revisions of
the local module. the local module.
If the `status' statement is omitted, the status value `current' is
implied.
9.5 The class' description Statement 9.5 The class' description Statement
The class' `description' statement, which must be present, gets one The class' `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 the newly defined class. the newly defined class.
It is RECOMMENDED to include all semantic definitions necessary for It is RECOMMENDED to include all semantic definitions necessary for
implementation, and to embody any information which would otherwise implementation, and to embody any information which would otherwise
be communicated in any commentary annotations associated with this be communicated in any commentary annotations associated with this
class definition. class definition.
9.6 The class's reference Statement 9.6 The class's reference Statement
The class's `reference' statement, which need not be present, gets The class'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
class definitions, or some other document which provides additional class definitions, or some other document which provides additional
information relevant to this class definition. information relevant to this class definition.
9.7 Usage Example 9.7 Usage Example
Consider how an event might be described that signals a status Consider how an event might be described that signals a status change
change of an interface: of an interface:
class Interface { class Interface {
// ... // ...
attribute Gauge32 speed { attribute Gauge32 speed {
access readonly; access readonly;
units "bps"; units "bps";
status current;
description description
"An estimate of the interface's current bandwidth "An estimate of the interface's current bandwidth
in bits per second."; in bits per second.";
}; };
// ... // ...
attribute AdminStatus adminStatus { attribute AdminStatus adminStatus {
access readwrite; access readwrite;
status current;
description description
"The desired state of the interface."; "The desired state of the interface.";
}; };
attribute OperStatus operStatus { attribute OperStatus operStatus {
access readonly; access readonly;
status current;
description description
"The current operational state of the interface."; "The current operational state of the interface.";
}; };
event linkDown { event linkDown {
status current; status current;
description description
"A linkDown event signifies that the ifOperStatus "A linkDown event signifies that the ifOperStatus
attribute for this interface instance is about to attribute for this interface instance is about to
enter the down state from some other state (but not enter the down state from some other state (but not
from the notPresent state). This other state is from the notPresent state). This other state is
indicated by the included value of ifOperStatus."; indicated by the included value of ifOperStatus.";
}; };
status current;
description description
"A physical or logical network interface."; "A physical or logical network interface.";
}; };
10. Extending a Module 10. Extending a Module
As experience is gained with a module, it may be desirable to revise As experience is gained with a module, it may be desirable to revise
that module. However, changes are not allowed if they have any that module. However, changes are not allowed if they have any
potential to cause interoperability problems between an potential to cause interoperability problems between an
implementation using an original specification and an implementation implementation using an original specification and an implementation
using an updated specification(s). using an updated specification(s).
For any change, some statements near the top of the module MUST be For any change, some statements near the top of the module MUST be
updated to include information about the revision: specifically, a updated to include information about the revision: specifically, a
new `revision' statement (Section 5.6) must be included in front of new `revision' statement (Section 5.6) must be included in front of
the `revision' statements. Furthermore, any necessary changes MUST the `revision' statements. Furthermore, any necessary changes MUST
be applied to other statements, including the `organization' and be applied to other statements, including the `organization' and
`contact' statements (Section 5.2, Section 5.3). `contact' statements (Section 5.2, Section 5.3).
Note that any definition contained in a module is available to be Note that any definition contained in a module is available to be
imported by any other module, and is referenced in an `import' imported by any other module, and is referenced in an `import'
statement via the module name. Thus, a module name MUST NOT be statement via the module name. Thus, a module name MUST NOT be
changed. Specifically, the module name (e.g., `FIZBIN' in the changed. Specifically, the module name (e.g., `FIZBIN' in the
example of Section 5.7) MUST NOT be changed when revising a module example of Section 5.7) MUST NOT be changed when revising a module
(except to correct typographical errors), and definitions MUST NOT (except to correct typographical errors), and definitions MUST NOT be
be moved from one module to another. moved from one module to another.
Also note, that obsolete definitions MUST NOT be removed from Also note, that obsolete definitions MUST NOT be removed from modules
modules since their identifiers may still be referenced by other since their identifiers may still be referenced by other modules.
modules.
A definition may be revised in any of the following ways: A definition may be revised in any of the following ways:
o In `typedef' statement blocks, a `type' statement containing an o In `typedef' statement blocks, a `type' statement containing an
`Enumeration' or `Bits' type may have new named numbers added. `Enumeration' or `Bits' type may have new named numbers added.
o In `typedef' statement blocks, the value of a `type' statement o In `typedef' statement blocks, the value of a `type' statement may
may be replaced by another type if the new type is derived be replaced by another type if the new type is derived (directly
(directly or indirectly) from the same base type, has the same or indirectly) from the same base type, has the same set of
set of values, and has identical semantics. values, and has identical semantics.
o In `attribute' statements where the first argument specifies a o In `attribute' statements where the first argument specifies a
class, the class may be replaced by another class if the new class, the class may be replaced by another class if the new class
class is inherited (directly or indirectly) from the base class is inherited (directly or indirectly) from the base class and both
and both classes have identical semantics. classes have identical semantics.
o In `attribute' statements where the first argument specifies a o In `attribute' statements where the first argument specifies a
type, the type may be replaced by another type if the new type is type, the type may be replaced by another type if the new type is
derived (directly or indirectly) from the same base type, has the derived (directly or indirectly) from the same base type, has the
same set of values, and has identical semantics. same set of values, and has identical semantics.
o In any statement block, a `status' statement value of `current' o In any statement block, a `status' statement value of `current'
(or a missing `status' statement) may be revised as `deprecated' may be revised as `deprecated' or `obsolete'. Similarly, a
or `obsolete'. Similarly, a `status' statement value of `status' statement value of `deprecated' may be revised as
`deprecated' may be revised as `obsolete'. When making such a `obsolete'. When making such a change, the `description'
change, the `description' statement SHOULD be updated to explain statement SHOULD be updated to explain the rationale.
the rationale.
o In `typedef' and `attribute' statement blocks, a `default' o In `typedef' and `attribute' statement blocks, a `default'
statement may be added or updated. statement may be added or updated.
o In `typedef' and `attribute' statement blocks, a `units' o In `typedef' and `attribute' statement blocks, a `units' statement
statement may be added. may be added.
o A class may be augmented by adding new attributes. o A class may be augmented by adding new attributes.
o In any statement block, clarifications and additional information o In any statement block, clarifications and additional information
may be included in the `description' statement. may be included in the `description' statement.
o In any statement block, a `reference' statement may be added or o In any statement block, a `reference' statement may be added or
updated. updated.
o Entirely new extensions, types, identities, and classes may be o Entirely new extensions, types, identities, and classes may be
defined, using previously unassigned identifiers. defined, using previously unassigned identifiers.
Otherwise, if the semantics of any previous definition are changed Otherwise, if the semantics of any previous definition are changed
(i.e., if a non-editorial change is made to any definition other (i.e., if a non-editorial change is made to any definition other than
than those specifically allowed above), then this MUST be achieved those specifically allowed above), then this MUST be achieved by a
by a new definition with a new identifier. In case of a class where new definition with a new identifier. In case of a class where the
the semantics of any attributes are changed, the new class can be semantics of any attributes are changed, the new class can be defined
defined by inheritence from the old class and refining the changed by inheritence from the old class and refining the changed
attributes. attributes.
Note that changing the identifier associated with an existing Note that changing the identifier associated with an existing
definition is considered a semantic change, as these strings may be definition is considered a semantic change, as these strings may be
used in an `import' statement. used in an `import' statement.
11. SMIng Language Extensibility 11. SMIng Language Extensibility
While the core SMIng language has a well defined set of statements While the core SMIng language has a well defined set of statements
(Section 5 through Section 9.3) that are used to specify those (Section 5 through Section 9.3) that are used to specify those
aspects of management information commonly regarded as necessary aspects of management information commonly regarded as necessary
without management protocol specific information, there may be without management protocol specific information, there may be
further information, people wish to express. To describe additional further information, people wish to express. To describe additional
information informally in description statements has the information informally in description statements has the disadvantage
disadvantage that this information cannot be parsed by any program. that this information cannot be parsed by any program.
SMIng allows modules to include statements that are unknown to a SMIng allows modules to include statements that are unknown to a
parser but fulfill some core grammar rules (Section 4.2). parser but fulfill some core grammar rules (Section 4.2).
Furthermore, additional statements may be defined by the `extension' Furthermore, additional statements may be defined by the `extension'
statement (Section 6). Extensions can be used in the local module or statement (Section 6). Extensions can be used in the local module or
in other modules, that import the extension. This has some in other modules, that import the extension. This has some
advantages: advantages:
o A parser can differentiate between statements known as extensions o A parser can differentiate between statements known as extensions
and unknown statements. This enables the parser to complain about and unknown statements. This enables the parser to complain about
unknown statements, e.g. due to typos. unknown statements, e.g. due to typos.
o If an extension's definition contains a formal ABNF grammar o If an extension's definition contains a formal ABNF grammar
definition and a parser is able to interpret this ABNF definition and a parser is able to interpret this ABNF definition,
definition, this enables the parser also to complain about wrong this enables the parser also to complain about wrong usage of an
usage of an extension. extension.
o Since, there might be some common need for extensions, there is a o Since, there might be some common need for extensions, there is a
relatively high probability of extension name collisions relatively high probability of extension name collisions
originated by different organizations, as long as there is no originated by different organizations, as long as there is no
standardized extension for that purpose. The requirement to standardized extension for that purpose. The requirement to
explicitly import extension statements allows to distinguish explicitly import extension statements allows to distinguish those
those extensions. extensions.
o The supported extensions of an SMIng implementation, e.g. a SMIng o The supported extensions of an SMIng implementation, e.g. a SMIng
module compiler, can be clearly expressed. module compiler, can be clearly expressed.
The only formal effect of an extension statement definition is to The only formal effect of an extension statement definition is to
declare its existence and its status, and optionally its ABNF declare its existence and its status, and optionally its ABNF
grammar. All additional aspects SHOULD be described in the grammar. All additional aspects SHOULD be described in the
`description' statement: `description' statement:
o The detailed semantics of the new statement SHOULD be described. o The detailed semantics of the new statement SHOULD be described.
o The contexts in which the new statement can be used, SHOULD be o The contexts in which the new statement can be used, SHOULD be
described, e.g., a new statement may be designed to be used only described, e.g., a new statement may be designed to be used only
in the statement block of a module, but not in other nested in the statement block of a module, but not in other nested
statement blocks. Others may be applicable in multiple contexts. statement blocks. Others may be applicable in multiple contexts.
In addition, the point in the sequence of an obligatory order of In addition, the point in the sequence of an obligatory order of
other statements, where the new statement may be inserted, might other statements, where the new statement may be inserted, might
be prescribed. be prescribed.
o The circumstances that make the new statement mandatory or o The circumstances that make the new statement mandatory or
optional SHOULD be described. optional SHOULD be described.
o The syntax of the new statement SHOULD at least be described o The syntax of the new statement SHOULD at least be described
informally, if not supplied formally in an `abnf' statement. informally, if not supplied formally in an `abnf' statement.
o It might be reasonable to give some suggestions under which o It might be reasonable to give some suggestions under which
conditions the implementation of the new statement is adequate conditions the implementation of the new statement is adequate and
and how it could be integrated into existent implementations. how it could be integrated into existent implementations.
Some possible extension applications are: Some possible extension applications are:
o The formal mappings of SMIng definitions into the SNMP ([3]) and o The formal mappings of SMIng definitions into the SNMP ([3]) and
COPS-PR frameworks are defined as SMIng extensions. COPS-PR frameworks are defined as SMIng extensions.
o Inlined annotations to definitions. E.g., a vendor may wish to o Inlined annotations to definitions. E.g., a vendor may wish to
describe additional information to class and attribute describe additional information to class and attribute definitions
definitions in private modules. An example are severity levels of in private modules. An example are severity levels of events in
events in the statement block of an `event' statement. the statement block of an `event' statement.
o Arbitrary annotations to external definitions. E.g., a vendor may o Arbitrary annotations to external definitions. E.g., a vendor may
wish to describe additional information to definitions in a wish to describe additional information to definitions in a
"standard" module. This allows a vendor to implement "standard" "standard" module. This allows a vendor to implement "standard"
modules as well as additional private features, without redundant modules as well as additional private features, without redundant
module definitions, but on top of "standard" module definitions. module definitions, but on top of "standard" module definitions.
12. Security Considerations 12. Security Considerations
This document defines a language with which to write and read This document defines a language with which to write and read
descriptions of management information. The language itself has no descriptions of management information. The language itself has no
security impact on the Internet. security impact on the Internet.
13. Acknowledgements 13. 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 [17] Marshall T. Rose's work on an XML framework for RFC authors [17]
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 Core [1] Strauss, F. and J. Schoenwaelder, "SMIng Core Modules", draft-
Modules", draft-ietf-sming-modules-01.txt, March 2001. ietf-sming-modules-02.txt, July 2001.
[2] Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng Internet [2] Strauss, F. and J. Schoenwaelder, "SMIng Internet Protocol Core
Protocol Core Modules", draft-ietf-sming-inet-modules-01.txt, Modules", draft-ietf-sming-inet-modules-02.txt, July 2001.
March 2001.
[3] Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng [3] Strauss, F. and J. Schoenwaelder, "SMIng Extension for SNMP
Extension for SNMP Mappings", draft-ietf-sming-snmp-01.txt, Mappings", draft-ietf-sming-snmp-02.txt, July 2001.
March 2001.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [4] 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.
[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] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., [8] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
Sahita, R., Smith, A., Reichmeyer, F., "Structure of Policy Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy
Provisioning Information (SPPI)", draft-ietf-rap-sppi-05.txt, Provisioning Information (SPPI)", draft-ietf-rap-sppi-07.txt,
February 2001. May 2001.
[9] Rose, M., McCloghrie, K., "Structure and Identification of [9] 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.
[10] Rose, M., McCloghrie, K., "Concise MIB Definitions", RFC 1212, [10] Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC
STD 16, March 1991. 1212, STD 16, March 1991.
[11] Rose, M., "A Convention for Defining Traps for use with the [11] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991. SNMP", RFC 1215, March 1991.
[12] Crocker, D., Overell, P., "Augmented BNF for Syntax [12] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[13] International Organization for Standardization, "Specification [13] 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.
[14] Harrington, D., Presuhn, R., Wijnen, B., "An Architecture for [14] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2271, January 1999. Describing SNMP Management Frameworks", RFC 2271, January 1999.
[15] Institute of Electrical and Electronics Engineers, "IEEE [15] 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.
[16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
RFC 2279, January 1998. 2279, January 1998.
[17] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June [17] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June
1999. 1999.
Authors' Addresses Authors' Addresses
Frank Strauss Frank Strauss
TU Braunschweig TU Braunschweig
Bueltenweg 74/75 Bueltenweg 74/75
38106 Braunschweig 38106 Braunschweig
skipping to change at page 47, line 40 skipping to change at page 41, line 40
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 ABNF Grammar Appendix A. SMIng ABNF Grammar
The SMIng grammar conforms to the Augmented Backus-Naur Form The SMIng grammar conforms to the Augmented Backus-Naur Form (ABNF)
(ABNF)[12]. [12].
;; ;;
;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234). ;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234).
;; ;;
;; @(#) $Id: sming.abnf,v 1.21 2001/03/02 18:03:13 strauss Exp $ ;; @(#) $Id: sming.abnf,v 1.24 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.
;; ;;
;; ;;
;; This file is WORK IN PROGRESS. ;; This file is WORK IN PROGRESS.
;; ;;
smingFile = optsep *(moduleStatement optsep) smingFile = optsep *(moduleStatement optsep)
;; ;;
;; Statement rules. ;; Statement rules.
skipping to change at page 48, line 44 skipping to change at page 42, line 33
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
1*(revisionStatement stmtsep) 1*(revisionStatement stmtsep)
*(extensionStatement stmtsep) *(extensionStatement stmtsep)
*(typedefStatement stmtsep) *(typedefStatement stmtsep)
*(identityStatement stmtsep) *(identityStatement stmtsep)
*(classStatement stmtsep) *(classStatement stmtsep)
"}" optsep ";" "}" optsep ";"
extensionStatement = extensionKeyword sep lcIdentifier optsep extensionStatement = extensionKeyword sep lcIdentifier optsep
"{" stmtsep "{" stmtsep
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
*1(abnfStatement stmtsep) *1(abnfStatement stmtsep)
"}" optsep ";" "}" optsep ";"
typedefStatement = typedefKeyword sep ucIdentifier optsep typedefStatement = typedefKeyword sep ucIdentifier optsep
"{" stmtsep "{" stmtsep
typedefTypeStatement stmtsep typedefTypeStatement stmtsep
*1(defaultStatement stmtsep) *1(defaultStatement stmtsep)
*1(formatStatement stmtsep) *1(formatStatement stmtsep)
*1(unitsStatement stmtsep) *1(unitsStatement stmtsep)
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
identityStatement = identityKeyword sep lcIdentifier optsep identityStatement = identityKeyword sep lcIdentifier optsep
*1(":" optsep qlcIdentifier optsep) *1(":" optsep qlcIdentifier optsep)
"{" stmtsep "{" stmtsep
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
classStatement = classKeyword sep ucIdentifier optsep classStatement = classKeyword sep ucIdentifier optsep
*1(":" optsep qucIdentifier optsep) *1(":" optsep qucIdentifier optsep)
"{" stmtsep "{" stmtsep
*(attributeStatement stmtsep) *(attributeStatement stmtsep)
*1(uniqueStatement stmtsep) *1(uniqueStatement stmtsep)
*(eventStatement stmtsep) *(eventStatement stmtsep)
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
attributeStatement = attributeKeyword sep attributeStatement = attributeKeyword sep
qucIdentifier sep qucIdentifier sep
lcIdentifier optsep lcIdentifier optsep
"{" stmtsep "{" stmtsep
*1(accessStatement stmtsep) *1(accessStatement stmtsep)
*1(defaultStatement stmtsep) *1(defaultStatement stmtsep)
*1(formatStatement stmtsep) *1(formatStatement stmtsep)
*1(unitsStatement stmtsep) *1(unitsStatement stmtsep)
*1(statusStatement stmtsep) statusStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
uniqueStatement = uniqueKeyword optsep uniqueStatement = uniqueKeyword optsep
"(" optsep qlcIdentifierList "(" optsep qlcIdentifierList
optsep ")" optsep ";" optsep ")" optsep ";"
eventStatement = eventKeyword sep lcIdentifier eventStatement = eventKeyword sep lcIdentifier
optsep "{" stmtsep optsep "{" stmtsep
*1(attributesStatement stmtsep) statusStatement stmtsep
*1(statusStatement stmtsep)
descriptionStatement stmtsep descriptionStatement stmtsep
*1(referenceStatement stmtsep) *1(referenceStatement stmtsep)
"}" optsep ";" "}" optsep ";"
importStatement = importKeyword sep ucIdentifier optsep importStatement = importKeyword sep ucIdentifier optsep
"(" optsep "(" optsep
identifierList optsep identifierList optsep
")" optsep ";" ")" optsep ";"
revisionStatement = revisionKeyword optsep "{" stmtsep revisionStatement = revisionKeyword optsep "{" stmtsep
dateStatement stmtsep dateStatement stmtsep
descriptionStatement stmtsep descriptionStatement stmtsep
skipping to change at page 50, line 41 skipping to change at page 44, line 31
accessStatement = accessKeyword sep access optsep ";" accessStatement = accessKeyword sep access optsep ";"
defaultStatement = defaultKeyword sep anyValue optsep ";" defaultStatement = defaultKeyword sep anyValue optsep ";"
descriptionStatement = descriptionKeyword sep text optsep ";" descriptionStatement = descriptionKeyword sep text optsep ";"
referenceStatement = referenceKeyword sep text optsep ";" referenceStatement = referenceKeyword sep text optsep ";"
abnfStatement = abnfKeyword sep text optsep ";" abnfStatement = abnfKeyword sep text optsep ";"
attributesStatement = attributesKeyword optsep "(" optsep
qlcIdentifierList optsep
")" optsep ";"
;; ;;
;; ;;
;; ;;
refinedBaseType = OctetStringKeyword *1(optsep numberSpec) / refinedBaseType = IdentityKeyword /
ObjectIdentifierKeyword /
OctetStringKeyword *1(optsep numberSpec) /
PointerKeyword *1(optsep pointerSpec) / PointerKeyword *1(optsep pointerSpec) /
Integer32Keyword *1(optsep numberSpec) / Integer32Keyword *1(optsep numberSpec) /
Unsigned32Keyword *1(optsep numberSpec) / Unsigned32Keyword *1(optsep numberSpec) /
Integer64Keyword *1(optsep numberSpec) / Integer64Keyword *1(optsep numberSpec) /
Unsigned64Keyword *1(optsep numberSpec) / Unsigned64Keyword *1(optsep numberSpec) /
Float32Keyword *1(optsep floatSpec) / Float32Keyword *1(optsep floatSpec) /
Float64Keyword *1(optsep floatSpec) / Float64Keyword *1(optsep floatSpec) /
Float128Keyword *1(optsep floatSpec) / Float128Keyword *1(optsep floatSpec) /
EnumerationKeyword EnumerationKeyword
optsep namedSignedNumberSpec / optsep namedSignedNumberSpec /
skipping to change at page 53, line 16 skipping to change at page 47, line 6
format = textSegment format = textSegment
units = textSegment units = textSegment
anyValue = bitsValue / anyValue = bitsValue /
signedNumber / signedNumber /
hexadecimalNumber / hexadecimalNumber /
floatValue / floatValue /
text / text /
qlcIdentifier objectIdentifier
; Note: `qlcIdentifier' includes the ; Note: `objectIdentifier' includes the
; syntax of enumeration labels and ; syntax of enumeration labels and
; identities. ; identities.
; They are not named literally to ; They are not named literally to
; avoid reduce/reduce conflicts when ; avoid reduce/reduce conflicts when
; building LR parsers based on this ; building LR parsers based on this
; grammar. ; grammar.
status = currentKeyword / status = currentKeyword /
deprecatedKeyword / deprecatedKeyword /
obsoleteKeyword obsoleteKeyword
access = eventonlyKeyword / access = eventonlyKeyword /
readonlyKeyword / readonlyKeyword /
readwriteKeyword readwriteKeyword
objectIdentifier = (qlcIdentifier / subid "." subid)
*127("." subid)
subid = decimalNumber
number = hexadecimalNumber / decimalNumber number = hexadecimalNumber / decimalNumber
negativeNumber = "-" decimalNumber negativeNumber = "-" decimalNumber
signedNumber = number / negativeNumber signedNumber = number / negativeNumber
decimalNumber = "0" / (nonZeroDigit *DIGIT) decimalNumber = "0" / (nonZeroDigit *DIGIT)
zeroDecimalNumber = 1*DIGIT zeroDecimalNumber = 1*DIGIT
skipping to change at page 55, line 8 skipping to change at page 49, line 4
%x6F %x6E %x6F %x6E
referenceKeyword = %x72 %x65 %x66 %x65 %x72 %x65 %x6E %x63 %x65 referenceKeyword = %x72 %x65 %x66 %x65 %x72 %x65 %x6E %x63 %x65
extensionKeyword = %x65 %x78 %x74 %x65 %x6E %x73 %x69 %x6F %x6E extensionKeyword = %x65 %x78 %x74 %x65 %x6E %x73 %x69 %x6F %x6E
typedefKeyword = %x74 %x79 %x70 %x65 %x64 %x65 %x66 typedefKeyword = %x74 %x79 %x70 %x65 %x64 %x65 %x66
typeKeyword = %x74 %x79 %x70 %x65 typeKeyword = %x74 %x79 %x70 %x65
identityKeyword = %x69 %x64 %x65 %x6E %x74 %x69 %x74 %x79 identityKeyword = %x69 %x64 %x65 %x6E %x74 %x69 %x74 %x79
classKeyword = %x63 %x6C %x61 %x73 %x73 classKeyword = %x63 %x6C %x61 %x73 %x73
attributeKeyword = %x61 %x74 %x74 %x72 %x69 %x62 %x75 %x74 %x65 attributeKeyword = %x61 %x74 %x74 %x72 %x69 %x62 %x75 %x74 %x65
uniqueKeyword = %x75 %x6E %x69 %x71 %x75 %x65 uniqueKeyword = %x75 %x6E %x69 %x71 %x75 %x65
eventKeyword = %x65 %x76 %x65 %x6E %x74 eventKeyword = %x65 %x76 %x65 %x6E %x74
attributesKeyword = %x61 %x74 %x74 %x72 %x69 %x62 %x75 %x74 %x65
%x73
formatKeyword = %x66 %x6F %x72 %x6D %x61 %x74 formatKeyword = %x66 %x6F %x72 %x6D %x61 %x74
unitsKeyword = %x75 %x6E %x69 %x74 %x73 unitsKeyword = %x75 %x6E %x69 %x74 %x73
statusKeyword = %x73 %x74 %x61 %x74 %x75 %x73 statusKeyword = %x73 %x74 %x61 %x74 %x75 %x73
accessKeyword = %x61 %x63 %x63 %x65 %x73 %x73 accessKeyword = %x61 %x63 %x63 %x65 %x73 %x73
defaultKeyword = %x64 %x65 %x66 %x61 %x75 %x6C %x74 defaultKeyword = %x64 %x65 %x66 %x61 %x75 %x6C %x74
abnfKeyword = %x61 %x62 %x6E %x66 abnfKeyword = %x61 %x62 %x6E %x66
;; Base type keywords. ;; Base type keywords.
OctetStringKeyword = %x4F %x63 %x74 %x65 %x74 %x53 %x74 %x72 %x69 OctetStringKeyword = %x4F %x63 %x74 %x65 %x74 %x53 %x74 %x72 %x69
%x6E %x67 %x6E %x67
PointerKeyword = %x50 %x6F %x69 %x6E %x74 %x65 %x72 PointerKeyword = %x50 %x6F %x69 %x6E %x74 %x65 %x72
IdentityKeyword = %x49 %x64 %x65 %x6E %x74 %x69 %x74 %x79
ObjectIdentifierKeyword = %x4F %x62 %x6A %x65 %x63 %x74 %x49 %x64
%x65 %x6E %x74 %x69 %x66 %x69 %x65 %x72
Integer32Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x33 %x32 Integer32Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x33 %x32
Unsigned32Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x33 Unsigned32Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x33
%x32 %x32
Integer64Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x36 %x34 Integer64Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x36 %x34
Unsigned64Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x36 Unsigned64Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x36
%x34 %x34
Float32Keyword = %x46 %x6C %x6F %x61 %x74 %x33 %x32 Float32Keyword = %x46 %x6C %x6F %x61 %x74 %x33 %x32
Float64Keyword = %x46 %x6C %x6F %x61 %x74 %x36 %x34 Float64Keyword = %x46 %x6C %x6F %x61 %x74 %x36 %x34
Float128Keyword = %x46 %x6C %x6F %x61 %x74 %x31 %x32 %x38 Float128Keyword = %x46 %x6C %x6F %x61 %x74 %x31 %x32 %x38
BitsKeyword = %x42 %x69 %x74 %x73 BitsKeyword = %x42 %x69 %x74 %x73
EnumerationKeyword = %x45 %x6E %x75 %x6D %x65 %x72 %x61 %x74 %x69 EnumerationKeyword = %x45 %x6E %x75 %x6D %x65 %x72 %x61 %x74 %x69
%x6F %x6E %x6F %x6E
;; Status keyword. ;; Status keywords.
currentKeyword = %x63 %x75 %x72 %x72 %x65 %x6E %x74 currentKeyword = %x63 %x75 %x72 %x72 %x65 %x6E %x74
deprecatedKeyword = %x64 %x65 %x70 %x72 %x65 %x63 %x61 %x74 %x65 deprecatedKeyword = %x64 %x65 %x70 %x72 %x65 %x63 %x61 %x74 %x65
%x64 %x64
obsoleteKeyword = %x6F %x62 %x73 %x6F %x6C %x65 %x74 %x65 obsoleteKeyword = %x6F %x62 %x73 %x6F %x6C %x65 %x74 %x65
;; Access keywords. ;; Access keywords.
eventonlyKeyword = %x65 %x76 %x65 %x6E %x74 %x6F %x6E %x6C %x79 eventonlyKeyword = %x65 %x76 %x65 %x6E %x74 %x6F %x6E %x6C %x79
readonlyKeyword = %x72 %x65 %x61 %x64 %x6F %x6E %x6C %x79 readonlyKeyword = %x72 %x65 %x61 %x64 %x6F %x6E %x6C %x79
skipping to change at page 58, line 21 skipping to change at page 51, line 47
(b) specification of a core SMIng module, (b) specification of a core SMIng module,
(c) language extensions for SNMP mappings, (c) language extensions for SNMP mappings,
(d) language extensions for COPS-PR mappings, (d) language extensions for COPS-PR mappings,
(e) maybe, an SMIng guidelines document, (e) maybe, an SMIng guidelines document,
(f) specification of a basic inet modules, that not (f) specification of a basic inet modules, that not
only contain basic definitions but also document only contain basic definitions but also document
the usage SMIng. the usage SMIng.
How Generic Shall the Core Language be? - If we focus strictly on How Generic Shall the Core Language be? - If we focus strictly on
SNMP and COPS-PR, we can build on some common characteristics in SNMP and COPS-PR, we can build on some common characteristics in
these two related worlds, e.g., the concept and common these two related worlds, e.g., the concept and common definitions
definitions of OIDs, and conformance statements. On the other of OIDs, and conformance statements. On the other hand, if we
hand, if we feel closer to OO modeling concepts that should feel closer to OO modeling concepts that should remain applicable
remain applicable also to other environments (AAA/DIAMETER, also to other environments (AAA/DIAMETER, XML-style definitions),
XML-style definitions), more information has to be specified in more information has to be specified in the mappings to those
the mappings to those environments, while the core language environments, while the core language cannot be very expressive.
cannot be very expressive.
OIDs / Pointers / Identities - If we decide for a quite generic OO
model (see issue above), we might want to drop the concept of
OIDs in the core language (currently, we did so). However, we
would need a concept of arbitrary unique identities (as
OBJECT-IDENTITYs in SMIv2) and a base type that allows to point
an attribute to such an identity. Maybe it should be possible to
restrict pointer types to identities derived from a common
identity?
Floating Point Types - Shall we include Float32/64/128 in the base Floating Point Types - Shall we include Float32/64/128 in the base
type system? I guess so. Although their implementation is not a type system? Maybe only Float32/64? If we do, shall we disallow
must. restrictions? See also the requirements document.
Drop REFERENCE Clauses - Since REFERENCE clauses have no specific
syntax their information can be placed in DESCRIPTION clauses.
Events / NOTIFICATIONs - SMIv2 NOTIFICATIONs contain objects. How Events / NOTIFICATIONs - SMIv2 NOTIFICATIONs contain objects. How
about SMIng? Assume, the clause is named `event'. Shall events about SMIng? Assume, the clause is named `event'. Shall events
carry a set of attributes? How about those attributes identifying carry a set of attributes? How about those attributes identifying
an instance of a class? Currently, events are assiciated with a an instance of a class? Currently, events are assiciated with a
class. What atttributes are carried with an event is subject to class. What atttributes are carried with an event is subject to
the protocol mapping. the protocol mapping.
Display Formats - Should display hints be usable in a reversed way? Display Formats - Should display hints be usable in a reversed way?
Check all variants carefully. Is the optional repeat indicator Check all variants carefully. Is the optional repeat indicator
`*' necessary? Would `u' for unsigned integers be useful? `*' necessary? Would `u' for unsigned integers be useful?
Discriminated Unions - How to specify unions and their Discriminated Unions - How to specify unions and their
discriminators? `typemap' statement? What are the specific discriminators? `typemap' statement? What are the specific
requirements? requirements? See also the requirements document.
Typedefs in Classes - Allow typedefs in the namespace of a class?
What would be the consequences for their names when converted to
a flattened namespace?
Default Status - Change the default status from `current' to
`current, or in case of derived type or class definitions, the
status level of the parent definition'.
How To Read - Add a section on how to read this set of documents. How To Read - Add a section on how to read this set of documents.
Annotations - Make annotations a core feature of SMIng? They are Annotations - Make annotations a core feature of SMIng? They are
used to add information to an existent definition in an external used to add information to an existent definition in an external
module, e.g., a vendor or user can add specific severity level module, e.g., a vendor or user can add specific severity level
information to standard event definitions. information to standard event definitions.
Glossary - Add/Update the glossary of terms. Glossary - Add/Update the glossary of terms.
Module Naming Scheme - Propose well known module name suffixes: Module Naming Scheme - Propose well known module name suffixes: `-
`-MIB' for SNMP mapping modules? `-PIB' for COPS-PR mapping MIB' for SNMP mapping modules? `-PIB' for COPS-PR mapping modules?
modules? `-EXT' for modules that define extensions (e.g. snmp)? `-EXT' for modules that define extensions (e.g. snmp)? no
no extension for modules that define general classes and types? extension for modules that define general classes and types? This
should go to the Guidelines document.
`Extending A Module' - Carefully adjust the rules, e.g., `new named `Extending A Module' - Carefully adjust the rules, e.g., `new named
numbers may be added to enumeration types' is in contradiction numbers may be added to enumeration types' is in contradiction
with `attributes may get a new type only if the set of values with `attributes may get a new type only if the set of values
remains equal'. remains equal'.
Pointers - Do we need a Pointer base type? How can assiciations be
represented? Compare to SPPI PIB-REFERENCES and PIB-TAG. Use
pointers within the actual classes or additional
`assiciation-classes' to express relations/associations? If we
use `Pointer', how about: `The Pointer base type represents an
arbitrary reference to a class instance, or an attribute of a
class instance. Thus, values of pointers cannot appear in a
module. The Pointer base type cannot be restricted.'
Methods - Is there a need for methods? If yes, denote just
signatures and semantics informally?
ABNF Statement - Is the `abnf' statement really meaningful? Someone ABNF Statement - Is the `abnf' statement really meaningful? Someone
stated that it could be abused? stated that it could be abused.
7-bit ASCII texts - Should we allow more than plain ascii in texts 7-bit ASCII texts - See requirements.
like descriptions and references?
Module Namespaces - Should we introduce domain-based namespaces for Module Namespaces - Should we introduce domain-based namespaces for
module names? E.g., DISMAN-SCRIPT-MIB.ietf.org? Mapping to module names? E.g., DISMAN-SCRIPT-MIB.ietf.org? Mapping to
SMIv2/SPPI module names? Which parts are case-sensitive? SMIv2/SPPI module names? Which parts are case-sensitive? Separator
Separator char between module name and domain name (@/.)? Or char between module name and domain name (@/.)? Or should we
should we enforce organization prefixes (also for the IETF), like enforce organization prefixes (also for the IETF), like IETF-
IETF-DISMAN-SCRIPT-MIB? DISMAN-SCRIPT-MIB?
Learn from ODL, XML, ODBMS - Look at the ODL proposal from TINAC. Learn from ODL, XML, ODBMS - Look at the ODL proposal from TINAC.
Look at the XML schema work from W3C. Look at the ODBMS work. Look at the XML schema work from W3C. Look at the ODBMS work.
Inheritence - Inheritence is a powerful technique in software Inheritence - Inheritence is a powerful technique in software
development. But is it really what we want to have in management development. But is it really what we want to have in management
data modeling? If it is not easy to find good examples for data modeling? If it is not easy to find good examples for
inheritence, can we expect that people will know how to use it? inheritence, can we expect that people will know how to use it? Or
Or would it be more likely that it will be misused? Maybe, would it be more likely that it will be misused? Maybe,
containment/discriminated unions are what we really need. containment/discriminated unions are what we really need.
Examples for Primary goals: MIBs/PIBs - Keep in mind that the Examples for Primary goals: MIBs/PIBs - Keep in mind that the
primary goal is to derive modules for use with SNMP and COPS-PR primary goal is to derive modules for use with SNMP and COPS-PR
from common definitions. If we cannot easily give good examples, from common definitions. If we cannot easily give good examples,
we have failed. we have failed.
Classes or Interfaces - Are classes really classes or are they more Classes or Interfaces - Are classes really classes or are they more
interfaces? [XXX] interfaces?
Reusable event definitions - Currently events are defined within a Reusable event definitions - Currently events are defined within a
class. Do we need to be able to reuse event definitions in class. Do we need to be able to reuse event definitions in
multiple classes? This potentially requires to give events their multiple classes? This potentially requires to give events their
own names, independent of any class definitions. Or is it own names, independent of any class definitions. Or is it
sufficient to use inheritance/containment to handle 99 % of the sufficient to use inheritance/containment to handle 99 % of the
cases? cases?
Extensions - Optionally require the understanding of imported Extensions - Optionally require the understanding of imported
extensions (similar to the marvelous diameter M bit ;-) [XXX] extensions (similar to the marvelous diameter M bit ;-)
Extension Context - Do we need a mechanism to allow an extension to Extension Context - Do we need a mechanism to allow an extension to
specify the context in which it can be used (the containing specify the context in which it can be used (the containing
statement block in the position within this block)? statement block in the position within this block)?
`Static' Definitions - Is it useful to make specific definitions `Static' Definitions - Is it useful to make specific definitions
non-exported (like `static' in C)? Or would it be useful to make non-exported (like `static' in C)? Or would it be useful to make
only those definitions be exported that are explicitly marked only those definitions be exported that are explicitly marked
(`public')? (`public')?
Something like SPPI SUBJECT-CATEGORIES - Add a mechanism to specify
the targeted management protocol(s), similar to SPPI subject
categories.
More Formal Restrictions? - Do we need further formal restrictions More Formal Restrictions? - Do we need further formal restrictions
on type definitions, e.g. subtyping not allowed on TimeTicks, on type definitions, e.g. subtyping not allowed on TimeTicks,
max-access read-only on Counters, no default values on Counters? max-access read-only on Counters, no default values on Counters?
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. 280 change blocks. 
734 lines changed or deleted 700 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/