doc: Add RFC documents

1 files changed, 3587 insertions, 0 deletions

diff --git a/doc/rfc/rfc3780.txt b/doc/rfc/rfc3780.txt
new file mode 100644
index 0000000..568d474
--- /dev/null
+++ b/doc/rfc/rfc3780.txt
@@ -0,0 +1,3587 @@
+
+
+
+
+
+
+Network Working Group                                         F. Strauss
+Request for Comments: 3780                               TU Braunschweig
+Category: Experimental                                  J. Schoenwaelder
+                                         International University Bremen
+                                                                May 2004
+
+
+      SMIng - Next Generation Structure of Management Information
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   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.  Separate RFCs define mappings of SMIng to
+   specific management protocols, including SNMP.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  The History of SMIng . . . . . . . . . . . . . . . . . .  4
+       1.2.  Terms of Requirement Levels. . . . . . . . . . . . . . .  5
+   2.  SMIng Data Modeling. . . . . . . . . . . . . . . . . . . . . .  5
+       2.1.  Identifiers. . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Base Types and Derived Types . . . . . . . . . . . . . . . . .  7
+       3.1.  OctetString. . . . . . . . . . . . . . . . . . . . . . .  8
+       3.2.  Pointer. . . . . . . . . . . . . . . . . . . . . . . . .  9
+       3.3.  ObjectIdentifier . . . . . . . . . . . . . . . . . . . .  9
+       3.4.  Integer32. . . . . . . . . . . . . . . . . . . . . . . . 10
+       3.5.  Integer64. . . . . . . . . . . . . . . . . . . . . . . . 11
+       3.6.  Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . 12
+       3.7.  Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . 13
+       3.8.  Float32. . . . . . . . . . . . . . . . . . . . . . . . . 13
+       3.9.  Float64. . . . . . . . . . . . . . . . . . . . . . . . . 14
+       3.10. Float128 . . . . . . . . . . . . . . . . . . . . . . . . 15
+       3.11. Enumeration. . . . . . . . . . . . . . . . . . . . . . . 17
+       3.12. Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 1]
+
+RFC 3780                         SMIng                          May 2004
+
+
+       3.13. Display Formats. . . . . . . . . . . . . . . . . . . . . 18
+   4.  The SMIng File Structure . . . . . . . . . . . . . . . . . . . 20
+       4.1.  Comments . . . . . . . . . . . . . . . . . . . . . . . . 20
+       4.2.  Textual Data . . . . . . . . . . . . . . . . . . . . . . 21
+       4.3.  Statements and Arguments . . . . . . . . . . . . . . . . 21
+   5.  The module Statement . . . . . . . . . . . . . . . . . . . . . 21
+       5.1.  The module's import Statement. . . . . . . . . . . . . . 22
+       5.2.  The module's organization Statement. . . . . . . . . . . 23
+       5.3.  The module's contact Statement . . . . . . . . . . . . . 23
+       5.4.  The module's description Statement . . . . . . . . . . . 23
+       5.5.  The module's reference Statement . . . . . . . . . . . . 23
+       5.6.  The module's revision Statement. . . . . . . . . . . . . 23
+             5.6.1. The revision's date Statement . . . . . . . . . . 24
+             5.6.2. The revision's description Statement. . . . . . . 24
+       5.7.  Usage Example. . . . . . . . . . . . . . . . . . . . . . 24
+   6.  The extension Statement. . . . . . . . . . . . . . . . . . . . 25
+       6.1.  The extension's status Statement . . . . . . . . . . . . 25
+       6.2.  The extension's description Statement. . . . . . . . . . 26
+       6.3.  The extension's reference Statement. . . . . . . . . . . 26
+       6.4.  The extension's abnf Statement . . . . . . . . . . . . . 26
+       6.5.  Usage Example. . . . . . . . . . . . . . . . . . . . . . 26
+   7.  The typedef Statement. . . . . . . . . . . . . . . . . . . . . 27
+       7.1.  The typedef's type Statement . . . . . . . . . . . . . . 27
+       7.2.  The typedef's default Statement. . . . . . . . . . . . . 27
+       7.3.  The typedef's format Statement . . . . . . . . . . . . . 27
+       7.4.  The typedef's units Statement. . . . . . . . . . . . . . 28
+       7.5.  The typedef's status Statement . . . . . . . . . . . . . 28
+       7.6.  The typedef's description Statement. . . . . . . . . . . 29
+       7.7.  The typedef's reference Statement. . . . . . . . . . . . 29
+       7.8.  Usage Examples . . . . . . . . . . . . . . . . . . . . . 29
+   8.  The identity Statement . . . . . . . . . . . . . . . . . . . . 30
+       8.1.  The identity's parent Statement. . . . . . . . . . . . . 30
+       8.2.  The identity's status Statement. . . . . . . . . . . . . 30
+       8.3.  The identity' description Statement. . . . . . . . . . . 31
+       8.4.  The identity's reference Statement . . . . . . . . . . . 31
+       8.5.  Usage Examples . . . . . . . . . . . . . . . . . . . . . 31
+   9.  The class Statement. . . . . . . . . . . . . . . . . . . . . . 32
+       9.1.  The class' extends Statement . . . . . . . . . . . . . . 32
+       9.2.  The class' attribute Statement . . . . . . . . . . . . . 32
+             9.2.1. The attribute's type Statement. . . . . . . . . . 32
+             9.2.2. The attribute's access Statement. . . . . . . . . 32
+             9.2.3. The attribute's default Statement . . . . . . . . 33
+             9.2.4. The attribute's format Statement. . . . . . . . . 33
+             9.2.5. The attribute's units Statement . . . . . . . . . 33
+             9.2.6. The attribute's status Statement. . . . . . . . . 34
+             9.2.7. The attribute's description Statement . . . . . . 34
+             9.2.8. The attribute's reference Statement . . . . . . . 34
+       9.3.  The class' unique Statement. . . . . . . . . . . . . . . 35
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 2]
+
+RFC 3780                         SMIng                          May 2004
+
+
+       9.4.  The class' event Statement . . . . . . . . . . . . . . . 35
+             9.4.1. The event's status Statement. . . . . . . . . . . 35
+             9.4.2. The event's description Statement . . . . . . . . 35
+             9.4.3. The event's reference Statement . . . . . . . . . 36
+       9.5.  The class' status Statement. . . . . . . . . . . . . . . 36
+       9.6.  The class' description Statement . . . . . . . . . . . . 36
+       9.7.  The class' reference Statement . . . . . . . . . . . . . 37
+       9.8.  Usage Example. . . . . . . . . . . . . . . . . . . . . . 37
+   10. Extending a Module . . . . . . . . . . . . . . . . . . . . . . 38
+   11. SMIng Language Extensibility . . . . . . . . . . . . . . . . . 39
+   12. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
+   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
+       14.1. Normative References . . . . . . . . . . . . . . . . . . 42
+       14.2. Informative References . . . . . . . . . . . . . . . . . 42
+   Appendix A.  NMRG-SMING Module . . . . . . . . . . . . . . . . . . 44
+   Appendix B.  SMIng ABNF Grammar. . . . . . . . . . . . . . . . . . 53
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 64
+
+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 in conformance with 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],
+   [RFC1215], and the SMI version 2 (SMIv2) in [RFC2578], [RFC2579], and
+   [RFC2580].  Both are based on adapted subsets of OSI's Abstract
+   Syntax Notation One, ASN.1 [ASN1].
+
+   In a similar fashion, policy provisioning information is viewed as a
+   collection of Provisioning Classes (PRCs) and Provisioning Instances
+   (PRIs) residing in a virtual information store, termed the Policy
+   Information Base (PIB).  Collections of related Provisioning Classes
+   are defined in PIB modules.  PIB modules are written using the
+   Structure of Policy Provisioning Information (SPPI) [RFC3159] which
+   is an adapted subset of SMIv2.
+
+   The SMIv1 and the SMIv2 are bound to the Simple Network Management
+   Protocol (SNMP) [RFC3411], while the SPPI is bound to the Common Open
+   Policy Service Provisioning (COPS-PR) Protocol [RFC3084].  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 can
+
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 3]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   formally specify data models independent of specific protocols and
+   applications.  The appendix of this document defines a core module
+   that supplies common SMIng definitions.
+
+   A companion document contains an SMIng language extension to define
+   SNMP specific mappings of SMIng definitions in compatibility with
+   SMIv2 MIB modules [RFC3781].  Additional language extensions may be
+   added in the future, e.g., to define COPS-PR specific mappings of
+   SMIng definitions in a way that is compatible with SPPI PIBs.
+
+   Section 2 gives an overview of the basic concepts of data modeling
+   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 B 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 modeling language for management
+   information bases.  Primarily, its partial dependence on ASN.1 and a
+   number of exception rules 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
+   definitions 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 (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, resulting in the Working Group being 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 memo on the SNMP
+   protocol mapping [RFC3781] have been published for informational
+   purposes.
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 4]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   Note that throughout these documents, the term "SMIng" refers to the
+   specific data modeling 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 Modeling
+
+   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
+   Section 9.2.
+
+   The base types of SMIng include signed and unsigned integers, octet
+   strings, enumeration types, bitset types, and pointers.  Pointers are
+   references to class instances, attributes of class instances, or
+   arbitrary identities.  The SMIng type system is described in Section
+   3.
+
+   Related class and type definitions are defined in modules.  A module
+   may refer to definitions from other modules by importing identifiers
+   from those modules.  Each module may serve one or multiple purposes:
+
+   o  the definition of management classes,
+
+   o  the definition of events,
+
+   o  the definition of derived types,
+
+   o  the definition of arbitrary untyped identities serving as values
+      of pointers,
+
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 5]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   o  the definition of SMIng extensions allowing 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
+      [RFC3781],
+
+   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
+      inner namespaces of the module.
+
+   o  Each class within a module defines a new namespace.  A class'
+      namespace may contain definitions of attribute identifiers and
+      event identifiers.
+
+   o  Each enumeration type and bitset type defines a new namespace of
+      its named numbers.  These named numbers are visible in each
+      expression of a corresponding value, e.g., default values and
+      sub-typing restrictions.
+
+   o  Extensions may define additional namespaces and have additional
+      rules of other namespaces' visibility.
+
+   Within every namespace each identifier MUST be unique.
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 6]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   Each identifier starts with an upper-case or lower-case character,
+   dependent on the kind of SMIng item, followed by zero or more
+   letters, digits, and hyphens.
+
+   All identifiers defined in a namespace MUST be unique and SHOULD NOT
+   only differ in case.  Identifiers MUST NOT exceed 64 characters in
+   length.  Furthermore, the set of all identifiers defined in all
+   modules of a single standardization body or organization SHOULD be
+   unique and mnemonic.  This promotes a common language for humans to
+   use when discussing a module.
+
+   To reference an item that is defined in the local module, its
+   definition MUST sequentially precede the reference.  Thus, there MUST
+   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 B 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 [RFC3781].
+
+   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
+
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 7]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   through Section 3.10), restricted pointer types (Section 3.2), and
+   restrictions on the sets of named numbers for enumeration types
+   (Section 3.11) and bit sets (Section 3.12).
+
+3.1.  OctetString
+
+   The OctetString base type represents arbitrary binary or textual
+   data.  Although SMIng has a theoretical size limitation of 2^16-1
+   (65535) octets for this base type, module designers should realize
+   that there may be implementation and interoperability limitations for
+   sizes in excess of 255 octets.
+
+   Values of octet strings may be denoted as textual data enclosed in
+   double quotes or as arbitrary binary data denoted as a `0x'-prefixed
+   hexadecimal value of 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, with 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
+   of at least two digits.  Size restricting values MUST NOT 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
+   applied to an already size restricted octet string, the new
+   restriction MUST be equal or more limiting, that is, raising the
+   lower bounds, reducing the upper bounds, removing explicit size
+   values or ranges, or splitting ranges into multiple ranges with
+   intermediate gaps.
+
+
+
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 8]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   Value Examples:
+
+      "This is a multiline
+       textual data example."         // legal
+      "This is "illegally" quoted."   // illegal quotes
+      "This is \"legally\" quoted."   // legally encoded quotes
+      "But this is 'ok', as well."    // legal apostrophe quoting
+      ""                              // legal zero length
+      0x123                           // illegal odd hex length
+      0x534d496e670a                  // legal octet string
+
+   Restriction Examples:
+
+      OctetString (0 | 4..255)        // legal size spec
+      OctetString (4)                 // legal exact size
+      OctetString (-1 | 1)            // illegal negative size
+      OctetString (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.  ObjectIdentifier
+
+   The ObjectIdentifier base type represents administratively assigned
+   names for use with SNMP and COPS-PR.  This type SHOULD NOT be used in
+   protocol independent SMIng modules.  It is meant to be used in SNMP
+   and COPS-PR mappings of attributes of type Pointer (Section 3.2).
+
+
+
+Strauss & Schoenwaelder       Experimental                      [Page 9]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   Values of this type may be denoted as a sequence of numerical non-
+   negative sub-identifier values in which each MUST NOT exceed 2^32-1
+   (4294967295).  Sub-identifiers may be denoted in 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.
+
+   Although the number of sub-identifiers in SMIng object identifiers is
+   not limited, module designers should realize that there may be
+   implementations that stick with the SMIv1/v2 limit of 128 sub-
+   identifiers.
+
+   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          // legal fully qualified 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
+   numbers, where only decimal numbers can be negative.  Decimal numbers
+   other than zero MUST NOT have leading zero digits.  Hexadecimal
+   numbers are prefixed by `0x' and MUST have an even number of at least
+   two hexadecimal digits, where letters MAY be upper-case, but lower-
+   case characters are RECOMMENDED.
+
+   When defining a type derived (directly or indirectly) from the
+   Integer32 base type, the set of possible values may be restricted by
+   appending a list of ranges or explicit values, separated by pipe `|'
+   characters, and the whole list enclosed in parenthesis.  A range
+   consists of a lower bound, two consecutive dots `..', and an upper
+   bound.  Each value can be given in decimal or `0x'-prefixed
+   hexadecimal notation.  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
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 10]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   bounds, reducing the upper bounds, removing explicit values or
+   ranges, or splitting ranges into multiple ranges with intermediate
+   gaps.
+
+   Value Examples:
+
+      015                         // illegal leading zero
+      -123                        // legal negative value
+      - 1                         // illegal intermediate space
+      0xabc                       // illegal hexadecimal value length
+      -0xff                       // illegal sign on hex value
+      0x80000000                  // illegal value, too large
+      0xf00f                      // legal hexadecimal value
+
+   Restriction Examples:
+
+      Integer32 (0 | 5..10)       // legal range spec
+      Integer32 (5..10 | 2..3)    // illegal ordering
+      Integer32 (4..8 | 5..10)    // illegal overlapping
+
+3.5.  Integer64
+
+   The Integer64 base type represents integer values between
+   -2^63 (-9223372036854775808) and 2^63-1 (9223372036854775807).
+
+   Values of type Integer64 may be denoted as decimal or hexadecimal
+   numbers, where only decimal numbers can be negative.  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
+   Integer64 base type, the set of possible values may be restricted by
+   appending a list of ranges or explicit values, separated by pipe `|'
+   characters, with 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.
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 11]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   Value Examples:
+
+      015                         // illegal leading zero
+      -123                        // legal negative value
+      - 1                         // illegal intermediate space
+      0xabc                       // illegal hexadecimal value length
+      -0xff                       // illegal sign on hex value
+      0x80000000                  // legal value
+
+   Restriction Examples:
+
+      Integer64 (0 | 5..10)       // legal range spec
+      Integer64 (5..10 | 2..3)    // illegal ordering
+      Integer64 (4..8 | 5..10)    // illegal overlapping
+
+3.6.  Unsigned32
+
+   The Unsigned32 base type represents positive integer values between 0
+   and 2^32-1 (4294967295).
+
+   Values of type Unsigned32 may be denoted as decimal or hexadecimal
+   numbers.  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
+   Unsigned32 base type, the set of possible values may be restricted by
+   appending a list of ranges or explicit values, separated by pipe `|'
+   characters, with 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:
+
+      015                         // illegal leading zero
+      -123                        // illegal negative value
+      0xabc                       // illegal hexadecimal value length
+      0x80000000                  // legal hexadecimal value
+      0x8080000000                // illegal value, too large
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 12]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   Restriction Examples:
+
+      Unsigned32 (0 | 5..10)       // legal range spec
+      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, with 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:
+
+      015                         // illegal leading zero
+      -123                        // illegal negative value
+      0xabc                       // illegal hexadecimal value length
+      0x8080000000                // legal hexadecimal value
+
+   Restriction Examples:
+
+      Unsigned64 (1..10000000000) // legal range spec
+      Unsigned64 (5..10 | 2..3)   // illegal ordering
+
+3.8.  Float32
+
+   The Float32 base type represents floating point values of single
+   precision as described by [IEEE754].
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 13]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   Values of type Float32 may be denoted as a decimal fraction with an
+   optional exponent, as known from many programming languages.  See the
+   grammar rule `floatValue' of Appendix B for the detailed syntax.
+   Special values are `snan' (signalling 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, with 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 Float32.
+   Note also that most floating point encodings disallow the
+   representation of many values that can be written as decimal
+   fractions as used in SMIng for human readability.  Therefore,
+   explicit values in floating point type restrictions should be handled
+   with care.
+
+   Value Examples:
+
+      00.1                       // illegal leading zero
+      3.1415                     // legal value
+      -2.5E+3                    // legal negative exponential value
+
+   Restriction Examples:
+
+      Float32 (-1.0..1.0)        // legal range spec
+      Float32 (1 | 3.3 | 5)      // legal, probably unrepresentable 3.3
+      Float32 (neginf..-0.0)     // legal range spec
+      Float32 (-10.0..10.0 | 0)  // illegal overlapping
+
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 14]
+
+RFC 3780                         SMIng                          May 2004
+
+
+3.9.  Float64
+
+   The Float64 base type represents floating point values of double
+   precision as described by [IEEE754].
+
+   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 B for the detailed syntax.
+   Special values are `snan' (signalling 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, with 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.
+
+   Value Examples:
+
+      00.1                       // illegal leading zero
+      3.1415                     // legal value
+      -2.5E+3                    // legal negative exponential value
+
+   Restriction Examples:
+
+      Float64 (-1.0..1.0)        // legal range spec
+      Float64 (1 | 3.3 | 5)      // legal, probably unrepresentable 3.3
+      Float64 (neginf..-0.0)     // legal range spec
+      Float64 (-10.0..10.0 | 0)  // illegal overlapping
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 15]
+
+RFC 3780                         SMIng                          May 2004
+
+
+3.10.  Float128
+
+   The Float128 base type represents floating point values of quadruple
+   precision as described by [IEEE754].
+
+   Values of type Float128 may be denoted as a decimal fraction with an
+   optional exponent, as known from many programming languages.  See the
+   grammar rule `floatValue' of Appendix B for the detailed syntax.
+   Special values are `snan' (signalling Not-a-Number), `qnan' (quiet
+   Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
+   infinity).  Note that -0.0 and +0.0 are different floating point
+   values.  0.0 is equal to +0.0.
+
+   When defining a type derived (directly or indirectly) from the
+   Float128 base type, the set of possible values may be restricted by
+   appending a list of ranges or explicit values, separated by pipe `|'
+   characters, with 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
+   with care.
+
+   Value Examples:
+
+      00.1                       // illegal leading zero
+      3.1415                     // legal value
+      -2.5E+3                    // legal negative exponential value
+
+   Restriction Examples:
+
+      Float128 (-1.0..1.0)        // legal range spec
+      Float128 (1 | 3.3 | 5)      // legal, probably unrepresentable 3.3
+      Float128 (neginf..-0.0)     // legal range spec
+      Float128 (-10.0..10.0 | 0)  // illegal overlapping
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 16]
+
+RFC 3780                         SMIng                          May 2004
+
+
+3.11.  Enumeration
+
+   The Enumeration base type represents values from a set of integers in
+   the range between -2^31 (-2147483648) and 2^31-1 (2147483647), where
+   each value has an assigned name.  The list of those named numbers has
+   to be comma-separated, enclosed in parenthesis, and appended to the
+   `Enumeration' keyword.  Each named number is denoted by its lower-
+   case identifier followed by the assigned integer value, denoted as a
+   decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis.
+   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 be positive, 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
+   2                            // legal value given by number
+
+3.12.  Bits
+
+   The Bits base type represents bit sets.  That is, a Bits value is a
+   set of flags identified by small integer numbers starting at 0.  Each
+   bit number has an assigned name.  The list of those named numbers has
+   to be comma-separated, enclosed in parenthesis, and appended to the
+   `Bits' keyword.  Each named number is denoted by its lower-case
+   identifier followed by the assigned integer value, denoted as a
+   decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis.
+   Hexadecimal numbers must have an even number of at least two digits.
+   Every name and every number in a bits type MUST be unique.  It is
+   RECOMMENDED that numbers start at 0 and be numbered contiguously.
+   Negative numbers are forbidden.  All named numbers MUST be given in
+   ascending order.
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 17]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   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), writable(1), executable(2))
+      Bits (writable(1), readable(0) // illegal order
+
+      ()                          // legal empty value
+      (readable, writable, 2)     // legal value
+      (0, readable, executable)   // illegal, readable(0) appears twice
+      (writable, 4)               // illegal, element 4 out of range
+
+3.13.  Display Formats
+
+   Attribute 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,
+   Integer64, Unsigned32, or Unsigned64, the format consists of an
+   integer-format specification containing two parts.  The first part is
+   a single character suggesting a display format, either: `x' for
+   hexadecimal, `d' for decimal, `o' for octal, or `b' for binary.  For
+   all types, when rendering the value, leading zeros are omitted, and
+   for negative values, a minus sign is rendered immediately before the
+   digits.  The second part is always omitted for `x', `o', and `b', and
+   need not be present for `d'.  If present, the second part starts with
+   a hyphen and is followed by a decimal number, which defines the
+   implied decimal point when rendering the value.  For example `d-2'
+   suggests that a value of 1234 be rendered as `12.34'.
+
+   When the attribute or type has an underlying base type of
+   OctetString, the format consists of one or more octet-format
+   specifications.  Each specification consists of five parts, with each
+   part using and removing zero or more of the next octets from the
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 18]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   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) specifying 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 [RFC3629].  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 to interpret the octets in the value.  The
+      octets processed by the `t' display format do not necessarily form
+      an integral number of UTF-8 characters.  Trailing octets which do
+      not form a valid UTF-8 encoded character are discarded.
+
+   4. The (optional) display separator character.  If present, this part
+      is a single character produced for display after each application
+      of this octet-specification; however, this character is not
+      produced for display if it would be immediately followed by the
+      display of the repeat terminator character for this octet
+      specification.  This character can be any character other than a
+      decimal digit and a `*'.
+
+   5. The (optional) repeat terminator character, which can be present
+      only if the display separator character is present and this octet
+      specification begins with a repeat indicator.  If present, this
+      part is a single character produced after all the zero or more
+      repeated applications (as given by the repeat count) of this octet
+      specification.  This character can be any character other than a
+      decimal digit and a `*'.
+
+   Output of a display separator character or a repeat terminator
+   character is suppressed if it would occur as the last character of
+   the display.
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 19]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   If the octets of the value are exhausted before all the octet format
+   specifications 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.  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 B) 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 that
+   modules be stored into separate files by their module names, 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
+   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.
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 20]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   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
+   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
+
+   If the text contains a line break followed by whitespace which is
+   used to indent the text according to the layout in the SMIng file,
+   this prefixing whitespace is stripped from the text.
+
+4.3.  Statements and Arguments
+
+   SMIng has a very small set of basic grammar rules based on the
+   concept of statements.  Each statement starts with a lower-case
+   keyword identifying the statement, followed by a number (possibly
+   zero) of arguments.  An argument may be quoted text, an identifier, a
+   value of any base type, a list of identifiers enclosed in parenthesis
+   `( )', or a statement block enclosed in curly braces `{ }'.  Since
+   statement blocks are valid arguments, it is possible to nest
+   statement sequences.  Each statement is terminated by a semicolon
+   `;'.
+
+   The core set of statements may be extended using the SMIng
+   `extension' statement.  See Sections 6 and 11 for details.
+
+   At places where a statement is expected, but an unknown lower-case
+   word is read, those statements MUST be skipped up to the proper
+   semicolon, including nested statement blocks.
+
+5.  The module Statement
+
+   The `module' statement is used as a container of all definitions of a
+   single SMIng module.  It gets two arguments: an upper-case module
+   name and a statement block that contains mandatory and optional
+   statements and sections of statements in an obligatory order:
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 21]
+
+RFC 3780                         SMIng                          May 2004
+
+
+         module <MODULE-NAME> {
+
+             <optional import statements>
+             <organization statement>
+             <contact statement>
+             <description statement>
+             <optional reference statement>
+             <at least one revision statement>
+
+             <optional extension statements>
+
+             <optional typedef statements>
+
+             <optional identity statements>
+
+             <optional class statements>
+
+         };
+
+   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 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 B) 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.  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
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 22]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   them in the local module, they have to be referred by qualified
+   names.  Importing identifiers not used in the local module is NOT
+   RECOMMENDED.
+
+   See the `importStatement' rule of the SMIng grammar (Appendix B) for
+   the formal syntax of the `import' statement.
+
+5.2.  The module's organization Statement
+
+   The module's `organization' statement, which must be present, gets
+   one argument which is used to specify a textual description of the
+   organization(s) under whose auspices this module was developed.
+
+5.3.  The module's contact Statement
+
+   The module's `contact' statement, which must be present, gets one
+   argument which is used to specify the name, postal address, telephone
+   number, and electronic mail address of the person to whom technical
+   queries concerning this module should be sent.
+
+5.4.  The module's description Statement
+
+   The module's `description' statement, which must be present, gets one
+   argument which is used to specify a high-level textual description of
+   the contents of this module.
+
+5.5.  The module's reference Statement
+
+   The module's `reference' statement, which need not be present, gets
+   one argument which is used to specify a textual cross-reference to
+   some other document, either another module which defines related
+   management information, or some other document which provides
+   additional information relevant to this module.
+
+5.6.  The module's revision Statement
+
+   The module's `revision' statement is repeatedly used to specify the
+   editorial revisions of the module, including the initial revision.
+   It gets one argument which is a statement block that holds detailed
+   information in an obligatory order.  A module MUST have at least one
+   initial `revision' statement.  For every editorial change, a new one
+   MUST be added in front of the revisions sequence, so that all
+   revisions are in reverse chronological order.
+
+   See the `revisionStatement' rule of the SMIng grammar (Appendix B)
+   for the formal syntax of the `revision' statement.
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 23]
+
+RFC 3780                         SMIng                          May 2004
+
+
+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 B) 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
+
+   Consider how a skeletal module might be constructed:
+
+   module ACME-MIB {
+
+     import NMRG-SMING (DisplayString);
+
+     organization
+               "IRTF Network Management Research Group (NMRG)";
+
+     contact   "IRTF Network Management Research Group (NMRG)
+                http://www.ibr.cs.tu-bs.de/projects/nmrg/
+
+                Joe L. User
+
+                ACME, Inc.
+                42 Anywhere Drive
+                Nowhere, CA 95134
+                USA
+
+                Phone: +1 800 555 0815
+                EMail: joe@acme.example.com";
+
+     description
+               "The module for entities implementing the ACME protocol.
+
+                Copyright (C) The Internet Society (2004).
+                All Rights Reserved.
+                This version of this MIB module is part of RFC 3780,
+                see the RFC itself for legal notices.";
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 24]
+
+RFC 3780                         SMIng                          May 2004
+
+
+     revision {
+       date            "2003-12-16";
+       description
+               "Initial revision, published as RFC 3780.";
+     };
+
+     // ... further definitions ...
+
+   }; // end of module ACME-MIB.
+
+6.  The extension Statement
+
+   The `extension' statement defines 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 the formal
+   specification of the context, or 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 [RFC3781] for
+   mappings of SMIng definitions to SNMP, which is formally defined as
+   an extension.
+
+   See the `extensionStatement' rule of the SMIng grammar (Appendix B)
+   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
+   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.
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 25]
+
+RFC 3780                         SMIng                          May 2004
+
+
+6.2.  The extension's description Statement
+
+   The extension's `description' statement, which must be present, gets
+   one argument which is used to specify a high-level textual
+   description of the extension statement.
+
+   It is RECOMMENDED that information on the extension's context, its
+   semantics, and implementation conditions be included.  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
+   from the core SMIng grammar (Appendix B).
+
+   Note that the `abnf' statement should contain only pure ABNF and no
+   additional text, though comments prefixed by a semicolon are allowed
+   but should probably be moved to the description statement.  Note that
+   double quotes within the ABNF grammar have to be represented as `\"'
+   according to Section 4.2.
+
+6.5.  Usage Example
+
+   extension severity {
+     status  current;
+     description
+            "The optional severity extension statement can only
+             be applied to the statement block of an SMIng class'
+             event definition. If it is present it denotes the
+             severity level of the event in a range from 0
+             (emergency) to 7 (debug).";
+     abnf
+            "severityStatement = severityKeyword sep number optsep \";\"
+             severityKeyword   = \"severity\"";
+   };
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 26]
+
+RFC 3780                         SMIng                          May 2004
+
+
+7.  The typedef Statement
+
+   The `typedef' statement defines new data types to be used in the
+   local module or in external modules.  It gets two arguments:  an
+   upper-case type identifier and a statement block that holds detailed
+   type information in an obligatory order.
+
+   Type identifiers SHOULD NOT consist of all upper-case characters and
+   SHOULD NOT contain hyphens.
+
+   See the `typedefStatement' rule of the SMIng grammar (Appendix B) for
+   the formal syntax of the `typedef' statement.
+
+7.1.  The typedef's type Statement
+
+   The typedef's `type' statement, which must be present, gets one
+   argument which is used to specify the type from which this type is
+   derived.  Optionally, type restrictions may be applied to the new
+   type by appending subtyping information according to the rules of the
+   base type.  See Section 3 for SMIng base types and their type
+   restrictions.
+
+7.2.  The typedef's default Statement
+
+   The typedef's `default' statement, which need not be present, gets
+   one argument which is used to specify an acceptable default value for
+   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.
+
+   Note that for some types, default values make no sense.
+
+7.3.  The typedef's format Statement
+
+   The typedef's `format' statement, which need not be present, gets one
+   argument which is used to give a hint as to how the value of an
+   instance of an attribute of this type might be displayed.  See
+   Section 3.13 for a description of format specifications.
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 27]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   If no format is specified, it is inherited from the type given in the
+   `type' statement.  On the other hand, the format specification of a
+   type may be semantically refined by a format specification of an
+   attribute of this type.
+
+7.4.  The typedef's units Statement
+
+   The typedef's `units' statement, which need not be present, gets one
+   argument which is used to specify a textual definition of the units
+   associated with 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.  For
+   example, 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 in sync.
+   Application implementors MUST NOT implement units specifications
+   without implementing format specifications.
+
+7.5.  The typedef's status Statement
+
+   The typedef's `status' statement, which must be present, gets one
+   argument which is used to specify whether this type definition is
+   current or historic.  The value `current' means that the definition
+   is current and valid.  The value `obsolete' means the definition is
+   obsolete and should not be implemented and/or can be removed if
+   previously implemented.  While the value `deprecated' also indicates
+   an obsolete definition, it permits new/continued implementation in
+   order to foster interoperability with older/existing implementations.
+
+   Derived types SHOULD NOT be defined as `current' if their underlying
+   type is `deprecated' or `obsolete'.  Similarly, they SHOULD NOT be
+   defined as `deprecated' if their underlying type is `obsolete'.
+   Nevertheless, subsequent revisions of the underlying type cannot be
+   avoided, but SHOULD be taken into account in subsequent revisions of
+   the local module.
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 28]
+
+RFC 3780                         SMIng                          May 2004
+
+
+7.6.  The typedef's description Statement
+
+   The typedef's `description' statement, which must be present, gets
+   one argument which is used to specify a high-level textual
+   description of the newly defined type.
+
+   It is RECOMMENDED that all semantic definitions necessary for
+   implementation, and to embody any information which would otherwise
+   be communicated in any commentary annotations associated with this
+   type definition be included.
+
+7.7.  The typedef's reference Statement
+
+   The typedef's `reference' statement, which need not be present, gets
+   one argument which is used to specify a textual cross-reference to
+   some other document, either another module which defines related type
+   definitions, or some other document which provides additional
+   information relevant to this type definition.
+
+7.8.  Usage Examples
+
+   typedef RptrOperStatus {
+     type            Enumeration (other(1), ok(2), rptrFailure(3),
+                                  groupFailure(4), portFailure(5),
+                                  generalFailure(6));
+     default         other;       // undefined by default.
+     status          deprecated;
+     description
+             "A type to indicate the operational state
+              of a repeater.";
+     reference
+             "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState.";
+   };
+
+   typedef SnmpTransportDomain {
+     type            Pointer (snmpTransportDomain);
+     status          current;
+     description
+             "A pointer to an SNMP transport domain identity.";
+   };
+
+   typedef DateAndTime {
+     type            OctetString (8 | 11);
+     format          "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
+     status          current;
+     description
+             "A date-time specification.
+              ...
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 29]
+
+RFC 3780                         SMIng                          May 2004
+
+
+              Note that if only local time is known, then timezone
+              information (fields 8-10) is not present.";
+     reference
+             "RFC 2579, SNMPv2-TC.DateAndTime.";
+   };
+
+   typedef Frequency {
+     type            Unsigned64;
+     format          "d-3"
+     units           "Hertz";
+     status          current;
+     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 B)
+   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
+   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.
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 30]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   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.
+
+8.3.  The identity' description Statement
+
+   The identity's `description' statement, which must be present, gets
+   one argument which is used to specify a high-level textual
+   description of the newly defined identity.
+
+   It is RECOMMENDED that 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 be included.
+
+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.";
+   };
+
+   identity snmpTransportDomain {
+     status  current;
+     description
+             "A generic SNMP transport domain identity.";
+   };
+
+   identity snmpUDPDomain {
+     parent  snmpTransportDomain;
+     status  current;
+     description
+             "The SNMP over UDP transport domain.";
+   };
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 31]
+
+RFC 3780                         SMIng                          May 2004
+
+
+9.  The class Statement
+
+   The `class' statement is used to define a new class that represents a
+   container of related attributes and events (Section 9.2, Section
+   9.4).  A class can be defined either from scratch or derived from a
+   parent class.  A derived class inherits all attributes and events of
+   the parent class and can be extended by additional attributes and
+   events.
+
+   The `class' statement gets the following two arguments: The first
+   argument is an upper-case class identifier.  The second argument is a
+   statement block that holds detailed class information in an
+   obligatory order.
+
+   See the `classStatement' rule of the SMIng grammar (Appendix B) for
+   the formal syntax of the `class' statement.
+
+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
+   described in Section 3.
+
+9.2.2.  The attribute's access Statement
+
+   The attribute's `access' statement must be present for 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 to
+   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
+   maximal level of access for the attribute.  This maximal level of
+   access is independent of any administrative authorization policy.
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 32]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   The value `readwrite' indicates that read and write access makes
+   sense.  The value `readonly' indicates that read access makes sense,
+   but write access is never possible.  The value `eventonly' indicates
+   an object which is accessible only via an event.
+
+   These values are ordered, from least to greatest access level:
+   `eventonly', `readonly', `readwrite'.
+
+9.2.3.  The attribute's default Statement
+
+   The attribute's `default' statement need not be present for
+   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
+   to specify an acceptable default value for this attribute.  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 attribute's `type'
+   statement.
+
+   The attribute's default value overrides the default value of the
+   underlying type definition if both are present.
+
+9.2.4.  The attribute's format Statement
+
+   The attribute's `format' statement need not be present for 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 to
+   give a hint as to how the value of an instance of this attribute
+   might be displayed.  See Section 3.13 for a description of format
+   specifications.
+
+   The attribute's format specification overrides the format
+   specification of the underlying type definition if both are present.
+
+9.2.5.  The attribute's units Statement
+
+   The attribute's `units' statement need not be present for 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 to
+   specify a textual definition of the units associated with this
+   attribute.
+
+   The attribute's units specification overrides the units specification
+   of the underlying type definition if both are present.
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 33]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   The units specification has to be appropriate for values displayed
+   according to the attribute's format specification if present.  For
+   example, if the attribute represents a frequency value of type
+   Unsigned64 measured in thousands of Hertz, the format specification
+   should be `d-3' and the units specification should be `Hertz' or
+   `Hz'.  If the format specification would be omitted, the units
+   specification should be `Milli-Hertz' or `mHz'.  Authors of SMIng
+   modules should pay attention to keep format and units specifications
+   of type and attribute definitions in sync.  Application implementors
+   MUST NOT implement units specifications without implementing format
+   specifications.
+
+9.2.6.  The attribute's status Statement
+
+   The attribute's `status' statement must be present.  It gets one
+   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
+   containing 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.
+
+   It is RECOMMENDED that all semantic definitions necessary for the
+   implementation of this attribute be included.
+
+9.2.8.  The attribute's reference Statement
+
+   The attribute'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
+   attribute definitions, or some other document which provides
+   additional information relevant to this attribute definition.
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 34]
+
+RFC 3780                         SMIng                          May 2004
+
+
+9.3.  The class' unique Statement
+
+   The class' `unique' statement, which need not be present, gets one
+   argument that specifies a comma-separated list of attributes of this
+   class, enclosed in parenthesis.  If present, this list of attributes
+   makes up a unique identification of all possible instances of this
+   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
+   with only a single instance.
+
+   If the `unique' statement is not present, the class is not meant to
+   be instantiated directly, but to be contained in other classes or the
+   parent class of other refining classes.
+
+   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 B) 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
+   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.
+
+9.4.2.  The event's description Statement
+
+   The event's `description' statement, which must be present, gets one
+   argument which is used to specify a high-level textual description of
+   this event.
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 35]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   It is RECOMMENDED that all semantic definitions necessary for the
+   implementation of this event be included.  In particular, which
+   instance of the class is associated with an event of this type SHOULD
+   be documented.
+
+9.4.3.  The event's reference Statement
+
+   The event'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
+   event definitions, or some other document which provides additional
+   information relevant to this event definition.
+
+9.5.  The class' status Statement
+
+   The class' `status' statement, which must be present, gets one
+   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 that all semantic definitions necessary for
+   implementation, and to embody any information which would otherwise
+   be communicated in any commentary annotations associated with this
+   class definition be included.
+
+
+
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 36]
+
+RFC 3780                         SMIng                          May 2004
+
+
+9.7.  The class' reference Statement
+
+   The class' `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 class
+   definitions, or some other document which provides additional
+   information relevant to this class definition.
+
+9.8.  Usage Example
+
+   Consider how an event might be described that signals a status change
+   of an interface:
+
+   class Interface {
+     // ...
+     attribute speed {
+       type        Gauge32;
+       access      readonly;
+       units       "bps";
+       status      current;
+       description
+            "An estimate of the interface's current bandwidth
+             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
+                attribute for this interface instance is about to
+                enter the down state from some other state (but not
+                from the notPresent state).  This other state is
+                indicated by the included value of ifOperStatus.";
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 37]
+
+RFC 3780                         SMIng                          May 2004
+
+
+     };
+
+     status        current;
+     description
+               "A physical or logical network interface.";
+
+   };
+
+10.  Extending a Module
+
+   As experience is gained with a module, it may be desirable to revise
+   that module.  However, changes are not allowed if they have any
+   potential to cause interoperability problems between an
+   implementation using an original specification and an implementation
+   using an updated specification(s).
+
+   For any change, some statements near the top of the module MUST be
+   updated to include information about the revision: specifically, a
+   new `revision' statement (Section 5.6) must be included in front of
+   the `revision' statements.  Furthermore, any necessary changes MUST
+   be applied to other statements, including the `organization' and
+   `contact' statements (Section 5.2, Section 5.3).
+
+   Note that any definition contained in a module is available to be
+   imported by any other module, and is referenced in an `import'
+   statement via the module name.  Thus, a module name MUST NOT be
+   changed.  Specifically, the module name (e.g., `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
+      values, and has identical semantics.
+
+   o  In `attribute' statements where the `type' sub-statement specifies
+      a class, the class may be replaced by another class if the new
+      class is derived (directly or indirectly) from the base class and
+      both classes have identical semantics.
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 38]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   o  In `attribute' statements where the `type' sub-statement specifies
+      a base type, a defined type, or an implicitly derived type (i.e.,
+      not a class), that type may be replaced by another type if the new
+      type is derived (directly or indirectly) from the same base type,
+      has the same set of values, and has identical semantics.
+
+   o  In any statement block, a `status' statement value of `current'
+      may be revised as `deprecated' or `obsolete'.  Similarly, a
+      `status' statement value of `deprecated' may be revised as
+      `obsolete'.  When making such a change, the `description'
+      statement SHOULD be updated to explain the rationale.
+
+   o  In `typedef' and `attribute' statement blocks, a `default'
+      statement may be added or updated.
+
+   o  In `typedef' and `attribute' statement blocks, a `units' statement
+      may be added.
+
+   o  A class may be augmented by adding new attributes.
+
+   o  In any statement block, clarifications and additional information
+      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
+   (Section 5 through Section 9.4) that are used to specify those
+   aspects of management information commonly regarded as necessary
+   without management protocol specific information, there may be
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 39]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   further information people wish to express.  Describing additional
+   information informally in description statements has a disadvantage
+   in that this information cannot be parsed by any program.
+
+   SMIng allows modules to include statements that are unknown to a
+   parser but fulfil some core grammar rules (Section 4.3).
+   Furthermore, additional statements may be defined by the `extension'
+   statement (Section 6).  Extensions can be used in the local module or
+   in other modules that import the extension.  This has some
+   advantages:
+
+   o  A parser can differentiate between statements known as extensions
+      and unknown statements.  This enables the parser to complain about
+      unknown statements, e.g., due to typos.
+
+   o  If an extension's definition contains a formal ABNF grammar
+      definition and a parser is able to interpret this ABNF definition,
+      this enables the parser to also complain about the wrong usage of
+      an extension.
+
+   o  Since there might be some common need for extensions, there is a
+      relatively high probability of extension name collisions
+      originated by different organizations, as long as there is no
+      standardized extension for that purpose.  The requirement to
+      explicitly import extension statements allows those extensions to
+      be distinguished.
+
+   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 status, and optionally its ABNF grammar.
+   All additional aspects SHOULD be described in the `description'
+   statement:
+
+   o  The detailed semantics of the new statement SHOULD be described.
+
+   o  The contexts in which the new statement can be used SHOULD be
+      described, e.g., a new statement may be designed to be used only
+      in the statement block of a module, but not in other nested
+      statement blocks.  Others may be applicable in multiple contexts.
+      In addition, the point in the sequence of an obligatory order of
+      other statements, where the new statement may be inserted, might
+      be prescribed.
+
+   o  The circumstances that make the new statement mandatory or
+      optional SHOULD be described.
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 40]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   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 [RFC3781]
+      framework is defined as an SMIng extension.  Other mappings may
+      follow in the future.
+
+   o  Inlined annotations to definitions.  For example, 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.  For example, a
+      vendor may wish to describe additional information to definitions
+      in a "standard" module.  This allows a vendor to implement
+      "standard" modules as well as additional private features, without
+      redundant module definitions, but on top of "standard" module
+      definitions.
+
+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, Keith McCloghrie, and Bert Wijnen.
+
+   Furthermore, several discussions within the SMING Working Group
+   reflected experience with SMIv2 and influenced this specification at
+   some points.
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 41]
+
+RFC 3780                         SMIng                          May 2004
+
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+14.2.  Informative References
+
+   [RFC3216]  Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J.,
+              Strauss, F. and W. Weiss, "SMIng Objectives", RFC 3216,
+              December 2001.
+
+   [RFC3781]  Strauss, F. and J. Schoenwaelder, "Next Generation
+              Structure of Management Information (SMIng) Mappings to
+              the Simple Network Management Protocol (SNMP)", RFC 3781,
+              May 2004.
+
+   [RFC2578]  McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+              "Structure of Management Information Version 2 (SMIv2)",
+              STD 58, RFC 2578, April 1999.
+
+   [RFC2579]  McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual
+              Conventions for SMIv2", STD 59, RFC 2579, April 1999.
+
+   [RFC2580]  McCloghrie, K., Perkins, D. and J. Schoenwaelder,
+              "Conformance Statements for SMIv2", STD 60, RFC 2580,
+              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", STD
+              16, RFC 1155, May 1990.
+
+   [RFC1212]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
+              16, RFC 1212, March 1991.
+
+   [RFC1215]  Rose, M., "A Convention for Defining Traps for use with
+              the SNMP", RFC 1215, March 1991.
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 42]
+
+RFC 3780                         SMIng                          May 2004
+
+
+   [ASN1]     International Organization for Standardization,
+              "Specification of Abstract Syntax Notation One (ASN.1)",
+              International Standard 8824, December 1987.
+
+   [RFC3411]  Harrington, D., Presuhn, R. and B. Wijnen, "An
+              Architecture for Describing Simple Network Management
+              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
+              December 2002.
+
+   [IEEE754]  Institute of Electrical and Electronics Engineers, "IEEE
+              Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
+              Standard 754-1985, August 1985.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3084]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
+              K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith,
+              "COPS Usage for Policy Provisioning", RFC 3084, March
+              2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 43]
+
+RFC 3780                         SMIng                          May 2004
+
+
+Appendix A. NMRG-SMING Module
+
+   Most SMIng modules are built on top of the definitions of some
+   commonly used derived types.  The definitions of these derived types
+   are contained in the NMRG-SMING module which is defined below.  Its
+   derived types are generally applicable for modeling all areas of
+   management information.  Among these derived types are counter types,
+   string types, and date and time related types.
+
+   This module is derived from RFC 2578 [RFC2578] and RFC 2579
+   [RFC2579].
+
+module NMRG-SMING {
+
+    organization    "IRTF Network Management Research Group (NMRG)";
+
+    contact         "IRTF Network Management Research Group (NMRG)
+                     http://www.ibr.cs.tu-bs.de/projects/nmrg/
+
+                     Frank Strauss
+                     TU Braunschweig
+                     Muehlenpfordtstrasse 23
+                     38106 Braunschweig
+                     Germany
+                     Phone: +49 531 391 3266
+                     EMail: strauss@ibr.cs.tu-bs.de
+
+                     Juergen Schoenwaelder
+                     International University Bremen
+                     P.O. Box 750 561
+                     28725 Bremen
+                     Germany
+                     Phone: +49 421 200 3587
+                     EMail: j.schoenwaelder@iu-bremen.de";
+
+    description     "Core type definitions for SMIng. Several
+                     type definitions are SMIng versions of
+                     similar SMIv2 or SPPI definitions.
+
+                     Copyright (C) The Internet Society (2004).
+                     All Rights Reserved.
+                     This version of this module is part of
+                     RFC 3780, see the RFC itself for full
+                     legal notices.";
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 44]
+
+RFC 3780                         SMIng                          May 2004
+
+
+    revision {
+        date        "2003-12-16";
+        description "Initial revision, published as RFC 3780.";
+    };
+
+    typedef Gauge32 {
+        type        Unsigned32;
+        description
+           "The Gauge32 type represents a non-negative integer,
+            which may increase or decrease, but shall never
+            exceed a maximum value, nor fall below a minimum
+            value.  The maximum value can not be greater than
+            2^32-1 (4294967295 decimal), and the minimum value
+            can not be smaller than 0.  The value of a Gauge32
+            has its maximum value whenever the information
+            being modeled is greater than or equal to its
+            maximum value, and has its minimum value whenever
+            the information being modeled is smaller than or
+            equal to its minimum value.  If the information
+            being modeled subsequently decreases below
+            (increases above) the maximum (minimum) value, the
+            Gauge32 also decreases (increases).";
+        reference
+           "RFC 2578, Sections 2. and 7.1.7.";
+    };
+
+    typedef Counter32 {
+        type        Unsigned32;
+        description
+           "The Counter32 type represents a non-negative integer
+            which monotonically increases until it reaches a
+            maximum value of 2^32-1 (4294967295 decimal), when it
+            wraps around and starts increasing again from zero.
+
+            Counters have no defined `initial' value, and thus, a
+            single value of a Counter has (in general) no information
+            content.  Discontinuities in the monotonically increasing
+            value normally occur at re-initialization of the
+            management system, and at other times as specified in the
+            description of an attribute using this type.  If such
+            other times can occur, for example, the creation of a
+            class instance that contains an attribute of type
+            Counter32 at times other than re-initialization, then a
+            corresponding attribute should be defined, with an
+            appropriate type, to indicate the last discontinuity.
+            Examples of appropriate types include: TimeStamp32,
+            TimeStamp64, DateAndTime, TimeTicks32 or TimeTicks64
+            (other types defined in this module).
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 45]
+
+RFC 3780                         SMIng                          May 2004
+
+
+            The value of the access statement for attributes with
+            a type value of Counter32 should be either `readonly'
+            or `eventonly'.
+
+            A default statement should not be used for attributes
+            with a type value of Counter32.";
+        reference
+           "RFC 2578, Sections 2. and 7.1.6.";
+    };
+
+    typedef Gauge64 {
+        type        Unsigned64;
+        description
+           "The Gauge64 type represents a non-negative integer,
+            which may increase or decrease, but shall never
+            exceed a maximum value, nor fall below a minimum
+            value.  The maximum value can not be greater than
+            2^64-1 (18446744073709551615), and the minimum value
+            can not be smaller than 0.  The value of a Gauge64
+            has its maximum value whenever the information
+            being modeled is greater than or equal to its
+            maximum value, and has its minimum value whenever
+            the information being modeled is smaller than or
+            equal to its minimum value.  If the information
+            being modeled subsequently decreases below
+            (increases above) the maximum (minimum) value, the
+            Gauge64 also decreases (increases).";
+    };
+
+    typedef Counter64 {
+        type        Unsigned64;
+        description
+           "The Counter64 type represents a non-negative integer
+            which monotonically increases until it reaches a
+            maximum value of 2^64-1 (18446744073709551615), when
+            it wraps around and starts increasing again from zero.
+
+            Counters have no defined `initial' value, and thus, a
+            single value of a Counter has (in general) no
+            information content.  Discontinuities in the
+            monotonically increasing value normally occur at
+            re-initialization of the management system, and at
+            other times as specified in the description of an
+            attribute using this type.  If such other times can
+            occur, for example, the creation of a class
+            instance that contains an attribute of type Counter32
+            at times other than re-initialization, then
+            a corresponding attribute should be defined, with an
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 46]
+
+RFC 3780                         SMIng                          May 2004
+
+
+            appropriate type, to indicate the last discontinuity.
+            Examples of appropriate types include: TimeStamp32,
+            TimeStamp64, DateAndTime, TimeTicks32 or TimeTicks64
+            (other types defined in this module).
+
+            The value of the access statement for attributes with
+            a type value of Counter64 should be either `readonly'
+            or `eventonly'.
+
+            A default statement should not be used for attributes
+            with a type value of Counter64.";
+        reference
+           "RFC 2578, Sections 2. and 7.1.10.";
+    };
+
+    typedef Opaque {
+        type        OctetString;
+        status      obsolete;
+        description
+           "******* THIS TYPE DEFINITION IS OBSOLETE *******
+
+            The Opaque type is provided solely for
+            backward-compatibility, and shall not be used for
+            newly-defined attributes and derived types.
+
+            The Opaque type supports the capability to pass
+            arbitrary ASN.1 syntax.  A value is encoded using
+            the ASN.1 Basic Encoding Rules into a string of
+            octets.  This, in turn, is encoded as an
+            OctetString, in effect `double-wrapping' the
+            original ASN.1 value.
+
+            Note that a conforming implementation need only be
+            able to accept and recognize opaquely-encoded data.
+            It need not be able to unwrap the data and then
+            interpret its contents.
+
+            A requirement on `standard' modules is that no
+            attribute may have a type value of Opaque and no
+            type may be derived from the Opaque type.";
+        reference
+           "RFC 2578, Sections 2. and 7.1.9.";
+    };
+
+    typedef IpAddress {
+        type        OctetString (4);
+        status      deprecated;
+        description
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 47]
+
+RFC 3780                         SMIng                          May 2004
+
+
+           "******* THIS TYPE DEFINITION IS DEPRECATED *******
+
+            The IpAddress type represents a 32-bit Internet
+            IPv4 address.  It is represented as an OctetString
+            of length 4, in network byte-order.
+
+            Note that the IpAddress type is present for
+            historical reasons.";
+        reference
+           "RFC 2578, Sections 2. and 7.1.5.";
+    };
+
+    typedef TimeTicks32 {
+        type        Unsigned32;
+        description
+           "The TimeTicks32 type represents a non-negative integer
+            which represents the time, modulo 2^32 (4294967296
+            decimal), in hundredths of a second between two epochs.
+            When attributes are defined which use this type, the
+            description of the attribute identifies both of the
+            reference epochs.
+
+            For example, the TimeStamp32 type (defined in this
+            module) is based on the TimeTicks32 type.";
+        reference
+           "RFC 2578, Sections 2. and 7.1.8.";
+    };
+
+    typedef TimeTicks64 {
+        type        Unsigned64;
+        description
+           "The TimeTicks64 type represents a non-negative integer
+            which represents the time, modulo 2^64
+            (18446744073709551616 decimal), in hundredths of a second
+            between two epochs.  When attributes are defined which use
+            this type, the description of the attribute identifies
+            both of the reference epochs.
+
+            For example, the TimeStamp64 type (defined in this
+            module) is based on the TimeTicks64 type.";
+    };
+
+    typedef TimeStamp32 {
+        type        TimeTicks32;
+        description
+           "The value of an associated TimeTicks32 attribute at
+            which a specific occurrence happened.  The specific
+            occurrence must be defined in the description of any
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 48]
+
+RFC 3780                         SMIng                          May 2004
+
+
+            attribute defined using this type.  When the specific
+            occurrence occurred prior to the last time the
+            associated TimeTicks32 attribute was zero, then the
+            TimeStamp32 value is zero.  Note that this requires all
+            TimeStamp32 values to be reset to zero when the value of
+            the associated TimeTicks32 attribute reaches 497+ days
+            and wraps around to zero.
+
+            The associated TimeTicks32 attribute should be specified
+            in the description of any attribute using this type.
+            If no TimeTicks32 attribute has been specified, the
+            default scalar attribute sysUpTime is used.";
+        reference
+           "RFC 2579, Section 2.";
+    };
+
+    typedef TimeStamp64 {
+        type        TimeTicks64;
+        description
+           "The value of an associated TimeTicks64 attribute at which
+            a specific occurrence happened.  The specific occurrence
+            must be defined in the description of any attribute
+            defined using this type.  When the specific occurrence
+            occurred prior to the last time the associated TimeTicks64
+            attribute was zero, then the TimeStamp64 value is zero.
+            The associated TimeTicks64 attribute must be specified in
+            the description of any attribute using this
+            type. TimeTicks32 attributes must not be used as
+            associated attributes.";
+    };
+
+    typedef TimeInterval32 {
+        type        Integer32 (0..2147483647);
+        description
+           "A period of time, measured in units of 0.01 seconds.
+
+            The TimeInterval32 type uses Integer32 rather than
+            Unsigned32 for compatibility with RFC 2579.";
+        reference
+           "RFC 2579, Section 2.";
+    };
+
+    typedef TimeInterval64 {
+        type        Integer64;
+        description
+           "A period of time, measured in units of 0.01 seconds.
+            Note that negative values are allowed.";
+    };
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 49]
+
+RFC 3780                         SMIng                          May 2004
+
+
+    typedef DateAndTime {
+        type        OctetString (8 | 11);
+        default     0x0000000000000000000000;
+        format      "2d-1d-1d,1d:1d:1d.1d,1a1d:1d";
+        description
+           "A date-time specification.
+
+            field  octets  contents                  range
+            -----  ------  --------                  -----
+             1      1-2   year*                     0..65535
+             2       3    month                     1..12 | 0
+             3       4    day                       1..31 | 0
+             4       5    hour                      0..23
+             5       6    minutes                   0..59
+             6       7    seconds                   0..60
+                          (use 60 for leap-second)
+             7       8    deci-seconds              0..9
+             8       9    direction from UTC        '+' / '-'
+             9      10    hours from UTC*           0..13
+            10      11    minutes from UTC          0..59
+
+            * Notes:
+            - the value of year is in big-endian encoding
+            - daylight saving time in New Zealand is +13
+
+            For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would
+            be displayed as:
+
+                         1992-5-26,13:30:15.0,-4:0
+
+            Note that if only local time is known, then timezone
+            information (fields 8-10) is not present.
+
+            The two special values of 8 or 11 zero bytes denote an
+            unknown date-time specification.";
+        reference
+           "RFC 2579, Section 2.";
+    };
+
+    typedef TruthValue {
+        type        Enumeration (true(1), false(2));
+        description
+           "Represents a boolean value.";
+        reference
+           "RFC 2579, Section 2.";
+    };
+
+    typedef PhysAddress {
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 50]
+
+RFC 3780                         SMIng                          May 2004
+
+
+        type        OctetString;
+        format      "1x:";
+        description
+           "Represents media- or physical-level addresses.";
+        reference
+           "RFC 2579, Section 2.";
+    };
+
+    typedef MacAddress {
+        type        OctetString (6);
+        format      "1x:";
+        description
+           "Represents an IEEE 802 MAC address represented in the
+            `canonical' order defined by IEEE 802.1a, i.e., as if it
+            were transmitted least significant bit first, even though
+            802.5 (in contrast to other 802.x protocols) requires MAC
+            addresses to be transmitted most significant bit first.";
+        reference
+           "RFC 2579, Section 2.";
+    };
+
+    // The DisplayString definition below does not impose a size
+    // restriction and is thus not the same as the DisplayString
+    // definition in RFC 2579. The DisplayString255 definition is
+    // provided for mapping purposes.
+
+    typedef DisplayString {
+        type        OctetString;
+        format      "1a";
+        description
+           "Represents textual information taken from the NVT ASCII
+            character set, as defined in pages 4, 10-11 of RFC 854.
+
+            To summarize RFC 854, the NVT ASCII repertoire specifies:
+
+             - the use of character codes 0-127 (decimal)
+
+             - the graphics characters (32-126) are interpreted as
+               US ASCII
+
+             - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
+               meanings specified in RFC 854
+
+             - the other 25 codes have no standard interpretation
+
+             - the sequence 'CR LF' means newline
+
+             - the sequence 'CR NUL' means carriage-return
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 51]
+
+RFC 3780                         SMIng                          May 2004
+
+
+             - an 'LF' not preceded by a 'CR' means moving to the
+               same column on the next line.
+
+             - the sequence 'CR x' for any x other than LF or NUL is
+               illegal.  (Note that this also means that a string may
+               end with either 'CR LF' or 'CR NUL', but not with CR.)
+        ";
+    };
+
+    typedef DisplayString255 {
+        type        DisplayString (0..255);
+        description
+           "A DisplayString with a maximum length of 255 characters.
+            Any attribute defined using this syntax may not exceed 255
+            characters in length.
+
+            The DisplayString255 type has the same semantics as the
+            DisplayString textual convention defined in RFC 2579.";
+        reference
+           "RFC 2579, Section 2.";
+    };
+
+    // The Utf8String and Utf8String255 definitions below facilitate
+    // internationalization. The definition is consistent with the
+    // definition of SnmpAdminString in RFC 2571.
+
+    typedef Utf8String {
+        type        OctetString;
+        format      "65535t";      // is there a better way ?
+        description
+           "A human readable string represented using the ISO/IEC IS
+            10646-1 character set, encoded as an octet string using
+            the UTF-8 transformation format described in RFC 3629.
+
+            Since additional code points are added by amendments to
+            the 10646 standard from time to time, implementations must
+            be prepared to encounter any code point from 0x00000000 to
+            0x7fffffff.  Byte sequences that do not correspond to the
+            valid UTF-8 encoding of a code point or are outside this
+            range are prohibited.
+
+            The use of control codes should be avoided. When it is
+            necessary to represent a newline, the control code
+            sequence CR LF should be used.
+
+            The use of leading or trailing white space should be
+            avoided.
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 52]
+
+RFC 3780                         SMIng                          May 2004
+
+
+            For code points not directly supported by user interface
+            hardware or software, an alternative means of entry and
+            display, such as hexadecimal, may be provided.
+
+            For information encoded in 7-bit US-ASCII, the UTF-8
+            encoding is identical to the US-ASCII encoding.
+
+            UTF-8 may require multiple bytes to represent a single
+            character / code point; thus the length of a Utf8String in
+            octets may be different from the number of characters
+            encoded.  Similarly, size constraints refer to the number
+            of encoded octets, not the number of characters
+            represented by an encoding.";
+    };
+
+    typedef Utf8String255 {
+        type        Utf8String (0..255);
+        format      "255t";
+        description
+           "A Utf8String with a maximum length of 255 octets.  Note
+            that the size of an Utf8String is measured in octets, not
+            characters.";
+    };
+
+    identity null {
+        description
+           "An identity used to represent null pointer values.";
+    };
+
+};
+
+Appendix B. 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.33 2003/10/23 19:31:55 strauss Exp $
+;;
+;; Copyright (C) The Internet Society (2004). All Rights Reserved.
+;;
+
+smingFile               = optsep *(moduleStatement optsep)
+
+;;
+;; Statement rules.
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 53]
+
+RFC 3780                         SMIng                          May 2004
+
+
+;;
+
+moduleStatement         = moduleKeyword sep ucIdentifier optsep
+                              "{" stmtsep
+                              *(importStatement stmtsep)
+                              organizationStatement stmtsep
+                              contactStatement stmtsep
+                              descriptionStatement stmtsep
+                              *1(referenceStatement stmtsep)
+                              1*(revisionStatement stmtsep)
+                              *(extensionStatement stmtsep)
+                              *(typedefStatement stmtsep)
+                              *(identityStatement stmtsep)
+                              *(classStatement stmtsep)
+                          "}" optsep ";"
+
+extensionStatement      = extensionKeyword sep lcIdentifier optsep
+                              "{" stmtsep
+                              statusStatement stmtsep
+                              descriptionStatement stmtsep
+                              *1(referenceStatement stmtsep)
+                              *1(abnfStatement stmtsep)
+                          "}" optsep ";"
+
+typedefStatement        = typedefKeyword sep ucIdentifier optsep
+                              "{" stmtsep
+                              typedefTypeStatement stmtsep
+                              *1(defaultStatement stmtsep)
+                              *1(formatStatement stmtsep)
+                              *1(unitsStatement stmtsep)
+                              statusStatement stmtsep
+                              descriptionStatement stmtsep
+                              *1(referenceStatement stmtsep)
+                          "}" optsep ";"
+
+identityStatement       = identityStmtKeyword sep lcIdentifier optsep
+                              "{" stmtsep
+                              *1(parentStatement stmtsep)
+                              statusStatement stmtsep
+                              descriptionStatement stmtsep
+                              *1(referenceStatement stmtsep)
+                          "}" optsep ";"
+
+classStatement          = classKeyword sep ucIdentifier optsep
+                              "{" stmtsep
+                              *1(extendsStatement stmtsep)
+                              *(attributeStatement stmtsep)
+                              *1(uniqueStatement stmtsep)
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 54]
+
+RFC 3780                         SMIng                          May 2004
+
+
+                              *(eventStatement stmtsep)
+                              statusStatement stmtsep
+                              descriptionStatement stmtsep
+                              *1(referenceStatement stmtsep)
+                          "}" optsep ";"
+
+attributeStatement      = attributeKeyword sep
+                              lcIdentifier optsep
+                              "{" stmtsep
+                              typeStatement stmtsep
+                              *1(accessStatement stmtsep)
+                              *1(defaultStatement stmtsep)
+                              *1(formatStatement stmtsep)
+                              *1(unitsStatement stmtsep)
+                              statusStatement stmtsep
+                              descriptionStatement stmtsep
+                              *1(referenceStatement stmtsep)
+                          "}" optsep ";"
+
+uniqueStatement         = uniqueKeyword optsep
+                              "(" optsep qlcIdentifierList
+                              optsep ")" optsep ";"
+
+eventStatement          = eventKeyword sep lcIdentifier
+                              optsep "{" stmtsep
+                              statusStatement stmtsep
+                              descriptionStatement stmtsep
+                              *1(referenceStatement stmtsep)
+                          "}" optsep ";"
+
+importStatement         = importKeyword sep ucIdentifier optsep
+                              "(" optsep
+                              identifierList optsep
+                          ")" optsep ";"
+
+revisionStatement       = revisionKeyword optsep "{" stmtsep
+                              dateStatement stmtsep
+                              descriptionStatement stmtsep
+                          "}" optsep ";"
+
+typedefTypeStatement    = typeKeyword sep refinedBaseType optsep ";"
+
+typeStatement           = typeKeyword sep
+                          (refinedBaseType / refinedType) optsep ";"
+
+parentStatement         = parentKeyword sep qlcIdentifier optsep ";"
+
+extendsStatement        = extendsKeyword sep qucIdentifier optsep ";"
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 55]
+
+RFC 3780                         SMIng                          May 2004
+
+
+dateStatement           = dateKeyword sep date optsep ";"
+
+organizationStatement   = organizationKeyword sep text optsep ";"
+
+contactStatement        = contactKeyword sep text optsep ";"
+
+formatStatement         = formatKeyword sep format optsep ";"
+
+unitsStatement          = unitsKeyword sep units optsep ";"
+
+statusStatement         = statusKeyword sep status optsep ";"
+
+accessStatement         = accessKeyword sep access optsep ";"
+
+defaultStatement        = defaultKeyword sep anyValue optsep ";"
+
+descriptionStatement    = descriptionKeyword sep text optsep ";"
+
+referenceStatement      = referenceKeyword sep text optsep ";"
+
+abnfStatement           = abnfKeyword sep text optsep ";"
+
+;;
+;;
+;;
+
+refinedBaseType         = ObjectIdentifierKeyword /
+                          OctetStringKeyword *1(optsep numberSpec) /
+                          PointerKeyword *1(optsep pointerSpec) /
+                          Integer32Keyword *1(optsep numberSpec) /
+                          Unsigned32Keyword *1(optsep numberSpec) /
+                          Integer64Keyword *1(optsep numberSpec) /
+                          Unsigned64Keyword *1(optsep numberSpec) /
+                          Float32Keyword *1(optsep floatSpec) /
+                          Float64Keyword *1(optsep floatSpec) /
+                          Float128Keyword *1(optsep floatSpec) /
+                          EnumerationKeyword
+                                      optsep namedSignedNumberSpec /
+                          BitsKeyword optsep namedNumberSpec
+
+refinedType             = qucIdentifier *1(optsep anySpec)
+
+anySpec                 = pointerSpec / numberSpec / floatSpec
+
+pointerSpec             = "(" optsep qlcIdentifier optsep ")"
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 56]
+
+RFC 3780                         SMIng                          May 2004
+
+
+numberSpec              = "(" optsep numberElement
+                              *furtherNumberElement
+                              optsep ")"
+
+furtherNumberElement    = optsep "|" optsep numberElement
+
+numberElement           = signedNumber *1numberUpperLimit
+
+numberUpperLimit        = optsep ".." optsep signedNumber
+
+floatSpec               = "(" optsep floatElement
+                              *furtherFloatElement
+                              optsep ")"
+
+furtherFloatElement     = optsep "|" optsep floatElement
+
+floatElement            = floatValue *1floatUpperLimit
+
+floatUpperLimit         = optsep ".." optsep floatValue
+
+namedNumberSpec         = "(" optsep namedNumberList optsep ")"
+
+namedNumberList         = namedNumberItem
+                              *(optsep "," optsep namedNumberItem)
+
+namedNumberItem         = lcIdentifier optsep "(" optsep number
+                              optsep ")"
+
+namedSignedNumberSpec   = "(" optsep namedSignedNumberList optsep ")"
+
+namedSignedNumberList   = namedSignedNumberItem
+                              *(optsep "," optsep
+                                           namedSignedNumberItem)
+
+namedSignedNumberItem   = lcIdentifier optsep "(" optsep signedNumber
+                              optsep ")"
+
+identifierList          = identifier
+                              *(optsep "," optsep identifier)
+
+qIdentifierList         = qIdentifier
+                              *(optsep "," optsep qIdentifier)
+
+qlcIdentifierList       = qlcIdentifier
+                              *(optsep "," optsep qlcIdentifier)
+
+bitsValue               = "(" optsep bitsList optsep ")"
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 57]
+
+RFC 3780                         SMIng                          May 2004
+
+
+bitsList                = *1(lcIdentifier
+                              *(optsep "," optsep lcIdentifier))
+
+;;
+;; Other basic rules.
+;;
+
+identifier              = ucIdentifier / lcIdentifier
+
+qIdentifier             = qucIdentifier / qlcIdentifier
+
+ucIdentifier            = ucAlpha *63(ALPHA / DIGIT / "-")
+
+qucIdentifier           = *1(ucIdentifier "::") ucIdentifier
+
+lcIdentifier            = lcAlpha *63(ALPHA / DIGIT / "-")
+
+qlcIdentifier           = *1(ucIdentifier "::") lcIdentifier
+
+attrIdentifier          = lcIdentifier *("." lcIdentifier)
+
+qattrIdentifier         = *1(ucIdentifier ".") attrIdentifier
+
+cattrIdentifier         = ucIdentifier "."
+                              lcIdentifier *("." lcIdentifier)
+
+qcattrIdentifier        = qucIdentifier "."
+                              lcIdentifier *("." lcIdentifier)
+
+text                    = textSegment *(optsep textSegment)
+
+textSegment             = DQUOTE *textAtom DQUOTE
+                          ; See Section 4.2.
+
+textAtom                = textVChar / HTAB / SP / lineBreak
+
+date                    = DQUOTE 4DIGIT "-" 2DIGIT "-" 2DIGIT
+                              *1(" " 2DIGIT ":" 2DIGIT)
+                              DQUOTE
+                          ; always in UTC
+
+format                  = textSegment
+
+units                   = textSegment
+
+anyValue                = bitsValue /
+                          signedNumber /
+                          hexadecimalNumber /
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 58]
+
+RFC 3780                         SMIng                          May 2004
+
+
+                          floatValue /
+                          text /
+                          objectIdentifier
+                          ; Note: `objectIdentifier' includes the
+                          ; syntax of enumeration labels and
+                          ; identities.
+                          ; They are not named literally to
+                          ; avoid reduce/reduce conflicts when
+                          ; building LR parsers based on this
+                          ; grammar.
+
+status                  = currentKeyword /
+                          deprecatedKeyword /
+                          obsoleteKeyword
+
+access                  = eventonlyKeyword /
+                          readonlyKeyword /
+                          readwriteKeyword
+
+objectIdentifier        = (qlcIdentifier / subid "." subid)
+                              *127("." subid)
+
+subid                   = decimalNumber
+
+number                  = hexadecimalNumber / decimalNumber
+
+negativeNumber          = "-" decimalNumber
+
+signedNumber            = number / negativeNumber
+
+decimalNumber           = "0" / (nonZeroDigit *DIGIT)
+
+zeroDecimalNumber       = 1*DIGIT
+
+hexadecimalNumber       = %x30 %x78 ; "0x" with x only lower-case
+                          1*(HEXDIG HEXDIG)
+
+floatValue              = neginfKeyword /
+                          posinfKeyword /
+                          snanKeyword /
+                          qnanKeyword /
+                          signedNumber "." zeroDecimalNumber
+                              *1("E" ("+"/"-") zeroDecimalNumber)
+
+;;
+;; Rules to skip unknown statements
+;; with arbitrary arguments and blocks.
+;;
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 59]
+
+RFC 3780                         SMIng                          May 2004
+
+
+unknownStatement        = unknownKeyword optsep *unknownArgument
+                              optsep ";"
+
+unknownArgument         = ("(" optsep unknownList optsep ")") /
+                          ("{" optsep *unknownStatement optsep "}") /
+                          qucIdentifier /
+                          anyValue /
+                          anySpec
+
+unknownList             = namedNumberList /
+                          qIdentifierList
+
+unknownKeyword          = lcIdentifier
+
+;;
+;; Keyword rules.
+;;
+;; Typically, keywords are represented by tokens returned from the
+;; lexical analyzer.  Note, that the lexer has to be stateful to
+;; distinguish keywords from identifiers depending on the context
+;; position in the input stream.
+;;
+
+moduleKeyword       =  %x6D %x6F %x64 %x75 %x6C %x65
+importKeyword       =  %x69 %x6D %x70 %x6F %x72 %x74
+revisionKeyword     =  %x72 %x65 %x76 %x69 %x73 %x69 %x6F %x6E
+dateKeyword         =  %x64 %x61 %x74 %x65
+organizationKeyword =  %x6F %x72 %x67 %x61 %x6E %x69 %x7A %x61 %x74
+                       %x69 %x6F %x6E
+contactKeyword      =  %x63 %x6F %x6E %x74 %x61 %x63 %x74
+descriptionKeyword  =  %x64 %x65 %x73 %x63 %x72 %x69 %x70 %x74 %x69
+                       %x6F %x6E
+referenceKeyword    =  %x72 %x65 %x66 %x65 %x72 %x65 %x6E %x63 %x65
+extensionKeyword    =  %x65 %x78 %x74 %x65 %x6E %x73 %x69 %x6F %x6E
+typedefKeyword      =  %x74 %x79 %x70 %x65 %x64 %x65 %x66
+typeKeyword         =  %x74 %x79 %x70 %x65
+parentKeyword       =  %x70 %x61 %x72 %x65 %x6E %x74
+identityStmtKeyword =  %x69 %x64 %x65 %x6E %x74 %x69 %x74 %x79
+classKeyword        =  %x63 %x6C %x61 %x73 %x73
+extendsKeyword      =  %x65 %x78 %x74 %x65 %x6E %x64 %x73
+attributeKeyword    =  %x61 %x74 %x74 %x72 %x69 %x62 %x75 %x74 %x65
+uniqueKeyword       =  %x75 %x6E %x69 %x71 %x75 %x65
+eventKeyword        =  %x65 %x76 %x65 %x6E %x74
+formatKeyword       =  %x66 %x6F %x72 %x6D %x61 %x74
+unitsKeyword        =  %x75 %x6E %x69 %x74 %x73
+statusKeyword       =  %x73 %x74 %x61 %x74 %x75 %x73
+accessKeyword       =  %x61 %x63 %x63 %x65 %x73 %x73
+defaultKeyword      =  %x64 %x65 %x66 %x61 %x75 %x6C %x74
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 60]
+
+RFC 3780                         SMIng                          May 2004
+
+
+abnfKeyword         =  %x61 %x62 %x6E %x66
+
+;; Base type keywords.
+
+OctetStringKeyword  =  %x4F %x63 %x74 %x65 %x74 %x53 %x74 %x72 %x69
+                       %x6E %x67
+PointerKeyword      =  %x50 %x6F %x69 %x6E %x74 %x65 %x72
+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
+Unsigned32Keyword   =  %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x33
+                       %x32
+Integer64Keyword    =  %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x36 %x34
+Unsigned64Keyword   =  %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x36
+                       %x34
+Float32Keyword      =  %x46 %x6C %x6F %x61 %x74 %x33 %x32
+Float64Keyword      =  %x46 %x6C %x6F %x61 %x74 %x36 %x34
+Float128Keyword     =  %x46 %x6C %x6F %x61 %x74 %x31 %x32 %x38
+BitsKeyword         =  %x42 %x69 %x74 %x73
+EnumerationKeyword  =  %x45 %x6E %x75 %x6D %x65 %x72 %x61 %x74 %x69
+                       %x6F %x6E
+
+;; Status keywords.
+
+currentKeyword      =  %x63 %x75 %x72 %x72 %x65 %x6E %x74
+deprecatedKeyword   =  %x64 %x65 %x70 %x72 %x65 %x63 %x61 %x74 %x65
+                       %x64
+obsoleteKeyword     =  %x6F %x62 %x73 %x6F %x6C %x65 %x74 %x65
+
+;; Access keywords.
+
+eventonlyKeyword    =  %x65 %x76 %x65 %x6E %x74 %x6F %x6E %x6C %x79
+readonlyKeyword     =  %x72 %x65 %x61 %x64 %x6F %x6E %x6C %x79
+readwriteKeyword    =  %x72 %x65 %x61 %x64 %x77 %x72 %x69 %x74 %x65
+
+;; Special floating point values' keywords.
+
+neginfKeyword       =  %x6E %x65 %x67 %x69 %x6E %x66
+posinfKeyword       =  %x70 %x6F %x73 %x69 %x6E %x66
+snanKeyword         =  %x73 %x6E %x61 %x6E
+qnanKeyword         =  %x71 %x6E %x61 %x6E
+
+;;
+;; Some low level rules.
+;; These tokens are typically skipped by the lexical analyzer.
+;;
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 61]
+
+RFC 3780                         SMIng                          May 2004
+
+
+sep                     = 1*(comment / lineBreak / WSP)
+                          ; unconditional separator
+
+optsep                  = *(comment / lineBreak / WSP)
+
+stmtsep                 = *(comment /
+                            lineBreak /
+                            WSP /
+                            unknownStatement)
+
+comment                 = "//" *(WSP / VCHAR) lineBreak
+
+lineBreak               = CRLF / LF
+
+;;
+;; Encoding specific rules.
+;;
+
+textVChar               = %x21 / %x23-7E
+                          ; any VCHAR except DQUOTE
+
+ucAlpha                 = %x41-5A
+
+lcAlpha                 = %x61-7A
+
+nonZeroDigit            = %x31-39
+
+;;
+;; RFC 2234 core rules.
+;;
+
+ALPHA          =  %x41-5A / %x61-7A
+                       ; A-Z / a-z
+
+CR             =  %x0D
+                       ; carriage return
+
+CRLF           =  CR LF
+                       ; Internet standard newline
+
+DIGIT          =  %x30-39
+                       ; 0-9
+
+DQUOTE         =  %x22
+                       ; " (Double Quote)
+
+HEXDIG         =  DIGIT /
+                  %x61 / %x62 / %x63 / %x64 / %x65 / %x66
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 62]
+
+RFC 3780                         SMIng                          May 2004
+
+
+                       ; only lower-case a..f
+
+HTAB           =  %x09
+                       ; horizontal tab
+
+LF             =  %x0A
+                       ; linefeed
+
+SP             =  %x20
+                       ; space
+
+VCHAR          =  %x21-7E
+                       ; visible (printing) characters
+
+WSP            =  SP / HTAB
+                       ; white space
+
+;; End of ABNF
+
+Authors' Addresses
+
+   Frank Strauss
+   TU Braunschweig
+   Muehlenpfordtstrasse 23
+   38106 Braunschweig
+   Germany
+
+   Phone: +49 531 391 3266
+   EMail: strauss@ibr.cs.tu-bs.de
+   URI:   http://www.ibr.cs.tu-bs.de/
+
+   Juergen Schoenwaelder
+   International University Bremen
+   P.O. Box 750 561
+   28725 Bremen
+   Germany
+
+   Phone: +49 421 200 3587
+   EMail: j.schoenwaelder@iu-bremen.de
+   URI:   http://www.eecs.iu-bremen.de/
+
+
+
+
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 63]
+
+RFC 3780                         SMIng                          May 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Strauss & Schoenwaelder       Experimental                     [Page 64]
+