--- xxx.old Wed Oct 29 17:23:48 2003 +++ xxx.new Wed Oct 29 17:23:48 2003 @@ -1,19 +1,19 @@ Network Working Group F. Strauss Internet-Draft TU Braunschweig -Expires: March 19, 2004 J. Schoenwaelder +Expires: April 28, 2004 J. Schoenwaelder International University Bremen - September 19, 2003 + October 29, 2003 SMIng - Next Generation Structure of Management Information - draft-irtf-nmrg-sming-05 + draft-irtf-nmrg-sming-06 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -22,48 +22,50 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 19, 2004. + This Internet-Draft will expire on April 28, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract - This memo presents a data definition language for the specification - of various kinds of management information. It is independent of - management protocols and applications. Protocol mappings are defined - as extensions to this language in separate memos. The language - builds on experiences gained with the SMIv2 and its derivate SPPI. + This memo defines the base SMIng (Structure of Management + Information, Next Generation) language. SMIng is a data definition + language that provides a protocol-independent representation for + management information. A companion document [RFCxxx2] defines a + core module that supplies common SMIng definitions. Separate RFCs + define mappings of SMIng to specific management protocols, including + SNMP [RFCxxx3]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 The History of SMIng . . . . . . . . . . . . . . . . . . . . 5 1.2 Terms of Requirement Levels . . . . . . . . . . . . . . . . 5 2. SMIng Data Modelling . . . . . . . . . . . . . . . . . . . . 5 - 2.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Base Types and Derived Types . . . . . . . . . . . . . . . . 8 3.1 OctetString . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.3 Object Identifier . . . . . . . . . . . . . . . . . . . . . 10 + 3.3 ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . . 10 3.4 Integer32 . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.5 Integer64 . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.6 Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.5 Integer64 . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.6 Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.7 Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.8 Float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.9 Float64 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.10 Float128 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.11 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . 17 3.12 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.13 Display Formats . . . . . . . . . . . . . . . . . . . . . . 19 4. The SMIng File Structure . . . . . . . . . . . . . . . . . . 21 4.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2 Textual Data . . . . . . . . . . . . . . . . . . . . . . . . 21 @@ -72,70 +74,70 @@ 5.1 The module's import Statement . . . . . . . . . . . . . . . 23 5.2 The module's organization Statement . . . . . . . . . . . . 24 5.3 The module's contact Statement . . . . . . . . . . . . . . . 24 5.4 The module's description Statement . . . . . . . . . . . . . 24 5.5 The module's reference Statement . . . . . . . . . . . . . . 24 5.6 The module's revision Statement . . . . . . . . . . . . . . 24 5.6.1 The revision's date Statement . . . . . . . . . . . . . . . 24 5.6.2 The revision's description Statement . . . . . . . . . . . . 25 5.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 25 6. The extension Statement . . . . . . . . . . . . . . . . . . 26 - 6.1 The extension's status Statement . . . . . . . . . . . . . . 26 - 6.2 The extension's description Statement . . . . . . . . . . . 26 - 6.3 The extension's reference Statement . . . . . . . . . . . . 26 + 6.1 The extension's status Statement . . . . . . . . . . . . . . 27 + 6.2 The extension's description Statement . . . . . . . . . . . 27 + 6.3 The extension's reference Statement . . . . . . . . . . . . 27 6.4 The extension's abnf Statement . . . . . . . . . . . . . . . 27 - 6.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 27 - 7. The typedef Statement . . . . . . . . . . . . . . . . . . . 27 - 7.1 The typedef's type Statement . . . . . . . . . . . . . . . . 27 + 6.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 28 + 7. The typedef Statement . . . . . . . . . . . . . . . . . . . 28 + 7.1 The typedef's type Statement . . . . . . . . . . . . . . . . 28 7.2 The typedef's default Statement . . . . . . . . . . . . . . 28 - 7.3 The typedef's format Statement . . . . . . . . . . . . . . . 28 - 7.4 The typedef's units Statement . . . . . . . . . . . . . . . 28 + 7.3 The typedef's format Statement . . . . . . . . . . . . . . . 29 + 7.4 The typedef's units Statement . . . . . . . . . . . . . . . 29 7.5 The typedef's status Statement . . . . . . . . . . . . . . . 29 - 7.6 The typedef's description Statement . . . . . . . . . . . . 29 + 7.6 The typedef's description Statement . . . . . . . . . . . . 30 - 7.7 The typedef's reference Statement . . . . . . . . . . . . . 29 + 7.7 The typedef's reference Statement . . . . . . . . . . . . . 30 7.8 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 30 - 8. The identity Statement . . . . . . . . . . . . . . . . . . . 30 + 8. The identity Statement . . . . . . . . . . . . . . . . . . . 31 8.1 The identity's parent Statement . . . . . . . . . . . . . . 31 - 8.2 The identity's status Statement . . . . . . . . . . . . . . 31 - 8.3 The identity' description Statement . . . . . . . . . . . . 31 - 8.4 The identity's reference Statement . . . . . . . . . . . . . 31 - 8.5 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 32 - 9. The class Statement . . . . . . . . . . . . . . . . . . . . 32 - 9.1 The class' extends Statement . . . . . . . . . . . . . . . . 32 + 8.2 The identity's status Statement . . . . . . . . . . . . . . 32 + 8.3 The identity' description Statement . . . . . . . . . . . . 32 + 8.4 The identity's reference Statement . . . . . . . . . . . . . 32 + 8.5 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 33 + 9. The class Statement . . . . . . . . . . . . . . . . . . . . 33 + 9.1 The class' extends Statement . . . . . . . . . . . . . . . . 33 9.2 The class' attribute Statement . . . . . . . . . . . . . . . 33 - 9.2.1 The attribute's type Statement . . . . . . . . . . . . . . . 33 - 9.2.2 The attribute's access Statement . . . . . . . . . . . . . . 33 - 9.2.3 The attribute's default Statement . . . . . . . . . . . . . 33 + 9.2.1 The attribute's type Statement . . . . . . . . . . . . . . . 34 + 9.2.2 The attribute's access Statement . . . . . . . . . . . . . . 34 + 9.2.3 The attribute's default Statement . . . . . . . . . . . . . 34 9.2.4 The attribute's format Statement . . . . . . . . . . . . . . 34 - 9.2.5 The attribute's units Statement . . . . . . . . . . . . . . 34 - 9.2.6 The attribute's status Statement . . . . . . . . . . . . . . 34 - 9.2.7 The attribute's description Statement . . . . . . . . . . . 35 - 9.2.8 The attribute's reference Statement . . . . . . . . . . . . 35 - 9.3 The class' unique Statement . . . . . . . . . . . . . . . . 35 - 9.4 The class' event Statement . . . . . . . . . . . . . . . . . 35 - 9.4.1 The event's status Statement . . . . . . . . . . . . . . . . 36 - 9.4.2 The event's description Statement . . . . . . . . . . . . . 36 - 9.4.3 The event's reference Statement . . . . . . . . . . . . . . 36 - 9.5 The class' status Statement . . . . . . . . . . . . . . . . 36 - 9.6 The class' description Statement . . . . . . . . . . . . . . 37 - 9.7 The class's reference Statement . . . . . . . . . . . . . . 37 - 9.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 37 - 10. Extending a Module . . . . . . . . . . . . . . . . . . . . . 38 - 11. SMIng Language Extensibility . . . . . . . . . . . . . . . . 40 - 12. Security Considerations . . . . . . . . . . . . . . . . . . 41 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 - Normative References . . . . . . . . . . . . . . . . . . . . 42 - Informative References . . . . . . . . . . . . . . . . . . . 42 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 43 - A. SMIng ABNF Grammar . . . . . . . . . . . . . . . . . . . . . 44 - Intellectual Property and Copyright Statements . . . . . . . 54 + 9.2.5 The attribute's units Statement . . . . . . . . . . . . . . 35 + 9.2.6 The attribute's status Statement . . . . . . . . . . . . . . 35 + 9.2.7 The attribute's description Statement . . . . . . . . . . . 36 + 9.2.8 The attribute's reference Statement . . . . . . . . . . . . 36 + 9.3 The class' unique Statement . . . . . . . . . . . . . . . . 36 + 9.4 The class' event Statement . . . . . . . . . . . . . . . . . 36 + 9.4.1 The event's status Statement . . . . . . . . . . . . . . . . 37 + 9.4.2 The event's description Statement . . . . . . . . . . . . . 37 + 9.4.3 The event's reference Statement . . . . . . . . . . . . . . 37 + 9.5 The class' status Statement . . . . . . . . . . . . . . . . 37 + 9.6 The class' description Statement . . . . . . . . . . . . . . 38 + 9.7 The class's reference Statement . . . . . . . . . . . . . . 38 + 9.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 38 + 10. Extending a Module . . . . . . . . . . . . . . . . . . . . . 39 + 11. SMIng Language Extensibility . . . . . . . . . . . . . . . . 41 + 12. Security Considerations . . . . . . . . . . . . . . . . . . 42 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 + Normative References . . . . . . . . . . . . . . . . . . . . 43 + Informative References . . . . . . . . . . . . . . . . . . . 43 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 + A. SMIng ABNF Grammar . . . . . . . . . . . . . . . . . . . . . 45 + Intellectual Property and Copyright Statements . . . . . . . 55 1. Introduction In traditional management systems management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written conforming to a specification language, the Structure of Management Information (SMI). There are different versions of the SMI. The SMI version 1 (SMIv1) is defined in [RFC1155], [RFC1212], @@ -153,84 +155,87 @@ The SMIv1 and the SMIv2 are bound to the Simple Network Management Protocol (SNMP) while the the SPPI is bound to the Common Open Policy Service Provisioning (COPS-PR) protocol. Even though the languages have common rules, it is hard to use common data definitions with both protocols. It is the purpose of this document to define a common data definition language, named SMIng, that allows to formally specify data models independent of specific protocols and applications. Companion documents contain - o core modules that supply common SMIng definitions [Modules], + o core modules that supply common SMIng definitions [RFCxxx2], o an SMIng language extension to define SNMP specific mappings of - SMIng definitions in a way compatible to SMIv2 MIBs [SNMP], and + SMIng definitions in a way compatible to SMIv2 MIBs [RFCxxx3]. Additional language extensions may be added in the future, e.g. to define COPS-PR specific mappings of SMIng definition in a way compatible to SPPI PIBs. Section 2 gives an overview of the basic concepts of data modelling using SMIng while the subsequent sections present the concepts of the SMIng language in detail: the base types, the SMIng file structure, and all SMIng core statements. The remainder of the document describes extensibility features of the language and rules to follow when changes are applied to a module. Appendix A contains the grammar of SMIng in ABNF [RFC2234] notation. 1.1 The History of SMIng SMIng started in 1999 as a research project to address some drawbacks of SMIv2, the current data modelling language for management information bases, primarily its partial dependence on ASN.1 and a - number of exceptional rules that turned out to be problematic. In + number of exception rules that turned out to be problematic. In 2000, the work was handed over to the IRTF Network Management Research Group where it was significantly detailed. Since the work of the RAP Working Group on COPS-PR and SPPI emerged in 1999/2000, SMIng was split into two parts: a core data definition language (defined in this document) and protocol mappings to allow the application of core defintions through (potentially) multiple management protocols. The replacement of SMIv2 and SPPI by a single merged data definition language was also a primary goal of the IETF SMING Working Group that was chartered at the end of 2000. The requirements for a new data definition language were discussed several times within the IETF SMING Working Group and changed - significantly over time [RFC3216], so that another proposal, named - SMI Data Structures (SMI-DS) was presented to the Working Group. In - the end none of the two proposals found enough consensus and support - and the attempt to merge the existing concepts did not succeed, so - that the Working Group was closed down in April 2003. - - In order to record the NMRG work on SMIng, this memo and the - accompanying memos on the SNMP protocol mapping [SNMP] and on core - SMIng modules [Modules] have been published for informational - purpose. - - Note that throughout these three documents the term "SMIng" refers to - the specific data modelling language that is specified in this - document, whereas the term "SMING" refers to the general effort - within the IETF Working Group to define a new management data - definition language as an SMIv2 successor and probably an SPPI - merger, for which "SMIng" and "SMI-DS" were two specific proposals. + significantly over time [RFC3216], so that another proposal (in + addition to SMIng), named SMI Data Structures (SMI-DS) was presented + to the Working Group. In the end neither of the two proposals found + enough consensus and support and the attempt to merge the existing + concepts did not succeed, so that the Working Group was closed down + in April 2003. + + In order to record the work of the NMRG (Network Management Research + Group) on SMIng, this memo and the accompanying memos on the SNMP + protocol mapping [RFCxxx3] and on core SMIng modules [RFCxxx2] have + been published for informational purpose. + + Note that throughout the present document and its two companions + [RFCxxx3], [RFCxxx2] the term "SMIng" refers to the specific data + modelling language that is specified in this document, whereas the + term "SMING" refers to the general effort within the IETF Working + Group to define a new management data definition language as an SMIv2 + successor and probably an SPPI merger, for which "SMIng" and "SMI-DS" + were two specific proposals. 1.2 Terms of Requirement Levels The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. SMIng Data Modelling SMIng is a language designed to specify management information in a structured way readable to computer programs, e.g. MIB compilers, as + well as to human readers. Management information is modeled in classes. Classes can be defined from scratch or by derivation from a parent class. Derivation from multiple parent classes is not possible. The concept of classes is described in Section 9. 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 type, or another class. The concept of attributes is described in @@ -251,37 +256,37 @@ o the definition of events, o the definition of derived types, o the definition of arbitrary untyped identities serving as values of pointers, o the definition of SMIng extensions to allow the local module or other modules to specify information beyond the scope of the base SMIng in a machine readable notation. Some extensions for the - application of SMIng in the SNMP framework are defined in [SNMP], + application of SMIng in the SNMP framework are defined in + [RFCxxx3], o the definition of information beyond the scope of the base SMIng statements, based on locally defined or imported SMIng extensions. Each module is identified by an upper-case identifier. The names of all standard modules must be unique (but different versions of the same module should have the same name). Developers of enterprise modules are encouraged to choose names for their modules that will have a low probability of colliding with standard or other enterprise modules, e.g. by using the enterprise or organization name as a prefix. 2.1 Identifiers Identifiers are used to identify different kinds of SMIng items by - name. Each identifier is valid in a namespace which depends on the type of the SMIng item being defined: o The global namespace contains all module identifiers. o Each module defines a new namespace. A module's namespace may contain definitions of extension identifiers, derived type identifiers, identity identifiers, and class identifiers. Furthermore, a module may import identifiers of these kinds from other modules. All these identifiers are also visible within all @@ -316,42 +321,41 @@ definition MUST sequentially precede the reference. Thus, there MUST NOT be any forward references. To reference an item, that is defined in an external module it MUST be imported (Section 5.1). Identifiers that are neither defined nor imported MUST NOT be visible in the local module. When identifiers from external modules are referenced, there is the possibility of name collisions. As such, if different items with the same identifier are imported or if imported identifiers collide with - identifiers of locally defined items, then this ambiguity is resolved by prefixing those identifiers with the names of their modules and the namespace operator `::', i.e. `Module::item'. Of course, this notation can be used to refer to identifiers even when there is no name collision. Note that SMIng core language keywords MUST NOT be imported. See the `...Keyword' rules of the SMIng ABNF grammar in Appendix A for a list of those keywords. 3. Base Types and Derived Types SMIng has a set of base types, similar to those of many programming languages, but with some differences due to special requirements from the management information model. Additional types may be defined, derived from those base types or from other derived types. Derived types may use subtyping to formally restrict the set of possible values. An initial set of commonly used derived types is defined in the SMIng standard module - NMRG-SMING [Modules]. + NMRG-SMING [RFCxxx2]. The different base types and their derived types allow different kinds of subtyping, namely size restrictions of octet strings (Section 3.1), range restrictions of numeric types (Section 3.4 through Section 3.10), restricted pointer types (Section 3.2), and restrictions of the sets of named numbers for enumeration types (Section 3.11) and bit sets (Section 3.12). 3.1 OctetString @@ -362,24 +366,24 @@ sizes in excess of 255 octets. Values of octet strings may be denoted as textual data enclosed in double quotes or as arbitrary binary data denoted as a `0x'-prefixed hexadecimal value of an even number of at least two hexadecimal digits, where each pair of hexadecimal digits represents a single octet. Letters in hexadecimal values MAY be upper-case but lower-case characters are RECOMMENDED. Textual data may contain any number (possibly zero) of any 7-bit displayable ASCII characters, including tab characters, spaces and line terminator characters (nl + or cr & nl). Some characters require a special encoding (see Section 4.2). Textual data may span multiple lines, where each subsequent line prefix containing only white space up to the column where the - first line's data starts SHOULD be skipped by parsers for a better text formatting. When defining a type derived (directly or indirectly) from the OctetString base type, the size in octets may be restricted by appending a list of size ranges or explicit size values, separated by pipe `|' characters and the whole list enclosed in parenthesis. A size range consists of a lower bound, two consecutive dots `..' and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number @@ -410,39 +414,39 @@ OctetString (-1 | 1) // illegal negative size OctetString (5 | 0) // illegal ordering OctetString (1 | 1..10) // illegal overlapping 3.2 Pointer The Pointer base type represents values that reference class instances, attributes of class instances, or arbitrary 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 - Pointer base type, the values may be restricted to a specific class, attribute or identity and all (directly or indirectly) derived items thereof by appending the identifier of the appropriate construct enclosed in parenthesis. Value Examples: null // legal identity name snmpUDPDomain // legal identity name Restriction Examples: Pointer (snmpTransportDomain) // legal restriction -3.3 Object Identifier +3.3 ObjectIdentifier The ObjectIdentifier base type represents administratively assigned 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 @@ -592,32 +596,32 @@ Unsigned32 (5..10 | 2..3) // illegal ordering Unsigned32 (4..8 | 5..10) // illegal overlapping 3.7 Unsigned64 The Unsigned64 base type represents positive integer values between 0 and 2^64-1 (18446744073709551615). Values of type Unsigned64 may be denoted as decimal or hexadecimal numbers. Decimal numbers other than zero MUST NOT have leading zero + digits. Hexadecimal numbers are prefixed by `0x' and MUST have an even number of hexadecimal digits, where letters MAY be upper-case but lower-case characters are RECOMMENDED. When defining a type derived (directly or indirectly) from the Unsigned64 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters and the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..' and an upper bound. Each value can be given in decimal or `0x'-prefixed hexadecimal notation. Hexadecimal numbers must have an even number - 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 restriction is applied to an already restricted type the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. Value Examples: @@ -640,20 +644,21 @@ optional exponent as known from many programming languages. See the grammar rule `floatValue' of Appendix A for the detailed syntax. Special values are `snan' (signaling Not-a-Number), `qnan' (quiet Not-a-Number), `neginf' (negative infinity), and `posinf' (positive infinity). Note that -0.0 and +0.0 are different floating point values. 0.0 is equal to +0.0. When defining a type derived (directly or indirectly) from the Float32 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' + characters and the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..' and an upper bound. If multiple values or ranges are given they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. The special values `snan', `qnan', `neginf', and `posinf' must be explicitly listed in restrictions if they shall be included, where `snan' and @@ -687,33 +692,33 @@ Values of type Float64 may be denoted as a decimal fraction with an optional exponent as known from many programming languages. See the grammar rule `floatValue' of Appendix A for the detailed syntax. Special values are `snan' (signaling Not-a-Number), `qnan' (quiet Not-a-Number), `neginf' (negative infinity), and `posinf' (positive infinity). Note that -0.0 and +0.0 are different floating point values. 0.0 is equal to +0.0. When defining a type derived (directly or indirectly) from the + Float64 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters and the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..' and an upper bound. If multiple values or ranges are given they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. The special values `snan', `qnan', `neginf', and `posinf' must be explicitly listed in restrictions if they shall be included, where `snan' and - `qnan' cannot be used in ranges. Note that encoding is not subject to this specification. It has to be described by protocols that transport objects of type Float64. Note also that most floating point encodings disallow the representation of many values that can be written as decimal fractions as used in SMIng for human readability. Therefore, explicit values in floating point type restrictions should be handled with care. @@ -747,21 +752,20 @@ Float128 base type, the set of possible values may be restricted by appending a list of ranges or explicit values, separated by pipe `|' characters and the whole list enclosed in parenthesis. A range consists of a lower bound, two consecutive dots `..' and an upper bound. If multiple values or ranges are given they all MUST be disjoint and MUST be in ascending order. If a value restriction is applied to an already restricted type the new restriction MUST be equal or more limiting, that is raising the lower bounds, reducing the upper bounds, removing explicit values or ranges, or splitting ranges into multiple ranges with intermediate gaps. The special - values `snan', `qnan', `neginf', and `posinf' must be explicitly listed in restrictions if they shall be included, where `snan' and `qnan' cannot be used in ranges. Note that encoding is not subject to this specification. It has to be described by protocols that transport objects of type Float128. Note also that most floating point encodings disallow the representation of many values that can be written as decimal fractions as used in SMIng for human readability. Therefore, explicit values in floating point type restrictions should be handled @@ -784,32 +788,32 @@ The Enumeration base type represents values from a set of integers in the range between -2^31 (-2147483648) and 2^31-1 (2147483647), where each value has an assigned name. The list of those named numbers has to be comma-separated, enclosed in parenthesis and appended to the `Enumeration' keyword. Each named number is denoted by its lower-case identifier followed by the assigned integer value, denoted as a decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis. Hexadecimal numbers must have an even number of at least two digits. Every name and every number in an enumeration type + MUST be unique. It is RECOMMENDED that values are positive and start at 1 and be numbered contiguously. All named numbers MUST be given in ascending order. Values of enumeration types may be denoted as decimal or `0x'-prefixed hexadecimal numbers or preferably as their assigned names. Hexadecimal numbers must have an even number of at least two digits. When types are derived (directly or indirectly) from an enumeration type, the set of named numbers may be equal or restricted by removing - one or more named numbers. But no named numbers may be added or changed regarding its name, value, or both. Type and Value Examples: Enumeration (up(1), down(2), testing(3)) Enumeration (down(2), up(1)) // illegal order 0 // legal (though not recommended) value up // legal value given by name @@ -832,32 +836,32 @@ Values of bits types may be denoted as a comma-separated list of decimal or `0x'-prefixed hexadecimal numbers or preferably their assigned names enclosed in parenthesis. Hexadecimal numbers must 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 listed in ascending order. When defining a type derived (directly or indirectly) from a bits type, the set of named numbers may be restricted by removing one or + more named numbers. But no named numbers may be added or changed regarding its name, value, or both. Type and Value Examples: Bits (readable(0), writeable(1), executable(2)) Bits (writeable(1), readable(0) // illegal order () // legal empty value (readable, writeable, 2) // legal value (0, readable, executable) // illegal, readable(0) appears twice - (writeable, 4) // illegal, element 4 out of range 3.13 Display Formats Attribute definitions and type definitions allow the specification of a format to be used, when a value of that attribute or an attribute of that type is displayed. Format specifications are represented as textual data. When the attribute or type has an underlying base type of Integer32, @@ -880,32 +884,32 @@ value and producing the next zero or more characters to be displayed. The octets within the value are processed in order of significance, most significant first. The five parts of a octet-format specification are: 1. the (optional) repeat indicator; if present, this part is a `*', and indicates that the current octet of the value is to be used as the repeat count. The repeat count is an unsigned integer (which may be zero) which specifies how many times the remainder + of this octet-format specification should be successively applied. If the repeat indicator is not present, the repeat count is one. 2. the octet length: one or more decimal digits specifying the number of octets of the value to be used and formatted by this octet-specification. Note that the octet length can be zero. If less than this number of octets remain in the value, then the lesser number of octets are used. 3. the display format, either: `x' for hexadecimal, `d' for decimal, - `o' for octal, `a' for ASCII, or `t' for UTF-8 [RFC2279]. If the octet length part is greater than one, and the display format part refers to a numeric format, then network byte-ordering (big-endian encoding) is used interpreting the octets in the value. The octets processed by the `t' display format do not necessarily form an integral number of UTF-8 characters. Trailing octets which do not form a valid UTF-8 encoded character are discarded. 4. the (optional) display separator character; if present, this part @@ -928,67 +932,71 @@ character is suppressed if it would occur as the last character of the display. If the octets of the value are exhausted before all the octet format specification have been used, then the excess specifications are ignored. If additional octets remain in the value after interpreting all the octet format specifications, then the last octet format specification is re-interpreted to process the additional octets, until no octets remain in the value. - Note that for some types no format specifications are defined and - SHOULD be omitted. Implementations MUST ignore format specifications - they cannot interpret. Also note that the SMIng grammar (Appendix A) - does not specify the syntax of format specifications. + Note that for some types no format specifications are defined. For + + derived types and attributes that are based on such types, format + specifications SHOULD be omitted. Implementations MUST ignore format + specifications they cannot interpret. Also note that the SMIng + grammar (Appendix A) does not specify the syntax of format + specifications. Display Format Examples: Base Type Format Example Value Rendered Value ----------- ------------------- ---------------- ----------------- OctetString 255a "Hello World." Hello World. OctetString 1x: "Hello!" 48:65:6c:6c:6f:21 OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0 OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024 OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee Integer32 d-2 1234 12.34 4. The SMIng File Structure The topmost container of SMIng information is a file. An SMIng file may contain zero, one or more modules. It is RECOMMENDED to separate - modules into files named by their modules, where possible. Though, + modules into files named by their modules, where possible. However, for dedicated purposes it may be reasonable to collect several modules in a single file. The top level SMIng construct is the `module' statement (Section 5) that defines a single SMIng module. A module contains a sequence of sections in an obligatory order with different kinds of definitions. Whether these sections contain statements or remain empty mainly depends on the purpose of the module. 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 between the characters of a single token like those of a quoted string. However, it is RECOMMENDED that all substantive descriptions be placed within an appropriate description clause, so that the information is available to SMIng parsers. Comments commence with a pair of adjacent slashes `//' and end at the end of the line. 4.2 Textual Data Some statements, namely `organization', `contact', `description', `reference', `abnf', `format', and `units', get a textual argument. This text, as well as representations of OctetString values, have to - be enclosed in double quotes. they may contain arbitrary characters + + be enclosed in double quotes. They may contain arbitrary characters with the following exceptional encoding rules: A backslash character introduces a special character, which depends on the character that immediately follows the backslash: \n new line \t a tab character \" a double quote \\ a single backslash @@ -1028,48 +1036,56 @@ + + }; - The optional `import' statements are followed by the mandatory - `organization', `contact', and `description' statements and the - optional `reference' statement, which in turn are followed by the - mandatory `revision' statements. This part defines the module's meta - information while the following sections contain its main - definitions. + The optional `import' statements (Section 5.1) are followed by the + mandatory `organization' (Section 5.2), `contact' (Section 5.3), and + `description' (Section 5.4) statements and the optional `reference' + statement (Section 5.5), which in turn are followed by at least one + mandatory `revision' statement (Section 5.6). The part up to this + point defines the module's meta information, i.e., information that + describes the whole module but which does not define any items used + by applications in the first instance. This part of a module is + followed by its main definitions, namely SMIng extensions (Section + 6), derived types (Section 7), identities (Section 8), and classes + (Section 9). See the `moduleStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `module' statement. 5.1 The module's import Statement The optional module's `import' statement is used to import identifiers from external modules into the local module's namespace. It gets two arguments: the name of the external module and a comma-separated list of one or more identifiers to be imported enclosed in parenthesis. Multiple `import' statements for the same module but with disjoint lists of identifiers are allowed, though NOT RECOMMENDED. Anyhow, the same identifier from the same module MUST NOT be imported multiple times. To import identifiers with the same name from different modules might be necessary and is allowed. To distinguish them in the local module, they have to be referred by qualified + names. It is NOT RECOMMENDED to import identifiers not used in the local module. See the `importStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `import' statement. 5.2 The module's organization Statement The module's `organization' statement, which must be present, gets one argument which is used to specify a textual description of the @@ -1110,21 +1126,20 @@ for the formal syntax of the `revision' statement. 5.6.1 The revision's date Statement The revision's `date' statement, which must be present, gets one argument which is used to specify the date and time of the revision in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the time `00:00'. The time is always given in UTC. See the `date' rule of the SMIng grammar (Appendix A) for the formal - syntax of the revision's `date' statement. 5.6.2 The revision's description Statement The revision's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the revision. 5.7 Usage Example @@ -1152,47 +1167,48 @@ description "The module for entities implementing the ACME protocol. Copyright (C) The Internet Society (2003). All Rights Reserved. This version of this MIB module is part of RFC XXXX, see the RFC itself for legal notices."; revision { - date "2003-09-19"; + date "2003-10-29"; description "Initial revision, published as RFC XXXX."; }; // ... further definitions ... }; // end of module ACME-MIB. 6. The extension Statement The `extension' statement is used to define new statements to be used in the local module following this extension statement definition or in external modules that may import this extension statement definition. The `extension' statement gets two arguments: a lower-case extension statement identifier and a statement block that holds detailed extension information in an obligatory order. Extension statement identifiers SHOULD NOT contain any upper-case + characters. Note that the SMIng extension feature does not allow to formally specify the context, argument syntax and semantics of an extension. Its only purpose is to declare the existence of an extension and to allow a unique reference to an extension. See Section 11 for - detailed information on extensions and [SNMP] for mappings of SMIng - definitions to SNMP which is formally defined as an extension. + detailed information on extensions and [RFCxxx3] for mappings of + SMIng definitions to SNMP which is formally defined as an extension. See the `extensionStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `extension' statement. 6.1 The extension's status Statement The extension's `status' statement, which must be present, gets one argument which is used to specify whether this extension definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the @@ -1207,21 +1223,20 @@ The extension's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the extension statement. It is RECOMMENDED to include information on the extension's context, its semantics, and implementation conditions. See also Section 11. 6.3 The extension's reference Statement The extension's `reference' statement, which need not be present, - gets one argument which is used to specify a textual cross-reference to some other document, either another module which defines related extension definitions, or some other document which provides additional information relevant to this extension. 6.4 The extension's abnf Statement The extension's `abnf' statement, which need not be present, gets one argument which is used to specify a formal ABNF [RFC2234] grammar definition of the extension. This grammar can reference rule names @@ -1268,20 +1283,21 @@ derived. Optionally, type restrictions may be applied to the new type by appending subtyping information according to the rules of the base type. See Section 3 for SMIng base types and their type restrictions. 7.2 The typedef's default Statement The typedef's `default' statement, which need not be present, gets one argument which is used to specify an acceptable default value for attributes of this type. A default value may be used when an + attribute instance is created. That is, the value is a "hint" to implementors. The value of the `default' statement must, of course, correspond to the (probably restricted) type specified in the typedef's `type' statement. The default value of a type may be overwritten by a default value of an attribute of this type. @@ -1304,21 +1320,20 @@ The typedef's `units' statement, which need not be present, gets one argument which is used to specify a textual definition of the units associated with attributes of this type. If no units are specified, they are inherited from the type given in the `type' statement. On the other hand, the units specification of a type may be semantically refined by a units specification of an attribute of this type. The units specification has to be appropriate for values displayed - according to the typedef's format specification, if present. E.g., if the type defines frequency values of type Unsigned64 measured in thousands of Hertz, the format specification should be `d-3' and the units specification should be `Hertz' or `Hz'. If the format specification would be omitted, the units specification should be `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay attention to keep format and units specifications synced. Application implementors MUST NOT implement units specifications without implementing format specifications. @@ -1365,20 +1380,21 @@ type Enumeration (other(1), ok(2), rptrFailure(3), groupFailure(4), portFailure(5), generalFailure(6)); default other; // undefined by default. status deprecated; description "A type to indicate the operational state of a repeater."; reference "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState."; + }; typedef SnmpTransportDomain { type Pointer (snmpTransportDomain); status current; description "A pointer to an SNMP transport domain identity."; }; typedef DateAndTime { @@ -1402,32 +1418,32 @@ description "A wide-range frequency specification measured in thousands of Hertz."; }; 8. The identity Statement The `identity' statement is used to define a new abstract and untyped identity. Its only purpose is to denote its name, semantics and existence. An identity can be defined either from scratch or derived - from a parent identity. The `identity' statement gets the following two arguments: The first argument is a lower-case identity identifier. The second argument is a statement block that holds detailed identity information in an obligatory order. See the `identityStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `identity' statement. 8.1 The identity's parent Statement The identity's `parent' statement must be present for a derived + identity and must be absent for an identity defined from scratch. It gets one argument which is used to specify the parent identity from which this identity shall be derived. 8.2 The identity's status Statement The identity's `status' statement, which must be present, gets one argument which is used to specify whether this identity definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is @@ -1451,21 +1467,20 @@ It is RECOMMENDED to include all semantic definitions necessary for implementation, and to embody any information which would otherwise be communicated in any commentary annotations associated with this identity definition. 8.4 The identity's reference Statement The identity's `reference' statement, which need not be present, gets one argument which is used to specify a textual cross-reference to - some other document, either another module which defines related identity definitions, or some other document which provides additional information relevant to this identity definition. 8.5 Usage Examples identity null { status current; description "An identity used to represent null pointer values."; @@ -1504,20 +1519,21 @@ 9.1 The class' extends Statement The class' `extends' statement must be present for a class derived from a parent class and must be absent for a class defined from scratch. It gets one argument which is used to specify the parent class from which this class shall be derived. 9.2 The class' attribute Statement The class' `attribute' statement, which can be present zero, one or + multiple times, gets two arguments: the attribute name and a statement block that holds detailed attribute information in an obligatory order. 9.2.1 The attribute's type Statement The attribute's `type' statement must be present. It gets at least one argument which is used to specify the type of the attribute: either a type name or a class name. In case of a type name, it may be restricted by a second argument according to the restriction rules @@ -1598,23 +1614,23 @@ argument which is used to specify whether this attribute definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/ existing implementations. Attributes SHOULD NOT be defined as `current' if their type or their - containing class is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be defined as `deprecated' if their type or their + containting class is `obsolete'. Nevertheless, subsequent revisions of used type definition cannot be avoided, but SHOULD be taken into account in subsequent revisions of the local module. 9.2.7 The attribute's description Statement The attribute's `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of this attribute. @@ -1647,21 +1663,20 @@ If present, the attribute list MUST NOT contain any attribute more than once and the attributes should be ordered where appropriate so that the attributes that are most significant in most situations appear first. 9.4 The class' event Statement The class' `event' statement is used to define an event related to an instance of this class that can occur asynchronously. It gets two arguments: a lower-case event identifier and a statement block that - holds detailed information in an obligatory order. See the `eventStatement' rule of the SMIng grammar (Appendix A) for the formal syntax of the `event' statement. 9.4.1 The event's status Statement The event's `status' statement, which must be present, gets one argument which is used to specify whether this event definition is current or historic. The value `current' means that the definition @@ -1696,23 +1711,23 @@ argument which is used to specify whether this class definition is current or historic. The value `current' means that the definition is current and valid. The value `obsolete' means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value `deprecated' also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. Derived classes SHOULD NOT be defined as `current' if their parent class is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be - defined as `deprecated' if their parent class is `obsolete'. Nevertheless, subsequent revisions of the parent class cannot be + avoided, but SHOULD be taken into account in subsequent revisions of the local module. 9.6 The class' description Statement The class' `description' statement, which must be present, gets one argument which is used to specify a high-level textual description of the newly defined class. It is RECOMMENDED to include all semantic definitions necessary for @@ -1745,23 +1760,23 @@ in bits per second."; }; // ... attribute adminStatus { type AdminStatus; access readwrite; status current; description "The desired state of the interface."; }; - attribute operStatus { type OperStatus; + access readonly; status current; description "The current operational state of the interface."; }; event linkDown { status current; description "A linkDown event signifies that the ifOperStatus @@ -1794,21 +1809,20 @@ Note that any definition contained in a module is available to be imported by any other module, and is referenced in an `import' statement via the module name. Thus, a module name MUST NOT be changed. Specifically, the module name (e.g., `ACME-MIB' in the example of Section 5.7) MUST NOT be changed when revising a module (except to correct typographical errors), and definitions MUST NOT be moved from one module to another. Also note, that obsolete definitions MUST NOT be removed from modules - since their identifiers may still be referenced by other modules. A definition may be revised in any of the following ways: o In `typedef' statement blocks, a `type' statement containing an `Enumeration' or `Bits' type may have new named numbers added. o In `typedef' statement blocks, the value of a `type' statement may be replaced by another type if the new type is derived (directly or indirectly) from the same base type, has the same set of @@ -1843,23 +1857,23 @@ may be included in the `description' statement. o In any statement block, a `reference' statement may be added or updated. o Entirely new extensions, types, identities, and classes may be defined, using previously unassigned identifiers. Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than - those specifically allowed above), then this MUST be achieved by a new definition with a new identifier. In case of a class where the + semantics of any attributes are changed, the new class can be defined by derivation from the old class and refining the changed attributes. Note that changing the identifier associated with an existing definition is considered a semantic change, as these strings may be used in an `import' statement. 11. SMIng Language Extensibility While the core SMIng language has a well defined set of statements @@ -1892,21 +1906,20 @@ standardized extension for that purpose. The requirement to explicitly import extension statements allows to distinguish those extensions. o The supported extensions of an SMIng implementation, e.g. an SMIng module compiler, can be clearly expressed. The only formal effect of an extension statement definition is to declare its existence and its status, and optionally its ABNF grammar. All additional aspects SHOULD be described in the - `description' statement: o The detailed semantics of the new statement SHOULD be described. o The contexts in which the new statement can be used, SHOULD be described, e.g., a new statement may be designed to be used only in the statement block of a module, but not in other nested statement blocks. Others may be applicable in multiple contexts. In addition, the point in the sequence of an obligatory order of other statements, where the new statement may be inserted, might @@ -1917,21 +1930,21 @@ o The syntax of the new statement SHOULD at least be described informally, if not supplied formally in an `abnf' statement. o It might be reasonable to give some suggestions under which conditions the implementation of the new statement is adequate and how it could be integrated into existent implementations. Some possible extension applications are: - o The formal mapping of SMIng definitions into the SNMP [SNMP] + o The formal mapping of SMIng definitions into the SNMP [RFCxxx3] framework is defined as an SMIng extension. Other mappings may follow in the future. o Inlined annotations to definitions. E.g., a vendor may wish to describe additional information to class and attribute definitions in private modules. An example are severity levels of events in the statement block of an `event' statement. o Arbitrary annotations to external definitions. E.g., a vendor may wish to describe additional information to definitions in a @@ -1942,68 +1955,70 @@ 12. Security Considerations This document defines a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet. 13. Acknowledgements Since SMIng started as a close successor of SMIv2, some paragraphs and phrases are directly taken from the SMIv2 specifications + [RFC2578], [RFC2579], [RFC2580] written by Jeff Case, Keith McCloghrie, David Perkins, Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser. The authors would like to thank all participants of the 7th NMRG meeting held in Schloss Kleinheubach from 6-8 September 2000, which was a major step towards the current status of this memo, namely - Heiko Dassow, David Durham, and Bert Wijnen. + Heiko Dassow, David Durham, Keith McCloghrie, and Bert Wijnen. Furthmore, several discussions within the SMING Working Group reflected experience with SMIv2 and influenced this specification at some points. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Informative References [RFC3216] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J., Strauss, F. and W. Weiss, "SMIng Objectives", RFC 3216, December 2001. - [Modules] Strauss, F. and J. Schoenwaelder, "SMIng Core Modules", - draft-irtf-nmrg-sming-modules-03.txt, September 2003. + [RFCxxx2] Strauss, F. and J. Schoenwaelder, "SMIng Core Modules", + draft-irtf-nmrg-sming-modules-04.txt, October 2003. - [SNMP] Strauss, F. and J. Schoenwaelder, "SMIng Extension for - SNMP Mappings", draft-irtf-nmrg-sming-snmp-03.txt, - September 2003. + [RFCxxx3] Strauss, F. and J. Schoenwaelder, "SMIng Extension for + SNMP Mappings", draft-irtf-nmrg-sming-snmp-04.txt, October + 2003. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 59, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, STD 60, April 1999. [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, + S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, STD 16, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC 1212, STD 16, March 1991. @@ -2050,21 +2065,21 @@ URI: http://www.eecs.iu-bremen.de/ Appendix A. SMIng ABNF Grammar The SMIng grammar conforms to the Augmented Backus-Naur Form (ABNF) [RFC2234]. ;; ;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234). ;; - ;; @(#) $Id: sming.abnf,v 1.32 2003/07/22 16:55:34 strauss Exp $ + ;; @(#) $Id: sming.abnf,v 1.33 2003/10/23 19:31:55 strauss Exp $ ;; ;; Copyright (C) The Internet Society (2003). All Rights Reserved. ;; smingFile = optsep *(moduleStatement optsep) ;; ;; Statement rules. ;; @@ -2506,20 +2521,22 @@ ; linefeed SP = %x20 ; space VCHAR = %x21-7E ; visible (printing) characters WSP = SP / HTAB ; white space + + ;; End of ABNF Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and