[nmrg] Re: SMIng documents ready (again) for experimental RFCs

[RFC Editor <[e-mail]>]

Greetings,

Thank you for your submissions.  The RFC Editor has received your
proposed RFCs, and will review the documents.  Once the RFC Editor has
reviewed these drafts, we will send them to the IESG for a 4 week
timeout, allowing the IESG time to review and comment on these
efforts. 

You can track the progress of your documents at:

   http://www.rfc-editor.org/queue.html

Please note that your documents will be removed from our queue and
treated as new submissions if we send them back to you for revisions. 

Thank you.

RFC Editor



On Tue, Nov 25, 2003 at 03:56:54PM +0100, Frank Strauss wrote:
> Hi!
> 
> On behalf of the NMRG, I would like to ask you to publish
>  
>         draft-irtf-nmrg-sming-06.txt
>         draft-irtf-nmrg-sming-modules-04.txt
>         draft-irtf-nmrg-sming-snmp-04.txt
> 
> as Experimental RFCs. These documents have been produced by the
> Network Management Research Group (NMRG) of the IRTF.
> 
> All three documents have already been in the RFC editor's queue in
> October. We got back a number of helpful comments. We have addressed
> all those comments in the new versions of the documents that I submit
> today.
> 
>  -frank
> 

> 
> 
> Network Working Group                                         F. Strauss
> Internet-Draft                                           TU Braunschweig
> Expires: April 28, 2004                                 J. Schoenwaelder
>                                          International University Bremen
>                                                         October 29, 2003
> 
> 
>       SMIng - Next Generation Structure of Management Information
>                         draft-irtf-nmrg-sming-06
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on April 28, 2004.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003).  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.  A companion document [RFCxxx2] defines a
>    core module that supplies common SMIng definitions.  Separate RFCs
>    define mappings of SMIng to specific management protocols, including
>    SNMP [RFCxxx3].
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 1]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
> Table of Contents
> 
>    1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
>    1.1   The History of SMIng . . . . . . . . . . . . . . . . . . . .  5
>    1.2   Terms of Requirement Levels  . . . . . . . . . . . . . . . .  5
>    2.    SMIng Data Modelling . . . . . . . . . . . . . . . . . . . .  5
>    2.1   Identifiers  . . . . . . . . . . . . . . . . . . . . . . . .  7
>    3.    Base Types and Derived Types . . . . . . . . . . . . . . . .  8
>    3.1   OctetString  . . . . . . . . . . . . . . . . . . . . . . . .  8
>    3.2   Pointer  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
>    3.3   ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . . 10
>    3.4   Integer32  . . . . . . . . . . . . . . . . . . . . . . . . . 11
>    3.5   Integer64  . . . . . . . . . . . . . . . . . . . . . . . . . 12
>    3.6   Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 13
>    3.7   Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 13
>    3.8   Float32  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
>    3.9   Float64  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
>    3.10  Float128 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
>    3.11  Enumeration  . . . . . . . . . . . . . . . . . . . . . . . . 17
>    3.12  Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
>    3.13  Display Formats  . . . . . . . . . . . . . . . . . . . . . . 19
>    4.    The SMIng File Structure . . . . . . . . . . . . . . . . . . 21
>    4.1   Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 21
>    4.2   Textual Data . . . . . . . . . . . . . . . . . . . . . . . . 21
>    4.3   Statements and Arguments . . . . . . . . . . . . . . . . . . 22
>    5.    The module Statement . . . . . . . . . . . . . . . . . . . . 22
>    5.1   The module's import Statement  . . . . . . . . . . . . . . . 23
>    5.2   The module's organization Statement  . . . . . . . . . . . . 24
>    5.3   The module's contact Statement . . . . . . . . . . . . . . . 24
>    5.4   The module's description Statement . . . . . . . . . . . . . 24
>    5.5   The module's reference Statement . . . . . . . . . . . . . . 24
>    5.6   The module's revision Statement  . . . . . . . . . . . . . . 24
>    5.6.1 The revision's date Statement  . . . . . . . . . . . . . . . 24
>    5.6.2 The revision's description Statement . . . . . . . . . . . . 25
>    5.7   Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 25
>    6.    The extension Statement  . . . . . . . . . . . . . . . . . . 26
>    6.1   The extension's status Statement . . . . . . . . . . . . . . 27
>    6.2   The extension's description Statement  . . . . . . . . . . . 27
>    6.3   The extension's reference Statement  . . . . . . . . . . . . 27
>    6.4   The extension's abnf Statement . . . . . . . . . . . . . . . 27
>    6.5   Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 28
>    7.    The typedef Statement  . . . . . . . . . . . . . . . . . . . 28
>    7.1   The typedef's type Statement . . . . . . . . . . . . . . . . 28
>    7.2   The typedef's default Statement  . . . . . . . . . . . . . . 28
>    7.3   The typedef's format Statement . . . . . . . . . . . . . . . 29
>    7.4   The typedef's units Statement  . . . . . . . . . . . . . . . 29
>    7.5   The typedef's status Statement . . . . . . . . . . . . . . . 29
>    7.6   The typedef's description Statement  . . . . . . . . . . . . 30
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 2]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    7.7   The typedef's reference Statement  . . . . . . . . . . . . . 30
>    7.8   Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 30
>    8.    The identity Statement . . . . . . . . . . . . . . . . . . . 31
>    8.1   The identity's parent Statement  . . . . . . . . . . . . . . 31
>    8.2   The identity's status Statement  . . . . . . . . . . . . . . 32
>    8.3   The identity' description Statement  . . . . . . . . . . . . 32
>    8.4   The identity's reference Statement . . . . . . . . . . . . . 32
>    8.5   Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 33
>    9.    The class Statement  . . . . . . . . . . . . . . . . . . . . 33
>    9.1   The class' extends Statement . . . . . . . . . . . . . . . . 33
>    9.2   The class' attribute Statement . . . . . . . . . . . . . . . 33
>    9.2.1 The attribute's type Statement . . . . . . . . . . . . . . . 34
>    9.2.2 The attribute's access Statement . . . . . . . . . . . . . . 34
>    9.2.3 The attribute's default Statement  . . . . . . . . . . . . . 34
>    9.2.4 The attribute's format Statement . . . . . . . . . . . . . . 34
>    9.2.5 The attribute's units Statement  . . . . . . . . . . . . . . 35
>    9.2.6 The attribute's status Statement . . . . . . . . . . . . . . 35
>    9.2.7 The attribute's description Statement  . . . . . . . . . . . 36
>    9.2.8 The attribute's reference Statement  . . . . . . . . . . . . 36
>    9.3   The class' unique Statement  . . . . . . . . . . . . . . . . 36
>    9.4   The class' event Statement . . . . . . . . . . . . . . . . . 36
>    9.4.1 The event's status Statement . . . . . . . . . . . . . . . . 37
>    9.4.2 The event's description Statement  . . . . . . . . . . . . . 37
>    9.4.3 The event's reference Statement  . . . . . . . . . . . . . . 37
>    9.5   The class' status Statement  . . . . . . . . . . . . . . . . 37
>    9.6   The class' description Statement . . . . . . . . . . . . . . 38
>    9.7   The class's reference Statement  . . . . . . . . . . . . . . 38
>    9.8   Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 38
>    10.   Extending a Module . . . . . . . . . . . . . . . . . . . . . 39
>    11.   SMIng Language Extensibility . . . . . . . . . . . . . . . . 41
>    12.   Security Considerations  . . . . . . . . . . . . . . . . . . 42
>    13.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
>          Normative References . . . . . . . . . . . . . . . . . . . . 43
>          Informative References . . . . . . . . . . . . . . . . . . . 43
>          Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44
>    A.    SMIng ABNF Grammar . . . . . . . . . . . . . . . . . . . . . 45
>          Intellectual Property and Copyright Statements . . . . . . . 55
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 3]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
> 1. Introduction
> 
>    In traditional management systems management information is viewed as
>    a collection of managed objects, residing in a virtual information
>    store, termed the Management Information Base (MIB).  Collections of
>    related objects are defined in MIB modules.  These modules are
>    written conforming to a specification language, the Structure of
>    Management Information (SMI).  There are different versions of the
>    SMI.  The SMI version 1 (SMIv1) is defined in [RFC1155], [RFC1212],
>    [RFC1215] and the SMI version 2 (SMIv2) in [RFC2578], [RFC2579],
>    [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) while the the SPPI is bound to the Common Open Policy
>    Service Provisioning (COPS-PR) protocol.  Even though the languages
>    have common rules, it is hard to use common data definitions with
>    both protocols.  It is the purpose of this document to define a
>    common data definition language, named SMIng, that allows to formally
>    specify data models independent of specific protocols and
>    applications.  Companion documents contain
> 
>    o  core modules that supply common SMIng definitions [RFCxxx2],
> 
>    o  an SMIng language extension to define SNMP specific mappings of
>       SMIng definitions in a way compatible to SMIv2 MIBs [RFCxxx3].
> 
>    Additional language extensions may be added in the future, e.g.  to
>    define COPS-PR specific mappings of SMIng definition in a way
>    compatible to SPPI PIBs.
> 
>    Section 2 gives an overview of the basic concepts of data modelling
>    using SMIng while the subsequent sections present the concepts of the
>    SMIng language in detail: the base types, the SMIng file structure,
>    and all SMIng core statements.
> 
>    The remainder of the document describes extensibility features of the
>    language and rules to follow when changes are applied to a module.
>    Appendix A contains the grammar of SMIng in ABNF [RFC2234] notation.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 4]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
> 1.1 The History of SMIng
> 
>    SMIng started in 1999 as a research project to address some drawbacks
>    of SMIv2, the current data modelling language for management
>    information bases, primarily its partial dependence on ASN.1 and a
>    number of exception rules that turned out to be problematic.  In
>    2000, the work was handed over to the IRTF Network Management
>    Research Group where it was significantly detailed.  Since the work
>    of the RAP Working Group on COPS-PR and SPPI emerged in 1999/2000,
>    SMIng was split into two parts: a core data definition language
>    (defined in this document) and protocol mappings to allow the
>    application of core defintions through (potentially) multiple
>    management protocols.  The replacement of SMIv2 and SPPI by a single
>    merged data definition language was also a primary goal of the IETF
>    SMING Working Group that was chartered at the end of 2000.
> 
>    The requirements for a new data definition language were discussed
>    several times within the IETF SMING Working Group and changed
>    significantly over time [RFC3216], so that another proposal (in
>    addition to SMIng), named SMI Data Structures (SMI-DS) was presented
>    to the Working Group.  In the end neither of the two proposals found
>    enough consensus and support and the attempt to merge the existing
>    concepts did not succeed, so that the Working Group was closed down
>    in April 2003.
> 
>    In order to record the work of the NMRG (Network Management Research
>    Group) on SMIng, this memo and the accompanying memos on the SNMP
>    protocol mapping [RFCxxx3] and on core SMIng modules [RFCxxx2] have
>    been published for informational purpose.
> 
>    Note that throughout the present document and its two companions
>    [RFCxxx3], [RFCxxx2] the term "SMIng" refers to the specific data
>    modelling language that is specified in this document, whereas the
>    term "SMING" refers to the general effort within the IETF Working
>    Group to define a new management data definition language as an SMIv2
>    successor and probably an SPPI merger, for which "SMIng" and "SMI-DS"
>    were two specific proposals.
> 
> 1.2 Terms of Requirement Levels
> 
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
> 
> 2. SMIng Data Modelling
> 
>    SMIng is a language designed to specify management information in a
>    structured way readable to computer programs, e.g.  MIB compilers, as
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 5]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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,
> 
>    o  the definition of SMIng extensions to allow the local module or
>       other modules to specify information beyond the scope of the base
>       SMIng in a machine readable notation.  Some extensions for the
>       application of SMIng in the SNMP framework are defined in
>       [RFCxxx3],
> 
>    o  the definition of information beyond the scope of the base SMIng
>       statements, based on locally defined or imported SMIng extensions.
> 
>    Each module is identified by an upper-case identifier.  The names of
>    all standard modules must be unique (but different versions of the
>    same module should have the same name).  Developers of enterprise
>    modules are encouraged to choose names for their modules that will
>    have a low probability of colliding with standard or other enterprise
>    modules, e.g.  by using the enterprise or organization name as a
>    prefix.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 6]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
> 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' visibilty.
> 
>    Within every namespace each identifier MUST be unique.
> 
>    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.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 7]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    When identifiers from external modules are referenced, there is the
>    possibility of name collisions.  As such, if different items with the
>    same identifier are imported or if imported identifiers collide with
>    identifiers of locally defined items, then this ambiguity is resolved
>    by prefixing those identifiers with the names of their modules and
>    the namespace operator `::', i.e.  `Module::item'.  Of course, this
>    notation can be used to refer to identifiers even when there is no
>    name collision.
> 
>    Note that SMIng core language keywords MUST NOT be imported.  See the
>    `...Keyword' rules of the SMIng ABNF grammar in Appendix A for a list
>    of those keywords.
> 
> 3. Base Types and Derived Types
> 
>    SMIng has a set of base types, similar to those of many programming
>    languages, but with some differences due to special requirements from
>    the management information model.
> 
>    Additional types may be defined, derived from those base types or
>    from other derived types.  Derived types may use subtyping to
>    formally restrict the set of possible values.  An initial set of
>    commonly used derived types is defined in the SMIng standard module
>    NMRG-SMING [RFCxxx2].
> 
>    The different base types and their derived types allow different
>    kinds of subtyping, namely size restrictions of octet strings
>    (Section 3.1), range restrictions of numeric types (Section 3.4
>    through Section 3.10), restricted pointer types (Section 3.2), and
>    restrictions of the sets of named numbers for enumeration types
>    (Section 3.11) and bit sets (Section 3.12).
> 
> 3.1 OctetString
> 
>    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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 8]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    or cr & nl).  Some characters require a special encoding (see Section
>    4.2).  Textual data may span multiple lines, where each subsequent
>    line prefix containing only white space up to the column where the
>    first line's data starts SHOULD be skipped by parsers for a better
>    text formatting.
> 
>    When defining a type derived (directly or indirectly) from the
>    OctetString base type, the size in octets may be restricted by
>    appending a list of size ranges or explicit size values, separated by
>    pipe `|' characters and the whole list enclosed in parenthesis.  A
>    size range consists of a lower bound, two consecutive dots `..' and
>    an upper bound.  Each value can be given in decimal or `0x'-prefixed
>    hexadecimal notation.  Hexadecimal numbers must have an even number
>    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.
> 
>    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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 9]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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 independant SMIng modules.  It is meant to be used in SNMP
>    and COPS-PR mappings of attributes of type Pointer (Section 3.2).
> 
>    Values of this type may be denoted as a sequence of numerical
>    non-negative sub-identifier values which each MUST NOT exceed 2^32-1
>    (4294967295).  Sub-identifiers may be denoted decimal or
>    `0x'-prefixed hexadecimal.  They are separated by single dots and
>    without any intermediate white space.  Alternatively (and preferred
>    in most cases), the first element may be a previously defined or
>    imported lower-case identifier, representing a static object
>    identifier prefix.
> 
>    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:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 10]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>      1.3.6.1                     // legal numerical oid
>      mib-2.1                     // legal oid with identifier prefix
>      internet.4.1.0x0627.0x01    // legal oid with hex subids
>      iso.-1                      // illegal negative subid
>      iso.org.6                   // illegal non-heading identifier
>      IF-MIB::ifNumber.0          // legel fully quallified instance oid
> 
> 
> 
> 3.4 Integer32
> 
>    The Integer32 base type represents integer values between -2^31
>    (-2147483648) and 2^31-1 (2147483647).
> 
>    Values of type Integer32 may be denoted as decimal or hexadecimal
>    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
>    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:
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 11]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>      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 and the whole list enclosed in parenthesis.  A range
>    consists of a lower bound, two consecutive dots `..' and an upper
>    bound.  Each value can be given in decimal or `0x'-prefixed
>    hexadecimal notation.  Hexadecimal numbers must have an even number
>    of at least two digits.  If multiple values or ranges are given they
>    all MUST be disjoint and MUST be in ascending order.  If a value
>    restriction is applied to an already restricted type the new
>    restriction MUST be equal or more limiting, that is raising the lower
>    bounds, reducing the upper bounds, removing explicit values or
>    ranges, or splitting ranges into multiple ranges with intermediate
>    gaps.
> 
>    Value Examples:
> 
>      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
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 12]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
> 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 and the whole list enclosed in parenthesis.  A range
>    consists of a lower bound, two consecutive dots `..' and an upper
>    bound.  Each value can be given in decimal or `0x'-prefixed
>    hexadecimal notation.  Hexadecimal numbers must have an even number
>    of at least two digits.  If multiple values or ranges are given they
>    all MUST be disjoint and MUST be in ascending order.  If a value
>    restriction is applied to an already restricted type the new
>    restriction MUST be equal or more limiting, that is raising the lower
>    bounds, reducing the upper bounds, removing explicit values or
>    ranges, or splitting ranges into multiple ranges with intermediate
>    gaps.
> 
>    Value Examples:
> 
>      015                         // illegal leading zero
>      -123                        // illegal negative value
>      0xabc                       // illegal hexadecimal value length
>      0x80000000                  // legal hexadecimal value
>      0x8080000000                // illegal value, too large
> 
>    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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 13]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    digits.  Hexadecimal numbers are prefixed by `0x' and MUST have an
>    even number of hexadecimal digits, where letters MAY be upper-case
>    but lower-case characters are RECOMMENDED.
> 
>    When defining a type derived (directly or indirectly) from the
>    Unsigned64 base type, the set of possible values may be restricted by
>    appending a list of ranges or explicit values, separated by pipe `|'
>    characters and the whole list enclosed in parenthesis.  A range
>    consists of a lower bound, two consecutive dots `..' and an upper
>    bound.  Each value can be given in decimal or `0x'-prefixed
>    hexadecimal notation.  Hexadecimal numbers must have an even number
>    of at least two digits.  If multiple values or ranges are given they
>    all MUST be disjoint and MUST be in ascending order.  If a value
>    restriction is applied to an already restricted type the new
>    restriction MUST be equal or more limiting, that is raising the lower
>    bounds, reducing the upper bounds, removing explicit values or
>    ranges, or splitting ranges into multiple ranges with intermediate
>    gaps.
> 
>    Value Examples:
> 
>      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].
> 
>    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 A for the detailed syntax.
>    Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
>    Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
>    infinity).  Note that -0.0 and +0.0 are different floating point
>    values.  0.0 is equal to +0.0.
> 
>    When defining a type derived (directly or indirectly) from the
>    Float32 base type, the set of possible values may be restricted by
>    appending a list of ranges or explicit values, separated by pipe `|'
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 14]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    characters and the whole list enclosed in parenthesis.  A range
>    consists of a lower bound, two consecutive dots `..' and an upper
>    bound.  If multiple values or ranges are given they all MUST be
>    disjoint and MUST be in ascending order.  If a value restriction is
>    applied to an already restricted type the new restriction MUST be
>    equal or more limiting, that is raising the lower bounds, reducing
>    the upper bounds, removing explicit values or ranges, or splitting
>    ranges into multiple ranges with intermediate gaps.  The special
>    values `snan', `qnan', `neginf', and `posinf' must be explicitly
>    listed in restrictions if they shall be included, where `snan' and
>    `qnan' cannot be used in ranges.
> 
>    Note that encoding is not subject to this specification.  It has to
>    be described by protocols that transport objects of type 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
> 
> 
> 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 A for the detailed syntax.
>    Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
>    Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
>    infinity).  Note that -0.0 and +0.0 are different floating point
>    values.  0.0 is equal to +0.0.
> 
>    When defining a type derived (directly or indirectly) from the
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 15]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    Float64 base type, the set of possible values may be restricted by
>    appending a list of ranges or explicit values, separated by pipe `|'
>    characters and the whole list enclosed in parenthesis.  A range
>    consists of a lower bound, two consecutive dots `..' and an upper
>    bound.  If multiple values or ranges are given they all MUST be
>    disjoint and MUST be in ascending order.  If a value restriction is
>    applied to an already restricted type the new restriction MUST be
>    equal or more limiting, that is raising the lower bounds, reducing
>    the upper bounds, removing explicit values or ranges, or splitting
>    ranges into multiple ranges with intermediate gaps.  The special
>    values `snan', `qnan', `neginf', and `posinf' must be explicitly
>    listed in restrictions if they shall be included, where `snan' and
>    `qnan' cannot be used in ranges.
> 
>    Note that encoding is not subject to this specification.  It has to
>    be described by protocols that transport objects of type Float64.
>    Note also that most floating point encodings disallow the
>    representation of many values that can be written as decimal
>    fractions as used in SMIng for human readability.  Therefore,
>    explicit values in floating point type restrictions should be handled
>    with care.
> 
>    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
> 
> 
> 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 A for the detailed syntax.
>    Special values are `snan' (signaling Not-a-Number), `qnan' (quiet
>    Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
>    infinity).  Note that -0.0 and +0.0 are different floating point
>    values.  0.0 is equal to +0.0.
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 16]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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 and the whole list enclosed in parenthesis.  A range
>    consists of a lower bound, two consecutive dots `..' and an upper
>    bound.  If multiple values or ranges are given they all MUST be
>    disjoint and MUST be in ascending order.  If a value restriction is
>    applied to an already restricted type the new restriction MUST be
>    equal or more limiting, that is raising the lower bounds, reducing
>    the upper bounds, removing explicit values or ranges, or splitting
>    ranges into multiple ranges with intermediate gaps.  The special
>    values `snan', `qnan', `neginf', and `posinf' must be explicitly
>    listed in restrictions if they shall be included, where `snan' and
>    `qnan' cannot be used in ranges.
> 
>    Note that encoding is not subject to this specification.  It has to
>    be described by protocols that transport objects of type Float128.
>    Note also that most floating point encodings disallow the
>    representation of many values that can be written as decimal
>    fractions as used in SMIng for human readability.  Therefore,
>    explicit values in floating point type restrictions should be handled
>    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
> 
> 
> 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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 17]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    MUST be unique.  It is RECOMMENDED that values are positive and start
>    at 1 and be numbered contiguously.  All named numbers MUST be given
>    in ascending order.
> 
>    Values of enumeration types may be denoted as decimal or
>    `0x'-prefixed hexadecimal numbers or preferably as their assigned
>    names.  Hexadecimal numbers must have an even number of at least two
>    digits.
> 
>    When types are derived (directly or indirectly) from an enumeration
>    type, the set of named numbers may be equal or restricted by removing
>    one or more named numbers.  But no named numbers may be added or
>    changed regarding its name, value, or both.
> 
>    Type and Value Examples:
> 
>      Enumeration (up(1), down(2), testing(3))
>      Enumeration (down(2), up(1)) // illegal order
> 
>      0                            // legal (though not recommended) value
>      up                           // legal value given by name
>      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.
> 
>    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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 18]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    more named numbers.  But no named numbers may be added or changed
>    regarding its name, value, or both.
> 
>    Type and Value Examples:
> 
>      Bits (readable(0), writeable(1), executable(2))
>      Bits (writeable(1), readable(0) // illegal order
> 
>      ()                          // legal empty value
>      (readable, writeable, 2)    // legal value
>      (0, readable, executable)   // illegal, readable(0) appears twice
>      (writeable, 4)              // illegal, element 4 out of range
> 
> 
> 3.13 Display Formats
> 
>    Attribute definitions and type definitions allow the specification of
>    a format to be used, when a value of that attribute or an attribute
>    of that type is displayed.  Format specifications are represented as
>    textual data.
> 
>    When the attribute or type has an underlying base type of Integer32,
>    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, or `d' for decimal, or `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
>    value and producing the next zero or more characters to be displayed.
>    The octets within the value are processed in order of significance,
>    most significant first.
> 
>    The five parts of a octet-format specification are:
> 
>    1.  the (optional) repeat indicator; if present, this part is a `*',
>        and indicates that the current octet of the value is to be used
>        as the repeat count.  The repeat count is an unsigned integer
>        (which may be zero) which specifies how many times the remainder
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 19]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>        of this octet-format specification should be successively
>        applied.  If the repeat indicator is not present, the repeat
>        count is one.
> 
>    2.  the octet length: one or more decimal digits specifying the
>        number of octets of the value to be used and formatted by this
>        octet-specification.  Note that the octet length can be zero.  If
>        less than this number of octets remain in the value, then the
>        lesser number of octets are used.
> 
>    3.  the display format, either: `x' for hexadecimal, `d' for decimal,
>        `o' for octal, `a' for ASCII, or `t' for UTF-8 [RFC2279].  If the
>        octet length part is greater than one, and the display format
>        part refers to a numeric format, then network byte-ordering
>        (big-endian encoding) is used interpreting the octets in the
>        value.  The octets processed by the `t' display format do not
>        necessarily form an integral number of UTF-8 characters.
>        Trailing octets which do not form a valid UTF-8 encoded character
>        are discarded.
> 
>    4.  the (optional) display separator character; if present, this part
>        is a single character which is 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 which is 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.
> 
>    If the octets of the value are exhausted before all the octet format
>    specification have been used, then the excess specifications are
>    ignored.  If additional octets remain in the value after interpreting
>    all the octet format specifications, then the last octet format
>    specification is re-interpreted to process the additional octets,
>    until no octets remain in the value.
> 
>    Note that for some types no format specifications are defined.  For
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 20]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    derived types and attributes that are based on such types, format
>    specifications SHOULD be omitted.  Implementations MUST ignore format
>    specifications they cannot interpret.  Also note that the SMIng
>    grammar (Appendix A) does not specify the syntax of format
>    specifications.
> 
>    Display Format Examples:
> 
>      Base Type   Format              Example Value    Rendered Value
>      ----------- ------------------- ---------------- -----------------
>      OctetString 255a                "Hello World."   Hello World.
>      OctetString 1x:                 "Hello!"         48:65:6c:6c:6f:21
>      OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0
>      OctetString 1d.1d.1d.1d/2d      0x0a0000010400   10.0.0.1/1024
>      OctetString *1x:/1x:            0x02aabbccddee   aa:bb/cc:dd:ee
>      Integer32   d-2                 1234             12.34
> 
> 
> 4. The SMIng File Structure
> 
>    The topmost container of SMIng information is a file.  An SMIng file
>    may contain zero, one or more modules.  It is RECOMMENDED to separate
>    modules into files named by their modules, where possible.  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.
> 
>    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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 21]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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 Section 6 and Section 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    Expires April 28, 2004              [Page 22]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>            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 which does not define any items used
>    by applications in the first instance.  This part of a module is
>    followed by its main definitions, namely SMIng extensions (Section
>    6), derived types (Section 7), identities (Section 8), and classes
>    (Section 9).
> 
>    See the `moduleStatement' rule of the SMIng grammar (Appendix A) for
>    the formal syntax of the `module' statement.
> 
> 5.1 The module's import Statement
> 
>    The optional module's `import' statement is used to import
>    identifiers from external modules into the local module's namespace.
>    It gets two arguments: the name of the external module and a
>    comma-separated list of one or more identifiers to be imported
>    enclosed in parenthesis.
> 
>    Multiple `import' statements for the same module but with disjoint
>    lists of identifiers are allowed, though NOT RECOMMENDED.  Anyhow,
>    the same identifier from the same module MUST NOT be imported
>    multiple times.  To import identifiers with the same name from
>    different modules might be necessary and is allowed.  To distinguish
>    them in the local module, they have to be referred by qualified
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 23]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    names.  It is NOT RECOMMENDED to import identifiers not used in the
>    local module.
> 
>    See the `importStatement' rule of the SMIng grammar (Appendix A) for
>    the formal syntax of the `import' statement.
> 
> 5.2 The module's organization Statement
> 
>    The module's `organization' statement, which must be present, gets
>    one argument which is used to specify a textual description of the
>    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 A)
>    for the formal syntax of the `revision' statement.
> 
> 5.6.1 The revision's date Statement
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 24]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    The revision's `date' statement, which must be present, gets one
>    argument which is used to specify the date and time of the revision
>    in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the
>    time `00:00'.  The time is always given in UTC.
> 
>    See the `date' rule of the SMIng grammar (Appendix A) for the formal
>    syntax of the revision's `date' statement.
> 
> 5.6.2 The revision's description Statement
> 
>    The revision's `description' statement, which must be present, gets
>    one argument which is used to specify a high-level textual
>    description of the revision.
> 
> 5.7 Usage Example
> 
>    Consider how a skeletal module might be constructed:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 25]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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: [phone]
>                 EMail: [e-mail]";
> 
>      description
>                "The module for entities implementing the ACME protocol.
> 
>                 Copyright (C) The Internet Society (2003).
>                 All Rights Reserved.
>                 This version of this MIB module is part of RFC XXXX,
>                 see the RFC itself for legal notices.";
> 
>      revision {
>        date            "2003-10-29";
>        description
>                "Initial revision, published as RFC XXXX.";
>      };
> 
>      // ... further definitions ...
> 
>    }; // end of module ACME-MIB.
> 
> 6. The extension Statement
> 
>    The `extension' statement is used to define new statements to be used
>    in the local module following this extension statement definition or
>    in external modules that may import this extension statement
>    definition.  The `extension' statement gets two arguments: a
>    lower-case extension statement identifier and a statement block that
>    holds detailed extension information in an obligatory order.
> 
>    Extension statement identifiers SHOULD NOT contain any upper-case
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 26]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    characters.
> 
>    Note that the SMIng extension feature does not allow to formally
>    specify the context, argument syntax and semantics of an extension.
>    Its only purpose is to declare the existence of an extension and to
>    allow a unique reference to an extension.  See Section 11 for
>    detailed information on extensions and [RFCxxx3] for mappings of
>    SMIng definitions to SNMP which is formally defined as an extension.
> 
>    See the `extensionStatement' rule of the SMIng grammar (Appendix A)
>    for the formal syntax of the `extension' statement.
> 
> 6.1 The extension's status Statement
> 
>    The extension's `status' statement, which must be present, gets one
>    argument which is used to specify whether this extension definition
>    is current or historic.  The value `current' means that the
>    definition is current and valid.  The value `obsolete' means the
>    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.
> 
> 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 to include information on the extension's context,
>    its semantics, and implementation conditions.  See also Section 11.
> 
> 6.3 The extension's reference Statement
> 
>    The extension's `reference' statement, which need not be present,
>    gets one argument which is used to specify a textual cross-reference
>    to some other document, either another module which defines related
>    extension definitions, or some other document which provides
>    additional information relevant to this extension.
> 
> 6.4 The extension's abnf Statement
> 
>    The extension's `abnf' statement, which need not be present, gets one
>    argument which is used to specify a formal ABNF [RFC2234] grammar
>    definition of the extension.  This grammar can reference rule names
>    from the core SMIng grammar (Appendix A).
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 27]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    Note that the `abnf' statement should contain only pure ABNF and no
>    additional text, though comments prefixed by 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\"";
>    };
> 
> 7. The typedef Statement
> 
>    The `typedef' statement is used to define new data types to be used
>    in the local module or in external modules.  It gets two arguments:
>    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 A) 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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 28]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
> 
>    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.  E.g.,
>    if the type defines frequency values of type Unsigned64 measured in
>    thousands of Hertz, the format specification should be `d-3' and the
>    units specification should be `Hertz' or `Hz'.  If the format
>    specification would be omitted, the units specification should be
>    `Milli-Hertz' or `mHz'.  Authors of SMIng modules should pay
>    attention to keep format and units specifications synced.
>    Application implementors MUST NOT implement units specifications
>    without implementing format specifications.
> 
> 7.5 The typedef's status Statement
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 29]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
> 
> 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 to include all semantic definitions necessary for
>    implementation, and to embody any information which would otherwise
>    be communicated in any commentary annotations associated with this
>    type definition.
> 
> 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.";
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 30]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    };
> 
>    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.
>               ...
>               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 A)
>    for the formal syntax of the `identity' statement.
> 
> 8.1 The identity's parent Statement
> 
>    The identity's `parent' statement must be present for a derived
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 31]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
> 
>    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 to include all semantic definitions necessary for
>    implementation, and to embody any information which would otherwise
>    be communicated in any commentary annotations associated with this
>    identity definition.
> 
> 8.4 The identity's reference Statement
> 
>    The identity's `reference' statement, which need not be present, gets
>    one argument which is used to specify a textual cross-reference to
>    some other document, either another module which defines related
>    identity definitions, or some other document which provides
>    additional information relevant to this identity definition.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 32]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
> 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.";
>    };
> 
> 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 A) 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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 33]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
> 
>    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
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 34]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
> 
>    The units specification has to be appropriate for values displayed
>    according to the attribute's format specification if present.  E.g.,
>    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 synced.  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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 35]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    containting class is `obsolete'.  Nevertheless, subsequent revisions
>    of used type definition cannot be avoided, but SHOULD be taken into
>    account in subsequent revisions of the local module.
> 
> 9.2.7 The attribute's description Statement
> 
>    The attribute's `description' statement, which must be present, gets
>    one argument which is used to specify a high-level textual
>    description of this attribute.
> 
>    It is RECOMMENDED to include all semantic definitions necessary for
>    the implementation of this attribute.
> 
> 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.
> 
> 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 just to be contained in other classes or
>    to be 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.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 36]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    See the `eventStatement' rule of the SMIng grammar (Appendix A) for
>    the formal syntax of the `event' statement.
> 
> 9.4.1 The event's status Statement
> 
>    The event's `status' statement, which must be present, gets one
>    argument which is used to specify whether this event definition is
>    current or historic.  The value `current' means that the definition
>    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.
> 
>    It is RECOMMENDED to include all semantic definitions necessary for
>    the implementation of this event.  In particular, it SHOULD be
>    documented which instance of the class is associated with an event of
>    this type.
> 
> 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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 37]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    avoided, but SHOULD be taken into account in subsequent revisions of
>    the local module.
> 
> 9.6 The class' description Statement
> 
>    The class' `description' statement, which must be present, gets one
>    argument which is used to specify a high-level textual description of
>    the newly defined class.
> 
>    It is RECOMMENDED to include all semantic definitions necessary for
>    implementation, and to embody any information which would otherwise
>    be communicated in any commentary annotations associated with this
>    class definition.
> 
> 9.7 The class's reference Statement
> 
>    The class'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
>    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;
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 38]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>        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.";
>      };
> 
>      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.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 39]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
> 
>    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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 40]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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
>    further information, people wish to express.  To describe additional
>    information informally in description statements has the disadvantage
>    that this information cannot be parsed by any program.
> 
>    SMIng allows modules to include statements that are unknown to a
>    parser but fulfill 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 also to complain about 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 to distinguish those
>       extensions.
> 
>    o  The supported extensions of an SMIng implementation, e.g.  an
>       SMIng module compiler, can be clearly expressed.
> 
>    The only formal effect of an extension statement definition is to
>    declare its existence and its status, and optionally its ABNF
>    grammar.  All additional aspects SHOULD be described in the
>    `description' statement:
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 41]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
> 
>    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 [RFCxxx3]
>       framework is defined as an SMIng extension.  Other mappings may
>       follow in the future.
> 
>    o  Inlined annotations to definitions.  E.g., a vendor may wish to
>       describe additional information to class and attribute definitions
>       in private modules.  An example are severity levels of events in
>       the statement block of an `event' statement.
> 
>    o  Arbitrary annotations to external definitions.  E.g., a vendor may
>       wish to describe additional information to definitions in a
>       "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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 42]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    [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.
> 
>    Furthmore, several discussions within the SMING Working Group
>    reflected experience with SMIv2 and influenced this specification at
>    some points.
> 
> Normative References
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", RFC 2119, BCP 14, March 1997.
> 
>    [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
>               Specifications: ABNF", RFC 2234, November 1997.
> 
> Informative References
> 
>    [RFC3216]  Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J.,
>               Strauss, F. and W. Weiss, "SMIng Objectives", RFC 3216,
>               December 2001.
> 
>    [RFCxxx2]  Strauss, F. and J. Schoenwaelder, "SMIng Core Modules",
>               draft-irtf-nmrg-sming-modules-04.txt, October 2003.
> 
>    [RFCxxx3]  Strauss, F. and J. Schoenwaelder, "SMIng Extension for
>               SNMP Mappings", draft-irtf-nmrg-sming-snmp-04.txt, October
>               2003.
> 
>    [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Structure of Management
>               Information Version 2 (SMIv2)", RFC 2578, STD 58, April
>               1999.
> 
>    [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Textual Conventions for
>               SMIv2", RFC 2579, STD 59, April 1999.
> 
>    [RFC2580]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Conformance Statements for
>               SMIv2", RFC 2580, STD 60, April 1999.
> 
>    [RFC3159]  McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 43]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>               S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of
>               Policy Provisioning Information (SPPI)", RFC 3159, August
>               2001.
> 
>    [RFC1155]  Rose, M. and K. McCloghrie, "Structure and Identification
>               of Management Information for TCP/IP-based Internets", RFC
>               1155, STD 16, May 1990.
> 
>    [RFC1212]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC
>               1212, STD 16, March 1991.
> 
>    [RFC1215]  Rose, M., "A Convention for Defining Traps for use with
>               the SNMP", RFC 1215, March 1991.
> 
>    [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", RFC 3411, STD 62,
>               December 2002.
> 
>    [IEEE754]  Institute of Electrical and Electronics Engineers, "IEEE
>               Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
>               Standard 754-1985, August 1985.
> 
>    [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
>               10646", RFC 2279, January 1998.
> 
> 
> Authors' Addresses
> 
>    Frank Strauss
>    TU Braunschweig
>    Muehlenpfordtstrasse 23
>    38106 Braunschweig
>    Germany
> 
>    Phone: [phone]
>    EMail: [e-mail]
>    URI:   http://www.ibr.cs.tu-bs.de/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 44]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    Juergen Schoenwaelder
>    International University Bremen
>    P.O. Box 750 561
>    28725 Bremen
>    Germany
> 
>    Phone: [phone]
>    EMail: [e-mail]
>    URI:   http://www.eecs.iu-bremen.de/
> 
> Appendix A. SMIng ABNF Grammar
> 
>     The SMIng grammar conforms to the Augmented Backus-Naur Form (ABNF)
>    [RFC2234].
> 
>    ;;
>    ;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234).
>    ;;
>    ;; @(#) $Id: sming.abnf,v 1.33 2003/10/23 19:31:55 strauss Exp $
>    ;;
>    ;; Copyright (C) The Internet Society (2003). All Rights Reserved.
>    ;;
> 
>    smingFile               = optsep *(moduleStatement optsep)
> 
>    ;;
>    ;; Statement rules.
>    ;;
> 
>    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)
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 45]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>                                  *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)
>                                  *(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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 46]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>                                  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 ";"
> 
>    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 ";"
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 47]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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 ")"
> 
>    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 ")"
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 48]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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 ")"
> 
>    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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 49]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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 /
>                              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
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 50]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
>    ;;
> 
>    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.
>    ;;
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 51]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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
>    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.
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 52]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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.
>    ;;
> 
>    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
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 53]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    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
>                           ; 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 54]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights.  Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11.  Copies of
>    claims of rights made available for publication 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 implementors or users of this specification can
>    be obtained from the IETF Secretariat.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard.  Please address the information to the IETF Executive
>    Director.
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 55]
> 
> Internet-Draft                   SMIng                      October 2003
> 
> 
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Acknowledgement
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 56]
> 

> 
> 
> Network Working Group                                         F. Strauss
> Internet-Draft                                           TU Braunschweig
> Expires: April 28, 2004                                 J. Schoenwaelder
>                                          International University Bremen
>                                                         October 29, 2003
> 
> 
>                            SMIng Core Modules
>                     draft-irtf-nmrg-sming-modules-04
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on April 28, 2004.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
> Abstract
> 
>    SMIng (Structure of Management Information, Next Generation)
>    [RFCxxx1] is a protocol-independent data definition language for
>    management information.  This memo presents an SMIng module which
>    defines a set of derived types for common purposes such as counters,
>    date and time related types, and various string types.
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 1]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
> Table of Contents
> 
>    1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
>    2. NMRG-SMING . . . . . . . . . . . . . . . . . . . . . . . . . .   3
>    3. Security Considerations  . . . . . . . . . . . . . . . . . . .  12
>    4. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  12
>       Normative References . . . . . . . . . . . . . . . . . . . . .  13
>       Informative References . . . . . . . . . . . . . . . . . . . .  13
>       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  13
>       Intellectual Property and Copyright Statements . . . . . . . .  15
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 2]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
> 1. Introduction
> 
>    Most SMIng [RFCxxx1] 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 contained in
>    this memo.  Its derived types are generally applicable for modelling
>    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].
> 
> 2. NMRG-SMING
> 
>    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: [phone]
>                         EMail: [e-mail]
> 
>                         Juergen Schoenwaelder
>                         International University Bremen
>                         P.O. Box 750 561
>                         28725 Bremen
>                         Germany
>                         Phone: [phone]
>                         EMail: [e-mail]";
> 
>        description     "Core type definitions for SMIng. Several
>                         type definitions are SMIng versions of
>                         similar SMIv2 or SPPI definitions.
> 
>                         Copyright (C) The Internet Society (2003).
>                         All Rights Reserved.
>                         This version of this module is part of
>                         RFC XXXX, see the RFC itself for full
>                         legal notices.";
> 
>        revision {
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 3]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>            date        "2003-10-29";
>            description "Initial revision, published as RFC XXXX.";
>        };
> 
>        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    Expires April 28, 2004               [Page 4]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>                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    Expires April 28, 2004               [Page 5]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>                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    Expires April 28, 2004               [Page 6]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>               "******* 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    Expires April 28, 2004               [Page 7]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>                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    Expires April 28, 2004               [Page 8]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>        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    Expires April 28, 2004               [Page 9]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>            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    Expires April 28, 2004              [Page 10]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>                 - 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 2279.
> 
>                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    Expires April 28, 2004              [Page 11]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>                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.";
>        };
> 
>    };
> 
> 
> 
> 3. Security Considerations
> 
>    This module does not define any management objects.  Instead, it
>    defines a set of SMIng derived types which may be used by other SMIng
>    modules to define management objects.  These definitions have no
>    security impact on the Internet.
> 
> 4. Acknowledgments
> 
>    Some definitions in this document are derived from RFC 2578 [RFC2578]
>    and RFC 2579 [RFC2579], which were written by K.  McCloghrie, D.
>    Perkins, J.  Schoenwaelder, J.  Case, M.  Rose, and S.  Waldbusser.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 12]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
> Normative References
> 
>    [RFCxxx1]  Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
>               Structure of Management Information",
>               draft-irtf-nmrg-sming-06.txt, October 2003.
> 
> Informative References
> 
>    [RFC854]   Postel, J. and J. Reynolds, "TELNET Protocol
>               Specification", RFC 854, STD 8, May 1983.
> 
>    [RFC2279]  Yergeau, F., "UTF-8, a transformation format of ISO
>               10646", RFC 2279, January 1998.
> 
>    [RFC2571]  Harrington, D., Presuhn, R. and B. Wijnen, "An
>               Architecture for Describing SNMP Management Frameworks",
>               RFC 2571, April 1999.
> 
>    [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Structure of Management
>               Information Version 2 (SMIv2)", RFC 2578, STD 59, April
>               1999.
> 
>    [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Textual Conventions for
>               SMIv2", RFC 2579, STD 59, April 1999.
> 
> 
> Authors' Addresses
> 
>    Frank Strauss
>    TU Braunschweig
>    Muehlenpfordtstrasse 23
>    38106 Braunschweig
>    Germany
> 
>    Phone: [phone]
>    EMail: [e-mail]
>    URI:   http://www.ibr.cs.tu-bs.de/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 13]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>    Juergen Schoenwaelder
>    International University Bremen
>    P.O. Box 750 561
>    28725 Bremen
>    Germany
> 
>    Phone: [phone]
>    EMail: [e-mail]
>    URI:   http://www.eecs.iu-bremen.de/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 14]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights.  Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11.  Copies of
>    claims of rights made available for publication 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 implementors or users of this specification can
>    be obtained from the IETF Secretariat.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard.  Please address the information to the IETF Executive
>    Director.
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 15]
> 
> Internet-Draft               SMIng Modules                  October 2003
> 
> 
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Acknowledgement
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 16]
> 

> 
> 
> Network Working Group                                         F. Strauss
> Internet-Draft                                           TU Braunschweig
> Expires: April 28, 2004                                 J. Schoenwaelder
>                                          International University Bremen
>                                                         October 29, 2003
> 
> 
>                          SMIng Mappings to SNMP
>                      draft-irtf-nmrg-sming-snmp-04
> 
> Status of this Memo
> 
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as
>    Internet-Drafts.
> 
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
> 
>    The list of current Internet-Drafts can be accessed at http://
>    www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on April 28, 2004.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
> Abstract
> 
>    SMIng (Structure of Management Information, Next Generation)
>    [RFCxxx1] is a protocol-independent data definition language for
>    management information.  This memo defines an SMIng language
>    extension that specifies the mapping of SMIng definitions of
>    identities, classes, and their attributes and events to dedicated
>    definitions of nodes, scalar objects, tables and columnar objects,
>    and notifications for application in the SNMP management framework.
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 1]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
> Table of Contents
> 
>    1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
>    1.1   Terms of Requirement Levels  . . . . . . . . . . . . . . . .  4
>    2.    SNMP Based Internet Management . . . . . . . . . . . . . . .  4
>    2.1   Kinds of Nodes . . . . . . . . . . . . . . . . . . . . . . .  5
>    2.2   Scalar and Columnar Object Instances . . . . . . . . . . . .  6
>    2.3   Object Identifier Hierarchy  . . . . . . . . . . . . . . . .  7
>    3.    SMIng Data Type Mappings . . . . . . . . . . . . . . . . . .  8
>    3.1   ASN.1 Definitions  . . . . . . . . . . . . . . . . . . . . . 10
>    4.    The snmp Extension Statement . . . . . . . . . . . . . . . . 10
>    4.1   The oid Statement  . . . . . . . . . . . . . . . . . . . . . 11
>    4.2   The node Statement . . . . . . . . . . . . . . . . . . . . . 11
>    4.2.1 The node's oid Statement . . . . . . . . . . . . . . . . . . 11
>    4.2.2 The node's represents Statement  . . . . . . . . . . . . . . 11
>    4.2.3 The node's status Statement  . . . . . . . . . . . . . . . . 11
>    4.2.4 The node's description Statement . . . . . . . . . . . . . . 12
>    4.2.5 The node's reference Statement . . . . . . . . . . . . . . . 12
>    4.2.6 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 12
>    4.3   The scalars Statement  . . . . . . . . . . . . . . . . . . . 12
>    4.3.1 The scalars' oid Statement . . . . . . . . . . . . . . . . . 13
>    4.3.2 The scalars' object Statement  . . . . . . . . . . . . . . . 13
>    4.3.3 The scalars' status Statement  . . . . . . . . . . . . . . . 14
>    4.3.4 The scalars' description Statement . . . . . . . . . . . . . 14
>    4.3.5 The scalars' reference Statement . . . . . . . . . . . . . . 15
>    4.3.6 Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 15
>    4.4   The table Statement  . . . . . . . . . . . . . . . . . . . . 15
>    4.4.1 The table's oid Statement  . . . . . . . . . . . . . . . . . 15
>    4.4.2 Table Indexing Statements  . . . . . . . . . . . . . . . . . 15
>    4.4.3 The table's create Statement . . . . . . . . . . . . . . . . 18
>    4.4.4 The table's object Statement . . . . . . . . . . . . . . . . 18
>    4.4.5 The table's status Statement . . . . . . . . . . . . . . . . 19
>    4.4.6 The table's description Statement  . . . . . . . . . . . . . 19
>    4.4.7 The table's reference Statement  . . . . . . . . . . . . . . 20
>    4.4.8 Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 20
>    4.5   The notification Statement . . . . . . . . . . . . . . . . . 20
>    4.5.1 The notification's oid Statement . . . . . . . . . . . . . . 20
>    4.5.2 The notification's signals Statement . . . . . . . . . . . . 20
>    4.5.3 The notification's status Statement  . . . . . . . . . . . . 21
>    4.5.4 The notification's description Statement . . . . . . . . . . 21
>    4.5.5 The notification's reference Statement . . . . . . . . . . . 21
>    4.5.6 Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 22
>    4.6   The group Statement  . . . . . . . . . . . . . . . . . . . . 22
>    4.6.1 The group's oid Statement  . . . . . . . . . . . . . . . . . 22
>    4.6.2 The group's members Statement  . . . . . . . . . . . . . . . 22
>    4.6.3 The group's status Statement . . . . . . . . . . . . . . . . 22
>    4.6.4 The group's description Statement  . . . . . . . . . . . . . 23
>    4.6.5 The group's reference Statement  . . . . . . . . . . . . . . 23
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 2]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    4.6.6 Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 23
>    4.7   The compliance Statement . . . . . . . . . . . . . . . . . . 23
>    4.7.1 The compliance's oid Statement . . . . . . . . . . . . . . . 23
>    4.7.2 The compliance's status Statement  . . . . . . . . . . . . . 24
>    4.7.3 The compliance's description Statement . . . . . . . . . . . 24
>    4.7.4 The compliance's reference Statement . . . . . . . . . . . . 24
>    4.7.5 The compliance's mandatory Statement . . . . . . . . . . . . 24
>    4.7.6 The compliance's optional Statement  . . . . . . . . . . . . 24
>    4.7.7 The compliance's refine Statement  . . . . . . . . . . . . . 25
>    4.7.8 Usage Example  . . . . . . . . . . . . . . . . . . . . . . . 26
>    5.    NMRG-SMING-SNMP-EXT  . . . . . . . . . . . . . . . . . . . . 27
>    6.    NMRG-SMING-SNMP  . . . . . . . . . . . . . . . . . . . . . . 33
>    7.    Security Considerations  . . . . . . . . . . . . . . . . . . 47
>    8.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
>          Normative References . . . . . . . . . . . . . . . . . . . . 47
>          Informative References . . . . . . . . . . . . . . . . . . . 48
>          Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 49
>          Intellectual Property and Copyright Statements . . . . . . . 50
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 3]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
> 1. Introduction
> 
>    SMIng (Structure of Management Information, Next Generation)
>    [RFCxxx1] is a protocol-independent data definition language for
>    management information.  This memo defines an SMIng language
>    extension that specifies the mapping of SMIng definitions of
>    identities, classes, and their attributes and events to dedicated
>    definitions of nodes, scalar objects, tables and columnar objects,
>    and notifications for application in the SNMP management framework.
> 
>    Section 2 introduces basics of the SNMP management framework.
>    Section 3 defines how SMIng data types are mapped to the data types
>    supported by the SNMP protocol.  It introduces some new ASN.1 [ASN1]
>    definitions which are used to represent new SMIng base types such as
>    floats in the SNMP protocol.
> 
>    Section 4 describes the semantics of the SNMP mapping extensions for
>    SMIng.  The formal SMIng specification of the extension is provided
>    in Section 5.
> 
>    Section 6 contains an SMIng module which defines derived types (such
>    as RowStatus) that are specific to the SNMP mapping.
> 
> 1.1 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. SNMP Based Internet Management
> 
>    The SNMP network management framework [RFC3410] is based on the
>    concept of "managed objects".  Managed objects represent real or
>    synthesized variables of systems that are to be managed.  Note that
>    in spite of these terms this model is not object-oriented.  For
>    naming purposes, the managed objects are organized hierarchically in
>    an "object identifier tree", where only leaf nodes may represent
>    objects.
> 
>    Nodes in the object identifier tree may also identify conceptual
>    tables, rows of conceptual tables, notifications, groups of objects
>    and/or notifications, compliance statements, modules or other
>    information.  Each node is identified by an unique "object
>    identifier" value which is a sequence of non-negative numbers, named
>    "sub-identifiers", where the left-most sub-identifier refers to the
>    node next to the root of the tree and the right-most sub-identifier
>    refers to the node that is identified by the complete object
>    identifier value.  Each sub-identifier has a value between 0 and
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 4]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    2^32-1 (4294967295).
> 
>    The SMIng extensions described in this document are used to map SMIng
>    data definitions to SNMP compliant managed objects.  This mapping is
>    designed to be readable to computer programs, named MIB compilers, as
>    well as to human readers.
> 
> 2.1 Kinds of Nodes
> 
>    Each node in the object identifier tree is of a certain kind and may
>    represent management information or not:
> 
>    o  Simple nodes, that do not represent management information, but
>       may be used for grouping nodes in a subtree.  Those nodes are
>       defined by the `node' statement.  This statement can also be used
>       to map an SMIng `identity' to a node.
> 
>    o  Nodes representing the identity of a module to allow references to
>       a module in other objects of type `ObjectIdentifier'.  Those nodes
>       are defined by the `snmp' statement,
> 
>    o  Scalar objects, which have exactly one object instance and no
>       child nodes.  See Section 2.2 for scalar objects' instances.  A
>       set of scalar objects is mapped from one or more SMIng classes
>       using the `scalars' statement.  The statement block of the
>       `scalars' statement contains one `implements' statement for each
>       class.  The associated statement blocks in turn contain `object'
>       statements that specify the mapping of attributes to scalar
>       objects.  Scalar objects MUST not have any child node.
> 
>    o  Tables, which represent the root node of a collection of
>       information structured in table rows.  Table nodes are defined by
>       the `table' statement.  A table object identifier SHOULD not have
>       any other child node than the implicitly defined row node (see
>       below).
> 
>    o  Rows, which belong to a table (that is, row's object identifier
>       consists of the table's full object identifier plus a single `1'
>       sub-identifier) and represent a sequence of one or more columnar
>       objects.  A row node is implicitly defined for each table node.
> 
>    o  Columnar objects, which belong to a row (that is, the columnar
>       objects' object identifier consists of the row's full object
>       identifier plus a single column-identifying sub-identifier) and
>       have zero or more object instances and no child nodes.  They are
>       defined as follows: The classes that are implemented by a `table'
>       statement are identified by `implements' statements.  The
>       statement block of each `implements' statement contains `object'
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 5]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>       statements that specify the mapping of attributes to columnar
>       objects of this table.  Columnar objects MUST not have any child
>       node.
> 
>    o  Notifications, which represent information that is sent by agents
>       within unsolicited transmissions.  The `notification' statement is
>       used to map an SMIng event to a notification.  A notification's
>       object identifier SHOULD not have any child node.
> 
>    o  Groups of objects and notifications, which may be used for
>       compliance statements.  They are defined using the `group'
>       statement.
> 
>    o  Compliance statements which define requirements for MIB module
>       implementations.  They are defined using the `compliance'
>       statement.
> 
> 
> 2.2 Scalar and Columnar Object Instances
> 
>    Instances of managed objects are identified by appending an
>    instance-identifier to the object's object identifier.  Scalar
>    objects and columnar objects use different ways to construct the
>    instance-identifier.
> 
>    Scalar objects have exactly one object instance.  It is identified by
>    appending a single `0' sub-identifier to the object identifier of the
>    scalar object.
> 
>    Within tables, different instances of the same columnar object are
>    identified by appending a sequence of one or more sub-identifiers to
>    the object identifier of the columnar object which consists of the
>    values of object instances that unambiguously distinguish a table
>    row.  These indexing objects can be columnar objects of the same and/
>    or another table, but MUST NOT be scalar objects.  Multiple
>    applications of the same object in a single table indexing
>    specification are strongly discouraged.
> 
>    The base types of the indexing objects indicate how to form the
>    instance-identifier:
> 
>    o  integer-valued or enumeration-valued: a single sub-identifier
>       taking the integer value (this works only for non-negative
>       integers and integers of a size of up to 32 bits),
> 
>    o  string-valued, fixed-length strings (or variable-length with
>       compact encoding): `n' sub-identifiers, where `n' is the length of
>       the string (each octet of the string is encoded in a separate
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 6]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>       sub-identifier),
> 
>    o  string-valued, variable-length strings or bits-valued: `n+1'
>       sub-identifiers, where `n' is the length of the string or bits
>       encoding (the first sub-identifier is `n' itself, following this,
>       each octet of the string or bits is encoded in a separate
>       sub-identifier),
> 
>    o  object identifier-valued (with compact encoding): `n'
>       sub-identifiers, where `n' is the number of sub-identifiers in the
>       value (each sub-identifier of the value is copied into a separate
>       sub-identifier),
> 
>    o  object identifier-valued: `n+1' sub-identifiers, where `n' is the
>       number of sub-identifiers in the value (the first sub-identifier
>       is `n' itself, following this, each sub-identifier in the value is
>       copied),
> 
>    Note that compact encoding can only be applied to an object having a
>    variable-length syntax (e.g., variable-length strings, bits objects
>    or object identifier-valued objects).  Further, compact encoding can
>    only be associated with the last object in a list of indexing
>    objects.  Finally, compact encoding MUST NOT be used on a
>    variable-length string object if that string might have a value of
>    zero-length.
> 
>    Instances identified by use of integer-valued or enumeration-valued
>    objects are RECOMMENDED to be numbered starting from one (i.e., not
>    from zero).  Integer objects that allow negative values, Unsigned64
>    objects, Integer64 objects and floating point objects MUST NOT be
>    used for table indexing.
> 
>    Objects which are both specified for indexing in a row and also
>    columnar objects of the same row are termed auxiliary objects.
>    Auxiliary objects SHOULD be non-accessible, except in the following
>    circumstances:
> 
>    o  within a module originally written to conform to SMIv1, or
> 
>    o  a row must contain at least one columnar object which is not an
>       auxiliary object.  In the event that all of a row's columnar
>       objects are also specified to be indexing objects then one of them
>       MUST be accessible.
> 
> 
> 2.3 Object Identifier Hierarchy
> 
>    The layers of the object identifier tree near the root are well
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 7]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    defined and organized by standardization bodies.  The first level
>    next to the root has three nodes:
> 
>       0: ccitt
> 
>       1: iso
> 
>       2: joint-iso-ccitt
> 
>    Note that the renaming of the Commite Consultatif International de
>    Telegraphique et Telephonique (CCITT) to International
>    Telecommunications Union (ITU) had no consequence on the names used
>    in the object identifier tree.
> 
>    The root of the subtree administered by the Internet Assigned Numbers
>    Authority (IANA) for the Internet is `1.3.6.1' which is assigned with
>    the identifier `internet'.  That is, the Internet subtree of object
>    identifiers starts with the prefix `1.3.6.1.'.
> 
>    Several branches underneath this subtree are used for network
>    management:
> 
>    The `mgmt' (internet.2) subtree is used to identify "standard"
>    definitions.  An information module produced by an IETF working group
>    becomes a "standard" information module when the document is first
>    approved by the IESG and enters the Internet standards track.
> 
>    The `experimental' (internet.3) subtree is used to identify
>    experimental definitions being designed by working groups of the IETF
>    or IRTF.  If an information module produced by a working group
>    becomes a "standard" module, then at the very beginning of its entry
>    onto the Internet standards track, the definitions are moved under
>    the mgmt subtree.
> 
>    The `private' (internet.4) subtree is used to identify definitions
>    defined unilaterally.  The `enterprises' (private.1) subtree beneath
>    private is used, among other things, to permit providers of
>    networking subsystems to register information modules of their
>    products.
> 
>    These and some other nodes are defined in the SMIng module
>    NMRG-SMING-SNMP-EXT (Section 5).
> 
> 3. SMIng Data Type Mappings
> 
>    SMIng [RFCxxx1] supports the following set of base types:
>    OctetString, Pointer, Integer32, Integer64, Unsigned32, Unsigned64,
>    Float32, Float64, Float128, Enumeration, Bits, and ObjectIdentifier.
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 8]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    The SMIng core module NMRG-SMING [RFCxxx2] defines additional derived
>    types, among them Counter32 (derived from Unsigned32), Counter64
>    (derived from Unsigned64), TimeTicks32 and TimeTicks64 (derived from
>    Unsigned32 and Unsigned64), IpAddress (derived from OctetString), and
>    Opaque (derived from OctetString).
> 
>    The version 2 of the protocol operations for SNMP document [RFC3416]
>    defines the following 9 data types which are distinguished by the
>    protocol: INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress,
>    Counter32, TimeTicks, Opaque, Counter64, Unsigned32.
> 
>    The SMIng base types and their derived types are mapped to SNMP data
>    types according to the following table:
> 
> 
>            SMIng Data Type    SNMP Data Type         Comment
>            ---------------    -------------------    -------
>            OctetString        OCTET STRING           (1)
>            Pointer            OBJECT IDENTIFIER
>            Integer32          INTEGER
>            Integer64          Opaque (Integer64)     (2)
>            Unsigned32         Unsigned32             (3)
>            Unsigned64         Opaque (Unsigned64)    (2) (4)
>            Float32            Opaque (Float32)       (2)
>            Float64            Opaque (Float64)       (2)
>            Float128           Opaque (Float128)      (2)
>            Enumeration        INTEGER
>            Bits               OCTET STRING
>            ObjectIdentifier   OBJECT IDENTIFIER
> 
>            Counter32          Counter32
>            Counter64          Counter64
>            TimeTicks32        TimeTicks
>            TimeTicks64        Opaque (Unsigned64)    (2)
>            IpAddress          IpAddress
>            Opaque             Opaque
> 
>    (1) This mapping includes all types derived from the OctetString type
>       except those types derived from the IpAddress and Opaque SMIng
>       types defined in [RFCxxx2].
> 
>    (2) This type is encoded according to the ASN.1 type with the same
>       name defined in Section 3.1.  The resulting BER encoded value is
>       then wrapped in an Opaque value.
> 
>    (3) This mapping includes all types derived from the Unsigned32 type
>       except those types derived from the Counter32 and TimeTicks32
>       SMIng types defined in [RFCxxx2].
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004               [Page 9]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    (4) This mapping includes all types derived from the Unsigned64 type
>       except those types derived from the Counter64 SMIng type defined
>       in [RFCxxx2].
> 
> 
> 3.1 ASN.1 Definitions
> 
>    The ASN.1 [ASN1] type definitions below introduce data types which
>    are used to map the new SMIng base types into the set of ASN.1 types
>    supported by the second version of SNMP protocol operations
>    [RFC3416].
> 
> 
>    NMRG-SMING-SNMP-MAPPING DEFINITIONS ::= BEGIN
> 
>    Integer64 ::=
>        [APPLICATION 10]
>            IMPLICIT INTEGER (-9223372036854775808..9223372036854775807)
> 
>    Unsigned64
>        [APPLICATION 11]
>            IMPLICIT INTEGER (0..18446744073709551615)
> 
>    Float32
>        [APPLICATION 12]
>            IMPLICIT OCTET STRING (SIZE (4))
> 
>    Float64
>        [APPLICATION 13]
>            IMPLICIT OCTET STRING (SIZE (8))
> 
>    Float128
>        [APPLICATION 14]
>            IMPLICIT OCTET STRING (SIZE (16))
> 
>    END
> 
> 
>    The definitions of Integer64 and Unsigned64 are consistent with the
>    same definitions in the SPPI [RFC3159].  The floating point types
>    Float32, Float64 and Float128 support single, double and quadruple
>    IEEE floating point values.  The encoding of the values follows the
>    "IEEE Standard for Binary Floating-Point Arithmetic" as defined in
>    ANSI/IEEE Standard 754-1985 [IEEE754].
> 
> 4. The snmp Extension Statement
> 
>    The `snmp' statement is the main statement of the SNMP mapping
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 10]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    specification.  It gets one or two arguments: an optional lower-case
>    identifier that specifies a node that represents the module's
>    identity, and a mandatory statement block that contains all details
>    of the SNMP mapping.  All information of an SNMP mapping are mapped
>    to an SNMP conformant module of the same name as the containing SMIng
>    module.  A single SMIng module must not contain more than one `snmp'
>    statement.
> 
> 4.1 The oid Statement
> 
>    The snmp's `oid' statement, which must be present, if the snmp
>    statement contains a module identifier and must be absent otherwise,
>    gets one argument which specifies the object identifier value that is
>    assigned to this module's identity node.
> 
> 4.2 The node Statement
> 
>    The `node' statement is used to name and describe a node in the
>    object identifier tree, without associating any class or attribute
>    information with this node.  This may be useful to group definitions
>    in a subtree of related management information, or to uniquely define
>    an SMIng `identity' to be referenced in attributes of type Pointer.
>    The `node' statement gets two arguments: a lower-case node identifier
>    and a statement block that holds detailed node information in an
>    obligatory order.
> 
>    See the `nodeStatement' rule of the grammar (Section 5) for the
>    formal syntax of the `node' statement.
> 
> 4.2.1 The node's oid Statement
> 
>    The node's `oid' statement, which must be present, gets one argument
>    which specifies the object identifier value that is assigned to this
>    node.
> 
> 4.2.2 The node's represents Statement
> 
>    The node's `represents' statement, which need not be present, makes
>    this node represent an SMIng identity, so that objects of type
>    Pointer can reference that identity.  The statement gets one argument
>    which specifies the identity name.
> 
> 4.2.3 The node's status Statement
> 
>    The node's `status' statement, which must be present, gets one
>    argument which is used to specify whether this node definition is
>    current or historic.  The value `current' means that the definition
>    is current and valid.  The value `obsolete' means the definition is
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 11]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    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.
> 
> 4.2.4 The node's description Statement
> 
>    The node's `description' statement, which need not be present, gets
>    one argument which is used to specify a high-level textual
>    description of this node.
> 
>    It is RECOMMENDED to include all semantics and purposes of this node.
> 
> 4.2.5 The node's reference Statement
> 
>    The node'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
>    definitions, or some other document which provides additional
>    information relevant to this node.
> 
> 4.2.6 Usage Examples
> 
>        node iso                            { oid 1;     status current; };
>        node   org                          { oid iso.3; status current; };
>        node     dod                        { oid org.6; status current; };
>        node       internet                 { oid dod.1; status current; };
> 
>        node   zeroDotZero {
>            oid         0.0;
>            represents  NMRG-SMING::null;
>            status      current;
>            description "A null value used for pointers.";
>        };
> 
> 4.3 The scalars Statement
> 
>    The `scalars' statement is used to define the mapping of one or more
>    classes to a group of SNMP scalar managed objects organized under a
>    common parent node.  The `scalars' statement gets two arguments: a
>    lower-case scalar group identifier and a statement block that holds
>    detailed mapping information of this scalar group in an obligatory
>    order.
> 
>    See the `scalarsStatement' rule of the grammar (Section 5) for the
>    formal syntax of the `scalars' statement.
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 12]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
> 4.3.1 The scalars' oid Statement
> 
>    The scalars' `oid' statement, which must be present, gets one
>    argument which specifies the object identifier value that is assigned
>    to the common parent node of this scalar group.
> 
> 4.3.2 The scalars' object Statement
> 
>    The scalars' `object' statement, which must be present at least once,
>    makes this scalar group contain a given scalar object.  It gets two
>    arguments: the name of the scalar object to be defined and a
>    statement block that holds additional detailed information in an
>    obligatory order.
> 
> 4.3.2.1 The object's implements Statement
> 
>    The `implements' statement, which must be present, is used to specify
>    a single leaf attribute of a class that is implemented by this scalar
>    object.  The type of this attribute must be a simple type, i.e.  not
>    a class.
> 
> 4.3.2.2 The object's subid Statement
> 
>    The `subid' statement, which need not be present, is used to specify
>    the sub-identifier that identifies the scalar object within this
>    scalar group, i.e.  the object identifier of the scalar object is the
>    concatenation of the values of this scalar group's oid statement and
>    of this subid statement.
> 
>    If this statement is omitted, the sub-identifier is the one of the
>    previous object statement within this scalar group plus 1.  If the
>    containing object statement is the first one within the containing
>    scalar group and the subid statement is omitted, the sub-identifier
>    is 1.
> 
> 4.3.2.3 The object's status Statement
> 
>    The object's `status' statement, which need not be present, gets one
>    argument which is used to specify whether this scalar object
>    definition is current or historic.  The value `current' means that
>    the definition is current and valid.  The value `obsolete' means the
>    definition is obsolete and should not be implemented and/or can be
>    removed if previously implemented.  While the value `deprecated' also
>    indicates an obsolete definition, it permits new/continued
>    implementation in order to foster interoperability with older/
>    existing implementations.
> 
>    Scalar objects SHOULD NOT be defined as `current' if the implemented
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 13]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    attribute definition is `deprecated' or `obsolete'.  Similarly, they
>    SHOULD NOT be defined as `deprecated' if the implemented attribute is
>    `obsolete'.  Nevertheless, subsequent revisions of used class
>    definitions cannot be avoided, but SHOULD be taken into account in
>    subsequent revisions of the local module.
> 
>    Note that it is RECOMMENDED to omit the status statement which means
>    that the status is inherited from the containing scalars statement.
>    However, if the status of a scalar object varies from the containing
>    scalar group, it has to be expressed explicitly, e.g., if the
>    implemented attribute has been deprecated or obsoleted.
> 
> 4.3.2.4 The object's description Statement
> 
>    The object's `description' statement, which need not be present, gets
>    one argument which is used to specify a high-level textual
>    description of this scalar object.
> 
>    Note that in contrast to other definitions this description statement
>    is not mandatory and it is RECOMMENDED to omit it, if the object is
>    fully described by the description of the implemented attribute.
> 
> 4.3.2.5 The object's reference Statement
> 
>    The object'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
>    definitions, or some other document which provides additional
>    information relevant to this scalar object.
> 
>    It is RECOMMENDED to omit this statement, if the object's references
>    are fully described by the implemented attribute.
> 
> 4.3.3 The scalars' status Statement
> 
>    The scalars' `status' statement, which must be present, gets one
>    argument which is used to specify whether this scalar group
>    definition is current or historic.  The value `current' means that
>    the definition is current and valid.  The value `obsolete' means the
>    definition is obsolete and should not be implemented and/or can be
>    removed if previously implemented.  While the value `deprecated' also
>    indicates an obsolete definition, it permits new/continued
>    implementation in order to foster interoperability with older/
>    existing implementations.
> 
> 4.3.4 The scalars' description Statement
> 
>    The scalars' `description' statement, which must be present, gets one
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 14]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    argument which is used to specify a high-level textual description of
>    this scalar group.
> 
>    It is RECOMMENDED to include all semantic definitions necessary for
>    the implementation of this scalar group.
> 
> 4.3.5 The scalars' reference Statement
> 
>    The scalars' `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
>    definitions, or some other document which provides additional
>    information relevant to this scalars statement.
> 
> 4.3.6 Usage Example
> 
>        scalars ip {
>          oid             mib-2.4;
>          object ipForwarding { implements Ip.forwarding; };
>          object ipDefaultTTL { implements Ip.defaultTTL; };
>          // ...
>          status          current;
>          description
>                  "This scalar group implements the Ip class.";
>        };
> 
> 4.4 The table Statement
> 
>    The `table' statement is used to define the mapping of one or more
>    classes to a single SNMP table of columnar managed objects.  The
>    `table' statement gets two arguments: a lower-case table identifier
>    and a statement block that holds detailed mapping information of this
>    table in an obligatory order.
> 
>    See the `tableStatement' rule of the grammar (Section 5) for the
>    formal syntax of the `table' statement.
> 
> 4.4.1 The table's oid Statement
> 
>    The table's `oid' statement, which must be present, gets one argument
>    which specifies the object identifier value that is assigned to this
>    table's node.
> 
> 4.4.2 Table Indexing Statements
> 
>    SNMP table mappings offers five methods to supply table indexing
>    information: ordinary tables, table augmentations, sparse table
>    augmentations, table expansions, and reordered tables use different
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 15]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    statements to denote their indexing information.  Each table
>    definition must contain exactly one of the following indexing
>    statements.
> 
> 4.4.2.1 The table's index Statement for Table Indexing
> 
>    The table's `index' statement, which is used to supply table indexing
>    information of base tables, gets one argument that specifies a
>    comma-separated list of objects, that are used for table indexing,
>    enclosed in parenthesis.
> 
>    The elements of the `unique' statement of the implemented class(es)
>    and their order should be regarded as a hint for the index elements
>    of the table.
> 
>    In case of modules that should be compatible on the SNMP protocol
>    level to SMIv2 versions of the module, an optional `implied' keyword
>    may be added in front of the list to indicate a compact encoding of
>    the last object in the list.  See Section 2.2 for details.
> 
> 4.4.2.2 The table's augments Statement for Table Indexing
> 
>    The table's `augments' statement, which is used to supply table
>    indexing information of tables that augment a base table, gets one
>    argument that specifies the identifier of the table to be augmented.
>    Note that a table augmentation cannot itself be augmented.  Anyhow, a
>    base table may be augmented by multiple table augmentations.
> 
>    A table augmentation makes instances of subordinate columnar objects
>    identified according to the index specification of the base table
>    corresponding to the table named in the `augments' statement.
>    Further, instances of subordinate columnar objects of a table
>    augmentation exist according to the same semantics as instances of
>    subordinate columnar objects of the base table being augmented.  As
>    such, note that creation of a base table row implies the
>    correspondent creation of any table row augmentations.  Table
>    augmentations MUST NOT be used in table row creation and deletion
>    operations.
> 
> 4.4.2.3 The table's extends Statement for Table Indexing
> 
>    The table's `extends' statement, which is used to supply table
>    indexing information of tables that sparsely augment a base table,
>    gets one argument that specifies the identifier of the table to be
>    sparsely augmented.  Note that a sparse table augmentation cannot
>    itself be augmented.  Anyhow, a base table may be augmented by
>    multiple table augmentations, sparsely or not.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 16]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    A sparse table augmentation makes instances of subordinate columnar
>    objects identified, if present, according to the index specification
>    of the base table corresponding to the table named in the `extends'
>    statement.  Further, instances of subordinate columnar objects of a
>    sparse table augmentation exist according to the semantics as
>    instances of subordinate columnar objects of the base table and the
>    (non-formal) rules that confine the sparse relationship.  As such,
>    note that creation of a sparse table row augmentation may be implied
>    by the creation of a base table row as well as done by an explicit
>    creation.  However, if a base table row gets deleted, any dependent
>    sparse table row augmentations get also deleted implicitly.
> 
> 4.4.2.4 The table's reorders Statement for Table Indexing
> 
>    The table's `reorders' statement is used to supply table indexing
>    information of tables, that contain exactly the same index objects of
>    a base table but in a different order.  It gets at least two
>    arguments.  The first one specifies the identifier of the base table.
>    The second one specifies a comma-separated list of exactly those
>    object identifiers of the base table's `index' statement, but in the
>    order to be used in this table.  Note that a reordered table cannot
>    itself be reordered.  Anyhow, a base table may be used for multiple
>    reordered tables.
> 
>    Under some circumstances, an optional `implied' keyword may be added
>    in front of the list to indicate a compact encoding of the last
>    object in the list.  See Section 2.2 for details.
> 
>    Instances of subordinate columnar objects of a reordered table exist
>    according to the same semantics as instances of subordinate columnar
>    objects of the base table.  As such, note that creation of a base
>    table row implies the correspondent creation of any related reordered
>    table row.  Reordered tables MUST NOT be used in table row creation
>    and deletion operations.
> 
> 4.4.2.5 The table's expands Statement for Table Indexing
> 
>    The table's `expands' statement is used to supply table indexing
>    information of table expansions.  Table expansions use exactly the
>    same index objects of another table together with additional indexing
>    objects.  Thus, the `expands' statement gets at least two arguments.
>    The first one specifies the identifier of the base table.  The second
>    one specifies a comma-separated list of the additional object
>    identifiers used for indexing.  Note that an expanded table may
>    itself be expanded, and base tables may be used for multiple table
>    expansions.
> 
>    Under some circumstances, an optional `implied' keyword may be added
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 17]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    in front of the list to indicate a compact encoding of the last
>    object in the list.  See Section 2.2 for details.
> 
> 4.4.3 The table's create Statement
> 
>    The table's `create' statement, which need not be present, gets no
>    argument.  If the `create' statement is present, table row creation
>    (and deletion) is possible.
> 
> 4.4.4 The table's object Statement
> 
>    The table's `object' statement, which must be present at least once,
>    makes this table contain a given columnar object.  It gets two
>    arguments: the name of the columnar object to be defined and a
>    statement block that holds additional detailed information in an
>    obligatory order.
> 
> 4.4.4.1 The object's implements Statement
> 
>    The `implements' statement, which must be present, is used to specify
>    a single leaf attribute of a class that is implemented by this
>    columnar object.  The type of this attribute must be a simple type,
>    i.e.  not a class.
> 
> 4.4.4.2 The object's subid Statement
> 
>    The `subid' statement, which need not be present, is used to specify
>    the sub-identifier that identifies the columnar object within this
>    table, i.e.  the object identifier of the columnar object is the
>    concatenation of the values of this table's oid statement and of this
>    subid statement.
> 
>    If this statement is omitted, the sub-identifier is the one of the
>    previous object statement within this table plus 1.  If the
>    containing object statement is the first one within the containing
>    table and the subid statement is omitted, the sub-identifier is 1.
> 
> 4.4.4.3 The object's status Statement
> 
>    The object's `status' statement, which need not be present, gets one
>    argument which is used to specify whether this columnar object
>    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    Expires April 28, 2004              [Page 18]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    Columnar objects SHOULD NOT be defined as `current' if the
>    implemented attribute definition is `deprecated' or `obsolete'.
>    Similarly, they SHOULD NOT be defined as `deprecated' if the
>    implemented attribute is `obsolete'.  Nevertheless, subsequent
>    revisions of used class definitions cannot be avoided, but SHOULD be
>    taken into account in subsequent revisions of the local module.
> 
>    Note that it is RECOMMENDED to omit the status statement which means
>    that the status is inherited from the containing table statement.
>    However, if the status of a columnar object varies from the
>    containing table, it has to be expressed explicitly, e.g., if the
>    implemented attribute has been deprecated or obsoleted.
> 
> 4.4.4.4 The object's description Statement
> 
>    The object's `description' statement, which need not be present, gets
>    one argument which is used to specify a high-level textual
>    description of this columnar object.
> 
>    Note that in contrast to other definitions this description statement
>    is not mandatory and it is RECOMMENDED to omit it, if the object is
>    fully described by the description of the implemented attribute.
> 
> 4.4.4.5 The object's reference Statement
> 
>    The object'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
>    definitions, or some other document which provides additional
>    information relevant to this columnar object.
> 
>    It is RECOMMENDED to omit this statement, if the object's references
>    are fully described by the implemented attribute.
> 
> 4.4.5 The table's status Statement
> 
>    The table's `status' statement, which must be present, gets one
>    argument which is used to specify whether this table definition is
>    current or historic.  The value `current' means that the definition
>    is current and valid.  The value `obsolete' means the definition is
>    obsolete and should not be implemented and/or can be removed if
>    previously implemented.  While the value `deprecated' also indicates
>    an obsolete definition, it permits new/continued implementation in
>    order to foster interoperability with older/existing implementations.
> 
> 4.4.6 The table's description Statement
> 
>    The table's `description' statement, which must be present, gets one
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 19]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    argument which is used to specify a high-level textual description of
>    this table.
> 
>    It is RECOMMENDED to include all semantic definitions necessary for
>    the implementation of this table.
> 
> 4.4.7 The table's reference Statement
> 
>    The table'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
>    definitions, or some other document which provides additional
>    information relevant to this table statement.
> 
> 4.4.8 Usage Example
> 
>        table ifTable {
>          oid             interfaces.2;
>          index           (ifIndex);
>          object ifIndex { implements Interface.index;       };
>          object ifDescr { implements Interface.description; };
>          // ...
>          status          current;
>          description
>                  "This table implements the Interface class.";
>        };
> 
> 4.5 The notification Statement
> 
>    The `notification' statement is used to map events defined within
>    classes to SNMP notifications.  The `notification' statement gets two
>    arguments: a lower-case notification identifier and a statement block
>    that holds detailed notification information in an obligatory order.
> 
>    See the `notificationStatement' rule of the grammar (Section 5) for
>    the formal syntax of the `notification' statement.
> 
> 4.5.1 The notification's oid Statement
> 
>    The notification's `oid' statement, which must be present, gets one
>    argument which specifies the object identifier value that is assigned
>    to this notification.
> 
> 4.5.2 The notification's signals Statement
> 
>    The notification's `signals' statement, which must be present,
>    denotes the event that is signaled by this notification.  The
>    statement gets two arguments: the event to be signaled (in the
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 20]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    qualified form `Class.event') and a statement block that holds
>    detailed information on the objects transmitted with this
>    notification in an obligatory order.
> 
> 4.5.2.1 The signals' object Statement
> 
>    The signals' `object' statement, which can be present zero, one or
>    multiple times, makes a single instance of a class attribute be
>    contained in this notification.  It gets one argument: the specific
>    class attribute.  The namespace of attributes not specified by
>    qualified names is the namespace of the event's class specified in
>    the `signals' statement.
> 
> 4.5.3 The notification's status Statement
> 
>    The notification's `status' statement, which must be present, gets
>    one argument which is used to specify whether this notification
>    definition is current or historic.  The value `current' means that
>    the definition is current and valid.  The value `obsolete' means the
>    definition is obsolete and should not be implemented and/or can be
>    removed if previously implemented.  While the value `deprecated' also
>    indicates an obsolete definition, it permits new/continued
>    implementation in order to foster interoperability with older/
>    existing implementations.
> 
> 4.5.4 The notification's description Statement
> 
>    The notification's `description' statement, which need not be
>    present, gets one argument which is used to specify a high-level
>    textual description of this notification.
> 
>    It is RECOMMENDED to include all semantics and purposes of this
>    notification.
> 
> 4.5.5 The notification's reference Statement
> 
>    The notification'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
>    definitions, or some other document which provides additional
>    information relevant to this notification statement.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 21]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
> 4.5.6 Usage Example
> 
>        notification linkDown {
>            oid         snmpTraps.3;
>            signals     Interface.linkDown {
>                object      ifIndex;
>                object      ifAdminStatus;
>                object      ifOperStatus;
>            };
>            status      current;
>            description
>                  "This notification signals the linkDown event
>                   of the Interface class.";
>        };
> 
> 4.6 The group Statement
> 
>    The `group' statement is used to define a group of arbitrary nodes in
>    the object identifier tree.  It gets two arguments: a lower-case
>    group identifier and a statement block that holds detailed group
>    information in an obligatory order.
> 
>    Note that the primary application of groups are compliance
>    statements, although they might be referred in other formal or
>    informal documents.
> 
>    See the `groupStatement' rule of the grammar (Section 5) for the
>    formal syntax of the `group' statement.
> 
> 4.6.1 The group's oid Statement
> 
>    The group's `oid' statement, which must be present, gets one argument
>    which specifies the object identifier value that is assigned to this
>    group.
> 
> 4.6.2 The group's members Statement
> 
>    The group's `members' statement, which must be present, gets one
>    argument which specifies the list of nodes by their identifiers to be
>    contained in this group.  The list of nodes has to be comma-separated
>    and enclosed in parenthesis.
> 
> 4.6.3 The group's status Statement
> 
>    The group's `status' statement, which must be present, gets one
>    argument which is used to specify whether this group definition is
>    current or historic.  The value `current' means that the definition
>    is current and valid.  The value `obsolete' means the definition is
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 22]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    obsolete and the group should no longer be used.  While the value
>    `deprecated' also indicates an obsolete definition, it permits new/
>    continued use of this group.
> 
> 4.6.4 The group's description Statement
> 
>    The group's `description' statement, which must be present, gets one
>    argument which is used to specify a high-level textual description of
>    this group.  It is RECOMMENDED to include any relation to other
>    groups.
> 
> 4.6.5 The group's reference Statement
> 
>    The group's `reference' statement, which need not be present, gets
>    one argument which is used to specify a textual cross-reference to
>    some other document, either another module which defines related
>    groups, or some other document which provides additional information
>    relevant to this group.
> 
> 4.6.6 Usage Example
> 
>    The snmpGroup, originally defined in [RFC3418], may be described as
>    follows:
> 
>        group snmpGroup {
>          oid             snmpMIBGroups.8;
>          objects         (snmpInPkts, snmpInBadVersions,
>                           snmpInASNParseErrs,
>                           snmpSilentDrops, snmpProxyDrops,
>                           snmpEnableAuthenTraps);
>          status          current;
>          description
>                  "A collection of objects providing basic
>                   instrumentation and control of an agent.";
>        };
> 
> 4.7 The compliance Statement
> 
>    The `compliance' statement is used to define a set of conformance
>    requirements, named a `compliance statement'.  It gets two arguments:
>    a lower-case compliance identifier and a statement block that holds
>    detailed compliance information in an obligatory order.
> 
>    See the `complianceStatement' rule of the grammar (Section 5) for the
>    formal syntax of the `compliance' statement.
> 
> 4.7.1 The compliance's oid Statement
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 23]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    The compliance's `oid' statement, which must be present, gets one
>    argument which specifies the object identifier value that is assigned
>    to this compliance statement.
> 
> 4.7.2 The compliance's status Statement
> 
>    The compliance's `status' statement, which must be present, gets one
>    argument which is used to specify whether this compliance statement
>    is current or historic.  The value `current' means that the
>    definition is current and valid.  The value `obsolete' means the
>    definition is obsolete and no longer specifies a valid definition of
>    conformance.  While the value `deprecated' also indicates an obsolete
>    definition, it permits new/continued use of the compliance
>    specification.
> 
> 4.7.3 The compliance's description Statement
> 
>    The compliance's `description' statement, which must be present, gets
>    one argument which is used to specify a high-level textual
>    description of this compliance statement.
> 
> 4.7.4 The compliance's reference Statement
> 
>    The compliance's `reference' statement, which need not be present,
>    gets one argument which is used to specify a textual cross-reference
>    to some other document, either another module which defines related
>    compliance statements, or some other document which provides
>    additional information relevant to this compliance statement.
> 
> 4.7.5 The compliance's mandatory Statement
> 
>    The compliance's `mandatory' statement, which need not be present,
>    gets one argument which is used to specify a comma-separated list of
>    one or more groups (Section 4.6) of objects and/or notifications
>    enclosed in parenthesis.  These groups are unconditionally mandatory
>    for implementation.
> 
>    If an agent claims compliance to a MIB module then it must implement
>    each and every object and notification within each group listed in
>    the `mandatory' statement(s) of the compliance statement(s) of that
>    module.
> 
> 4.7.6 The compliance's optional Statement
> 
>    The compliance's `optional' statement, which need not be present, is
>    repeatedly used to name each group which is conditionally mandatory
>    for compliance to the compliance statement.  It can also be used to
>    name unconditionally optional groups.  A group named in an `optional'
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 24]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    statement MUST be absent from the correspondent `mandatory'
>    statement.  The `optional' statement gets two arguments: a lower-case
>    group identifier and a statement block that holds detailed compliance
>    information on that group.
> 
>    Conditionally mandatory groups include those groups which are
>    mandatory only if a particular protocol is implemented, or only if
>    another group is implemented.  The `description' statement specifies
>    the conditions under which the group is conditionally mandatory.
> 
>    A group which is named in neither a `mandatory' statement nor an
>    `optional' statement, is unconditionally optional for compliance to
>    the module.
> 
>    See the `optionalStatement' rule of the grammar (Section 5) for the
>    formal syntax of the `optional' statement.
> 
> 4.7.6.1 The optional's description Statement
> 
>    The optional's `description' statement, which must be present, gets
>    one argument which is used to specify a high-level textual
>    description of the conditions under which this group is conditionally
>    mandatory or unconditionally optional.
> 
> 4.7.7 The compliance's refine Statement
> 
>    The compliance's `refine' statement, which need not be present, is
>    repeatedly used to specify each object for which compliance has a
>    refined requirement with respect to the module definition.  The
>    object must be present in one of the conformance groups named in the
>    correspondent `mandatory' or `optional' statements.  The `refine'
>    statement gets two arguments: a lower-case identifier of a scalar or
>    columnar object and a statement block that holds detailed refinement
>    information on that object.
> 
>    See the `refineStatement' rule of the grammar (Section 5) for the
>    formal syntax of the `refine' statement.
> 
> 4.7.7.1 The refine's type Statement
> 
>    The refine's `type' statement, which need not be present, gets one
>    argument that is used to provide a refined type for the correspondent
>    object.  Type restrictions may be applied by appending subtyping
>    information according to the rules of the base type.  See [RFCxxx1]
>    for SMIng base types and their type restrictions.  In case of
>    enumeration or bitset types the order of named numbers is not
>    significant.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 25]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    Note that if a `type' and a `writetype' statement are both present
>    then this type only applies when instances of the correspondent
>    object are read.
> 
> 4.7.7.2 The refine's writetype Statement
> 
>    The refine's `writetype' statement, which need not be present, gets
>    one argument that is used to provide a refined type for the
>    correspondent object, only when instances of that object are written.
>    Type restrictions may be applied by appending subtyping information
>    according to the rules of the base type.  See [RFCxxx1] for SMIng
>    base types and their type restrictions.  In case of enumeration or
>    bitset types the order of named numbers is not significant.
> 
> 4.7.7.3 The refine's access Statement
> 
>    The refine's `access' statement, which need not be present, gets one
>    argument that is used to specify the minimal level of access that the
>    correspondent object must implement in the sense of its original
>    `access' statement.  Hence, the refine's `access' statement MUST NOT
>    specify a greater level of access than is specified in the
>    correspondent object definition.
> 
>    An implementation is compliant if the level of access it provides is
>    greater or equal to the minimal level in the refine's `access'
>    statement and less or equal to the maximal level in the object's
>    `access' statement.
> 
> 4.7.7.4 The refine's description Statement
> 
>    The refine's `description' statement, which must be present, gets one
>    argument which is used to specify a high-level textual description of
>    the refined compliance requirement.
> 
> 4.7.8 Usage Example
> 
>    The compliance statement contained in the SNMPv2-MIB [RFC3418],
>    converted to SMIng:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 26]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>        compliance snmpBasicComplianceRev2 {
>          oid             snmpMIBCompliances.3;
>          status          current;
>          description
>                  "The compliance statement for SNMP entities which
>                   implement this MIB module.";
> 
>          mandatory       (snmpGroup, snmpSetGroup, systemGroup,
>                           snmpBasicNotificationsGroup);
> 
>          optional snmpCommunityGroup {
>            description
>                  "This group is mandatory for SNMP entities which
>                   support community-based authentication.";
>          };
>          optional snmpWarmStartNotificationGroup {
>            description
>                  "This group is mandatory for an SNMP entity which
>                   supports command responder applications, and is
>                   able to reinitialize itself such that its
>                   configuration is unaltered.";
>          };
>        };
> 
> 5. NMRG-SMING-SNMP-EXT
> 
>    The grammar of the snmp statement (including all its contained
>    statements) conforms to the Augmented Backus-Naur Form (ABNF)
>    [RFC2234].  It is included in the abnf statement of the snmp SMIng
>    extension definition in the NMRG-SMING-SNMP-EXT module below.
> 
>    module NMRG-SMING-SNMP-EXT {
> 
>        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: [phone]
>                         EMail: [e-mail]
> 
>                         Juergen Schoenwaelder
>                         International University Bremen
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 27]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                         P.O. Box 750 561
>                         28725 Bremen
>                         Germany
>                         Phone: [phone]
>                         EMail: [e-mail]";
> 
>        description     "This module defines a SMIng extension to define
>                         the mapping of SMIng definitions of class and
>                         their attributes and events to SNMP compatible
>                         definitions of modules, node, scalars, tables,
>                         and notifications, and additional information on
>                         module compliances.
> 
>                         Copyright (C) The Internet Society (2003).
>                         All Rights Reserved.
>                         This version of this module is part of
>                         RFC XXXX, see the RFC itself for full
>                         legal notices.";
> 
>        revision {
>            date        "2003-10-29";
>            description "Initial revision, published as RFC XXXX.";
>        };
> 
>        //
>        //
>        //
> 
>        extension snmp {
> 
>            status          current;
>            description
>               "The snmp statement maps SMIng definitions to SNMP
>                conformant definitions.";
>            abnf "
>    ;;
>    ;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF
>    ;;                    notation (RFC 2234).
>    ;;
>    ;; @(#) $Id: sming-snmp.abnf,v 1.14 2003/10/23 19:31:55 strauss Exp $
>    ;;
>    ;; Copyright (C) The Internet Society (2003). All Rights Reserved.
>    ;;
> 
>    ;;
>    ;; Statement rules.
>    ;;
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 28]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    snmpStatement           = snmpKeyword *1(sep lcIdentifier) optsep
>                                  \"{\" stmtsep
>                                  *1(oidStatement stmtsep)
>                                  *(nodeStatement stmtsep)
>                                  *(scalarsStatement stmtsep)
>                                  *(tableStatement stmtsep)
>                                  *(notificationStatement stmtsep)
>                                  *(groupStatement stmtsep)
>                                  *(complianceStatement stmtsep)
>                                  statusStatement stmtsep
>                                  descriptionStatement stmtsep
>                                  *1(referenceStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    nodeStatement           = nodeKeyword sep lcIdentifier optsep
>                                  \"{\" stmtsep
>                                  oidStatement stmtsep
>                                  *1(representsStatement stmtsep)
>                                  statusStatement stmtsep
>                                  *1(descriptionStatement stmtsep)
>                                  *1(referenceStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    representsStatement     = representsKeyword sep
>                                  qucIdentifier optsep \";\"
> 
>    scalarsStatement        = scalarsKeyword sep lcIdentifier optsep
>                                  \"{\" stmtsep
>                                  oidStatement stmtsep
>                                  1*(objectStatement stmtsep)
>                                  statusStatement stmtsep
>                                  descriptionStatement stmtsep
>                                  *1(referenceStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    tableStatement          = tableKeyword sep lcIdentifier optsep
>                                  \"{\" stmtsep
>                                  oidStatement stmtsep
>                                  anyIndexStatement stmtsep
>                                  *1(createStatement stmtsep)
>                                  1*(objectStatement stmtsep)
>                                  statusStatement stmtsep
>                                  descriptionStatement stmtsep
>                                  *1(referenceStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    objectStatement         = objectKeyword sep lcIdentifier optsep
>                                  \"{\" stmtsep
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 29]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                                  implementsStatement stmtsep
>                                  *1(subidStatement stmtsep)
>                                  *1(statusStatement stmtsep)
>                                  *1(descriptionStatement stmtsep)
>                                  *1(referenceStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    implementsStatement     = implementsKeyword sep qcattrIdentifier
>                                  optsep \";\"
> 
>    notificationStatement   = notificationKeyword sep lcIdentifier
>                                  optsep \"{\" stmtsep
>                                  oidStatement stmtsep
>                                  signalsStatement stmtsep
>                                  statusStatement stmtsep
>                                  descriptionStatement stmtsep
>                                  *1(referenceStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    signalsStatement        = signalsKeyword sep qattrIdentifier
>                                  optsep \"{\" stmtsep
>                                  *(signalsObjectStatement)
>                              \"}\" optsep \";\"
> 
>    signalsObjectStatement  = objectKeyword sep
>                                  qattrIdentifier optsep \";\"
> 
>    groupStatement          = groupKeyword sep lcIdentifier optsep
>                                  \"{\" stmtsep
>                                  oidStatement stmtsep
>                                  membersStatement stmtsep
>                                  statusStatement stmtsep
>                                  descriptionStatement stmtsep
>                                  *1(referenceStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    complianceStatement     = complianceKeyword sep lcIdentifier optsep
>                                  \"{\" stmtsep
>                                  oidStatement stmtsep
>                                  statusStatement stmtsep
>                                  descriptionStatement stmtsep
>                                  *1(referenceStatement stmtsep)
>                                  *1(mandatoryStatement stmtsep)
>                                  *(optionalStatement stmtsep)
>                                  *(refineStatement stmtsep)
>                              \"}\" optsep \";\"
> 
>    anyIndexStatement       = indexStatement /
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 30]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                              augmentsStatement /
>                              reordersStatement /
>                              extendsStatement /
>                              expandsStatement
> 
>    indexStatement          = indexKeyword *1(sep impliedKeyword) optsep
>                                  \"(\" optsep qlcIdentifierList
>                                  optsep \")\" optsep \";\"
> 
>    augmentsStatement       = augmentsKeyword sep qlcIdentifier
>                                  optsep \";\"
> 
>    reordersStatement       = reordersKeyword sep qlcIdentifier
>                                  *1(sep impliedKeyword)
>                                  optsep \"(\" optsep
>                                  qlcIdentifierList optsep \")\"
>                                  optsep \";\"
> 
>    extendsStatement        = extendsKeyword sep qlcIdentifier optsep \";\"
> 
>    expandsStatement        = expandsKeyword sep qlcIdentifier
>                                  *1(sep impliedKeyword)
>                                  optsep \"(\" optsep
>                                  qlcIdentifierList optsep \")\"
>                                  optsep \";\"
> 
>    createStatement         = createKeyword optsep \";\"
> 
>    membersStatement        = membersKeyword optsep \"(\" optsep
>                                  qlcIdentifierList optsep
>                                  \")\" optsep \";\"
> 
>    mandatoryStatement      = mandatoryKeyword optsep \"(\" optsep
>                                  qlcIdentifierList optsep
>                                  \")\" optsep \";\"
> 
>    optionalStatement       = optionalKeyword sep qlcIdentifier optsep
>                                  \"{\" descriptionStatement stmtsep
>                              \"}\" optsep \";\"
> 
>    refineStatement         = refineKeyword sep qlcIdentifier optsep \"{\"
>                                  *1(typeStatement stmtsep)
>                                  *1(writetypeStatement stmtsep)
>                                  *1(accessStatement stmtsep)
>                                  descriptionStatement stmtsep
>                              \"}\" optsep \";\"
> 
>    typeStatement           = typeKeyword sep
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 31]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                                  (refinedBaseType / refinedType)
>                                  optsep \";\"
> 
>    writetypeStatement      = writetypeKeyword sep
>                                  (refinedBaseType / refinedType)
>                                  optsep \";\"
> 
>    oidStatement            = oidKeyword sep objectIdentifier optsep \";\"
> 
>    subidStatement          = subidKeyword sep subid optsep \";\"
> 
>    ;;
>    ;; Statement keywords.
>    ;;
> 
>    snmpKeyword         =  %x73 %x6E %x6D %x70
>    nodeKeyword         =  %x6E %x6F %x64 %x65
>    representsKeyword   =  %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6E %x74
>                           %x73
>    scalarsKeyword      =  %x73 %x63 %x61 %x6C %x61 %x72 %x73
>    tableKeyword        =  %x74 %x61 %x62 %x6C %x65
>    implementsKeyword   =  %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74
>                           %x73
>    subidKeyword        =  %x73 %x75 %x62 %x69 %x64
>    objectKeyword       =  %x6F %x62 %x6A %x65 %x63 %x74
>    notificationKeyword =  %x6E %x6F %x74 %x69 %x66 %x69 %x63 %x61 %x74
>                           %x69 %x6F %x6E
>    signalsKeyword      =  %x73 %x69 %x67 %x6E %x61 %x6C %x73
>    oidKeyword          =  %x6F %x69 %x64
>    groupKeyword        =  %x67 %x72 %x6F %x75 %x70
>    complianceKeyword   =  %x63 %x6F %x6D %x70 %x6C %x69 %x61 %x6E %x63
>                           %x65
>    impliedKeyword      =  %x69 %x6D %x70 %x6C %x69 %x65 %x64
>    indexKeyword        =  %x69 %x6E %x64 %x65 %x78
>    augmentsKeyword     =  %x61 %x75 %x67 %x6D %x65 %x6E %x74 %x73
>    reordersKeyword     =  %x72 %x65 %x6F %x72 %x64 %x65 %x72 %x73
>    extendsKeyword      =  %x65 %x78 %x74 %x65 %x6E %x64 %x73
>    expandsKeyword      =  %x65 %x78 %x70 %x61 %x6E %x64 %x73
>    createKeyword       =  %x63 %x72 %x65 %x61 %x74 %x65
>    membersKeyword      =  %x6D %x65 %x6D %x62 %x65 %x72 %x73
>    mandatoryKeyword    =  %x6D %x61 %x6E %x64 %x61 %x74 %x6F %x72 %x79
>    optionalKeyword     =  %x6F %x70 %x74 %x69 %x6F %x6E %x61 %x6C
>    refineKeyword       =  %x72 %x65 %x66 %x69 %x6E %x65
>    writetypeKeyword    =  %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65
> 
>    ;; End of ABNF
>                  ";
>        };
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 32]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>        //
>        //
>        //
> 
>        snmp {
> 
>            node ccitt                       { oid 0;          };
> 
>            node   zeroDotZero {
>                oid         0.0;
>                description "A null value used for pointers.";
>            };
> 
>            node iso                         { oid 1;          };
>            node   org                       { oid iso.3;      };
>            node     dod                     { oid org.6;      };
>            node       internet              { oid dod.1;      };
>            node         directory           { oid internet.1; };
>            node         mgmt                { oid internet.2; };
>            node           mib-2             { oid mgmt.1;     };
>            node             transmission    { oid mib-2.10;   };
>            node         experimental        { oid internet.3; };
>            node         private             { oid internet.4; };
>            node           enterprises       { oid private.1;  };
>            node         security            { oid internet.5; };
>            node         snmpV2              { oid internet.6; };
>            node           snmpDomains       { oid snmpV2.1;   };
>            node           snmpProxys        { oid snmpV2.2;   };
>            node           snmpModules       { oid snmpV2.3;   };
> 
>            node joint-iso-ccitt             { oid 2;          };
> 
>            status          current;
>            description
>    	   "This set of nodes defines the core object
>                identifier hierarchy";
>            reference
>    	   "RFC 2578, Section 2.";
> 
>        };
> 
>    };
> 
> 
> 
> 6. NMRG-SMING-SNMP
> 
>    The module NMRG-SMING-SNMP specified below defines derived types that
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 33]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    are specific to the SNMP mapping.
> 
>    module NMRG-SMING-SNMP {
> 
>        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: [phone]
>                         EMail: [e-mail]
> 
>                         Juergen Schoenwaelder
>                         International University Bremen
>                         P.O. Box 750 561
>                         28725 Bremen
>                         Germany
>                         Phone: [phone]
>                         EMail: [e-mail]";
> 
>        description     "Core type definitions for the SMIng SNMP mapping.
>                         These definitions are based on RFC 2579 definitions
>                         that are specific to the SNMP protocol and its
>                         naming system.
> 
>                         Copyright (C) The Internet Society (2003).
>                         All Rights Reserved.
>                         This version of this module is part of
>                         RFC XXXX, see the RFC itself for full
>                         legal notices.";
> 
>        revision {
>            date        "2003-10-29";
>            description "Initial version, published as RFC XXXX.";
>        };
> 
>        typedef TestAndIncr {
>            type        Integer32 (0..2147483647);
>            description
>                "Represents integer-valued information used for atomic
>                 operations.  When the management protocol is used to
>                 specify that an object instance having this type is to
>                 be modified, the new value supplied via the management
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 34]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                 protocol must precisely match the value presently held by
>                 the instance.  If not, the management protocol set
>                 operation fails with an error of `inconsistentValue'.
>                 Otherwise, if the current value is the maximum value of
>                 2^31-1 (2147483647 decimal), then the value held by the
>                 instance is wrapped to zero; otherwise, the value held by
>                 the instance is incremented by one.  (Note that
>                 regardless of whether the management protocol set
>                 operation succeeds, the variable-binding in the request
>                 and response PDUs are identical.)
> 
>                 The value of the SNMP access clause for objects having
>                 this type has to be `readwrite'.  When an instance of a
>                 columnar object having this type is created, any value
>                 may be supplied via the management protocol.
> 
>                 When the network management portion of the system is re-
>                 initialized, the value of every object instance having
>                 this type must either be incremented from its value prior
>                 to the re-initialization, or (if the value prior to the
>                 re-initialization is unknown) be set to a
>                 pseudo-randomly generated value."; };
> 
>        typedef AutonomousType {
>            type        Pointer;
>            description
>                "Represents an independently extensible type
>                 identification value.  It may, for example, indicate a
>                 particular OID sub-tree with further MIB definitions, or
>                 define a particular type of protocol or hardware.";
>        };
> 
>        typedef VariablePointer {
>            type        Pointer;
>            description
>                "A pointer to a specific object instance.  For example,
>                 sysContact.0 or ifInOctets.3.";
>        };
> 
>        typedef RowPointer {
>            type        Pointer;
>            description
>                "Represents a pointer to a conceptual row.  The value is
>                 the name of the instance of the first accessible columnar
>                 object in the conceptual row.
> 
>                 For example, ifIndex.3 would point to the 3rd row in the
>                 ifTable (note that if ifIndex were not-accessible, then
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 35]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                 ifDescr.3 would be used instead).";
>        };
> 
>        typedef RowStatus {
>            type        Enumeration (active(1), notInService(2),
>                            notReady(3), createAndGo(4),
>                            createAndWait(5), destroy(6));
>            description
>            "The RowStatus type is used to manage the creation and
>             deletion of conceptual rows, and is used as the type for the
>             row status column of a conceptual row (as described in
>             Section 7.7.1 of [2].)
> 
>             The status column has six defined values:
> 
>                 - `active', which indicates that the conceptual row is
>                 available for use by the managed device;
> 
>                 - `notInService', which indicates that the conceptual
>                 row exists in the agent, but is unavailable for use by
>                 the managed device (see NOTE below);
> 
>                 - `notReady', which indicates that the conceptual row
>                 exists in the agent, but is missing information
>                 necessary in order to be available for use by the
>                 managed device;
> 
>                 - `createAndGo', which is supplied by a management
>                 station wishing to create a new instance of a
>                 conceptual row and to have its status automatically set
>                 to active, making it available for use by the managed
>                 device;
> 
>                 - `createAndWait', which is supplied by a management
>                 station wishing to create a new instance of a
>                 conceptual row (but not make it available for use by
>                 the managed device); and,
> 
>                 - `destroy', which is supplied by a management station
>                 wishing to delete all of the instances associated with
>                 an existing conceptual row.
> 
>             Whereas five of the six values (all except `notReady') may
>             be specified in a management protocol set operation, only
>             three values will be returned in response to a management
>             protocol retrieval operation: `notReady', `notInService' or
>             `active'.  That is, when queried, an existing conceptual row
>             has only three states: it is either available for use by the
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 36]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>             managed device (the status column has value `active'); it is
>             not available for use by the managed device, though the
> 
> 
>             agent has sufficient information to make it so (the status
>             column has value `notInService'); or, it is not available
>             for use by the managed device, and an attempt to make it so
>             would fail because the agent has insufficient information
>             (the state column has value `notReady').
> 
>                                     NOTE WELL
> 
>                 This textual convention may be used for a MIB table,
>                 irrespective of whether the values of that table's
>                 conceptual rows are able to be modified while it is
>                 active, or whether its conceptual rows must be taken
>                 out of service in order to be modified.  That is, it is
>                 the responsibility of the DESCRIPTION clause of the
>                 status column to specify whether the status column must
>                 not be `active' in order for the value of some other
>                 column of the same conceptual row to be modified.  If
>                 such a specification is made, affected columns may be
>                 changed by an SNMP set PDU if the RowStatus would not
>                 be equal to `active' either immediately before or after
>                 processing the PDU.  In other words, if the PDU also
>                 contained a varbind that would change the RowStatus
>                 value, the column in question may be changed if the
>                 RowStatus was not equal to `active' as the PDU was
>                 received, or if the varbind sets the status to a value
>                 other than 'active'.
> 
>             Also note that whenever any elements of a row exist, the
>             RowStatus column must also exist.
> 
> 
>             To summarize the effect of having a conceptual row with a
>             column having a type of RowStatus, consider the following
>             state diagram:
> 
>                                             STATE
>                  +--------------+-----------+-------------+-------------
>                  |      A       |     B     |      C      |      D
>                  |              |status col.|status column|
>                  |status column |    is     |      is     |status column
>        ACTION    |does not exist|  notReady | notInService|  is active
>    --------------+--------------+-----------+-------------+-------------
>    set status    |noError    ->D|inconsist- |inconsistent-|inconsistent-
>    column to     |       or     |   entValue|        Value|        Value
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 37]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    createAndGo   |inconsistent- |           |             |
>                  |         Value|           |             |
>    --------------+--------------+-----------+-------------+-------------
>    set status    |noError  see 1|inconsist- |inconsistent-|inconsistent-
>    column to     |       or     |   entValue|        Value|        Value
>    createAndWait |wrongValue    |           |             |
>    --------------+--------------+-----------+-------------+-------------
>    set status    |inconsistent- |inconsist- |noError      |noError
>    column to     |         Value|   entValue|             |
>    active        |              |           |             |
>                  |              |     or    |             |
>                  |              |           |             |
>                  |              |see 2   ->D|see 8     ->D|          ->D
>    --------------+--------------+-----------+-------------+-------------
>    set status    |inconsistent- |inconsist- |noError      |noError   ->C
>    column to     |         Value|   entValue|             |
>    notInService  |              |           |             |
>                  |              |     or    |             |      or
>                  |              |           |             |
>                  |              |see 3   ->C|          ->C|see 6
>    --------------+--------------+-----------+-------------+-------------
>    set status    |noError       |noError    |noError      |noError   ->A
>    column to     |              |           |             |      or
>    destroy       |           ->A|        ->A|          ->A|see 7
>    --------------+--------------+-----------+-------------+-------------
>    set any other |see 4         |noError    |noError      |see 5
>    column to some|              |           |             |
>    value         |              |      see 1|          ->C|          ->D
>    --------------+--------------+-----------+-------------+-------------
> 
>             (1) goto B or C, depending on information available to the
> 
> 
>             agent.
> 
>             (2) if other variable bindings included in the same PDU,
>             provide values for all columns which are missing but
>             required, then return noError and goto D.
> 
>             (3) if other variable bindings included in the same PDU,
>             provide values for all columns which are missing but
>             required, then return noError and goto C.
> 
>             (4) at the discretion of the agent, the return value may be
>             either:
> 
>                 inconsistentName: because the agent does not choose to
>                 create such an instance when the corresponding
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 38]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                 RowStatus instance does not exist, or
> 
>                 inconsistentValue: if the supplied value is
>                 inconsistent with the state of some other MIB object's
>                 value, or
> 
>                 noError: because the agent chooses to create the
>                 instance.
> 
>             If noError is returned, then the instance of the status
>             column must also be created, and the new state is B or C,
>             depending on the information available to the agent.  If
>             inconsistentName or inconsistentValue is returned, the row
>             remains in state A.
> 
>             (5) depending on the MIB definition for the column/table,
>             either noError or inconsistentValue may be returned.
> 
>             (6) the return value can indicate one of the following
>             errors:
> 
>                 wrongValue: because the agent does not support
>                 createAndWait, or
> 
>                 inconsistentValue: because the agent is unable to take
>                 the row out of service at this time, perhaps because it
>                 is in use and cannot be de-activated.
> 
>             (7) the return value can indicate the following error:
> 
> 
>                 inconsistentValue: because the agent is unable to
>                 remove the row at this time, perhaps because it is in
>                 use and cannot be de-activated.
> 
>             NOTE: Other processing of the set request may result in a
>             response other than noError being returned, e.g.,
>             wrongValue, noCreation, etc.
> 
>                              Conceptual Row Creation
> 
>             There are four potential interactions when creating a
>             conceptual row: selecting an instance-identifier which is
>             not in use; creating the conceptual row; initializing any
>             objects for which the agent does not supply a default; and,
>             making the conceptual row available for use by the managed
>             device.
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 39]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>             Interaction 1: Selecting an Instance-Identifier
> 
>             The algorithm used to select an instance-identifier varies
>             for each conceptual row.  In some cases, the instance-
>             identifier is semantically significant, e.g., the
>             destination address of a route, and a management station
>             selects the instance-identifier according to the semantics.
> 
>             In other cases, the instance-identifier is used solely to
>             distinguish conceptual rows, and a management station
>             without specific knowledge of the conceptual row might
>             examine the instances present in order to determine an
>             unused instance-identifier.  (This approach may be used, but
>             it is often highly sub-optimal; however, it is also a
>             questionable practice for a naive management station to
>             attempt conceptual row creation.)
> 
>             Alternately, the MIB module which defines the conceptual row
>             might provide one or more objects which provide assistance
>             in determining an unused instance-identifier.  For example,
>             if the conceptual row is indexed by an integer-value, then
>             an object having an integer-valued SYNTAX clause might be
>             defined for such a purpose, allowing a management station to
>             issue a management protocol retrieval operation.  In order
>             to avoid unnecessary collisions between competing management
>             stations, `adjacent' retrievals of this object should be
>             different.
> 
> 
>             Finally, the management station could select a pseudo-random
>             number to use as the index.  In the event that this index
>             was already in use and an inconsistentValue was returned in
>             response to the management protocol set operation, the
>             management station should simply select a new pseudo-random
>             number and retry the operation.
> 
>             A MIB designer should choose between the two latter
>             algorithms based on the size of the table (and therefore the
>             efficiency of each algorithm).  For tables in which a large
>             number of entries are expected, it is recommended that a MIB
>             object be defined that returns an acceptable index for
>             creation.  For tables with small numbers of entries, it is
>             recommended that the latter pseudo-random index mechanism be
>             used.
> 
>             Interaction 2: Creating the Conceptual Row
> 
>             Once an unused instance-identifier has been selected, the
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 40]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>             management station determines if it wishes to create and
>             activate the conceptual row in one transaction or in a
>             negotiated set of interactions.
> 
>             Interaction 2a: Creating and Activating the Conceptual Row
> 
>             The management station must first determine the column
>             requirements, i.e., it must determine those columns for
>             which it must or must not provide values.  Depending on the
>             complexity of the table and the management station's
>             knowledge of the agent's capabilities, this determination
>             can be made locally by the management station.  Alternately,
>             the management station issues a management protocol get
>             operation to examine all columns in the conceptual row that
>             it wishes to create.  In response, for each column, there
>             are three possible outcomes:
> 
>                 - a value is returned, indicating that some other
>                 management station has already created this conceptual
>                 row.  We return to interaction 1.
> 
> 
>                 - the exception `noSuchInstance' is returned,
>                 indicating that the agent implements the object-type
>                 associated with this column, and that this column in at
>                 least one conceptual row would be accessible in the MIB
>                 view used by the retrieval were it to exist. For those
>                 columns to which the agent provides read-create access,
>                 the `noSuchInstance' exception tells the management
>                 station that it should supply a value for this column
>                 when the conceptual row is to be created.
> 
>                 - the exception `noSuchObject' is returned, indicating
>                 that the agent does not implement the object-type
>                 associated with this column or that there is no
>                 conceptual row for which this column would be
>                 accessible in the MIB view used by the retrieval.  As
>                 such, the management station can not issue any
>                 management protocol set operations to create an
>                 instance of this column.
> 
>             Once the column requirements have been determined, a
>             management protocol set operation is accordingly issued.
>             This operation also sets the new instance of the status
>             column to `createAndGo'.
> 
>             When the agent processes the set operation, it verifies that
>             it has sufficient information to make the conceptual row
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 41]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>             available for use by the managed device.  The information
>             available to the agent is provided by two sources: the
>             management protocol set operation which creates the
>             conceptual row, and, implementation-specific defaults
>             supplied by the agent (note that an agent must provide
>             implementation-specific defaults for at least those objects
>             which it implements as read-only).  If there is sufficient
>             information available, then the conceptual row is created, a
>             `noError' response is returned, the status column is set to
>             `active', and no further interactions are necessary (i.e.,
>             interactions 3 and 4 are skipped).  If there is insufficient
>             information, then the conceptual row is not created, and the
>             set operation fails with an error of `inconsistentValue'.
>             On this error, the management station can issue a management
>             protocol retrieval operation to determine if this was
>             because it failed to specify a value for a required column,
>             or, because the selected instance of the status column
>             already existed.  In the latter case, we return to
>             interaction 1.  In the former case, the management station
> 
> 
>             can re-issue the set operation with the additional
>             information, or begin interaction 2 again using
>             `createAndWait' in order to negotiate creation of the
>             conceptual row.
> 
>                                     NOTE WELL
> 
>                 Regardless of the method used to determine the column
>                 requirements, it is possible that the management
>                 station might deem a column necessary when, in fact,
>                 the agent will not allow that particular columnar
>                 instance to be created or written.  In this case, the
>                 management protocol set operation will fail with an
>                 error such as `noCreation' or `notWritable'.  In this
>                 case, the management station decides whether it needs
>                 to be able to set a value for that particular columnar
>                 instance.  If not, the management station re-issues the
>                 management protocol set operation, but without setting
>                 a value for that particular columnar instance;
>                 otherwise, the management station aborts the row
>                 creation algorithm.
> 
> 
>             Interaction 2b: Negotiating the Creation of the Conceptual
>             Row
> 
>             The management station issues a management protocol set
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 42]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>             operation which sets the desired instance of the status
>             column to `createAndWait'.  If the agent is unwilling to
>             process a request of this sort, the set operation fails with
>             an error of `wrongValue'.  (As a consequence, such an agent
>             must be prepared to accept a single management protocol set
>             operation, i.e., interaction 2a above, containing all of the
>             columns indicated by its column requirements.) Otherwise,
>             the conceptual row is created, a `noError' response is
>             returned, and the status column is immediately set to either
>             `notInService' or `notReady', depending on whether it has
>             sufficient information to make the conceptual row available
>             for use by the managed device.  If there is sufficient
>             information available, then the status column is set to
>             `notInService'; otherwise, if there is insufficient
>             information, then the status column is set to `notReady'.
>             Regardless, we proceed to interaction 3.
> 
>             Interaction 3: Initializing non-defaulted Objects
> 
>             The management station must now determine the column
>             requirements.  It issues a management protocol get operation
>             to examine all columns in the created conceptual row.  In
>             the response, for each column, there are three possible
>             outcomes:
> 
>                 - a value is returned, indicating that the agent
>                 implements the object-type associated with this column
>                 and had sufficient information to provide a value.  For
>                 those columns to which the agent provides read-create
>                 access (and for which the agent allows their values to
>                 be changed after their creation), a value return tells
>                 the management station that it may issue additional
>                 management protocol set operations, if it desires, in
>                 order to change the value associated with this column.
> 
> 
>                 - the exception `noSuchInstance' is returned,
>                 indicating that the agent implements the object-type
>                 associated with this column, and that this column in at
>                 least one conceptual row would be accessible in the MIB
>                 view used by the retrieval were it to exist. However,
>                 the agent does not have sufficient information to
>                 provide a value, and until a value is provided, the
>                 conceptual row may not be made available for use by the
>                 managed device.  For those columns to which the agent
>                 provides read-create access, the `noSuchInstance'
>                 exception tells the management station that it must
>                 issue additional management protocol set operations, in
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 43]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                 order to provide a value associated with this column.
> 
>                 - the exception `noSuchObject' is returned, indicating
>                 that the agent does not implement the object-type
>                 associated with this column or that there is no
>                 conceptual row for which this column would be
>                 accessible in the MIB view used by the retrieval.  As
>                 such, the management station can not issue any
>                 management protocol set operations to create an
>                 instance of this column.
> 
>             If the value associated with the status column is
>             `notReady', then the management station must first deal with
>             all `noSuchInstance' columns, if any.  Having done so, the
>             value of the status column becomes `notInService', and we
>             proceed to interaction 4.
> 
>             Interaction 4: Making the Conceptual Row Available
> 
>             Once the management station is satisfied with the values
>             associated with the columns of the conceptual row, it issues
>             a management protocol set operation to set the status column
>             to `active'.  If the agent has sufficient information to
>             make the conceptual row available for use by the managed
>             device, the management protocol set operation succeeds (a
>             `noError' response is returned).  Otherwise, the management
>             protocol set operation fails with an error of
>             `inconsistentValue'.
> 
> 
>                                     NOTE WELL
> 
>                 A conceptual row having a status column with value
>                 `notInService' or `notReady' is unavailable to the
>                 managed device.  As such, it is possible for the
>                 managed device to create its own instances during the
>                 time between the management protocol set operation
>                 which sets the status column to `createAndWait' and the
>                 management protocol set operation which sets the status
>                 column to `active'.  In this case, when the management
>                 protocol set operation is issued to set the status
>                 column to `active', the values held in the agent
>                 supersede those used by the managed device.
> 
>             If the management station is prevented from setting the
>             status column to `active' (e.g., due to management station or
>             network failure) the conceptual row will be left in the
>             `notInService' or `notReady' state, consuming resources
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 44]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>             indefinitely.  The agent must detect conceptual rows that
>             have been in either state for an abnormally long period of
>             time and remove them.  It is the responsibility of the
>             DESCRIPTION clause of the status column to indicate what an
>             abnormally long period of time would be.  This period of time
>             should be long enough to allow for human response time
>             (including `think time') between the creation of the
>             conceptual row and the setting of the status to `active'.  In
>             the absence of such information in the DESCRIPTION clause, it
>             is suggested that this period be approximately 5 minutes in
>             length.  This removal action applies not only to newly-
>             created rows, but also to previously active rows which are
>             set to, and left in, the notInService state for a prolonged
>             period exceeding that which is considered normal for such a
>             conceptual row.
> 
> 
>                             Conceptual Row Suspension
> 
>             When a conceptual row is `active', the management station
>             may issue a management protocol set operation which sets the
>             instance of the status column to `notInService'.  If the
>             agent is unwilling to do so, the set operation fails with an
>             error of `wrongValue' or `inconsistentValue'.
>             Otherwise, the conceptual row is taken out of service, and a
>             `noError' response is returned.  It is the responsibility of
>             the DESCRIPTION clause of the status column to indicate
>             under what circumstances the status column should be taken
>             out of service (e.g., in order for the value of some other
>             column of the same conceptual row to be modified).
> 
>                              Conceptual Row Deletion
> 
>             For deletion of conceptual rows, a management protocol set
>             operation is issued which sets the instance of the status
>             column to `destroy'.  This request may be made regardless of
>             the current value of the status column (e.g., it is possible
>             to delete conceptual rows which are either `notReady',
>             `notInService' or `active'.) If the operation succeeds, then
>             all instances associated with the conceptual row are
>             immediately removed.";
>        };
> 
>        typedef StorageType {
>            type        Enumeration (other(1), volatile(2),
>                            nonVolatile(3), permanent(4),
>                            readOnly(5));
>            description
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 45]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                "Describes the memory realization of a conceptual row.  A
>                 row which is volatile(2) is lost upon reboot.  A row
>                 which is either nonVolatile(3), permanent(4) or
>                 readOnly(5), is backed up by stable storage.  A row which
>                 is permanent(4) can be changed but not deleted.  A row
>                 which is readOnly(5) cannot be changed nor deleted.
> 
>                 If the value of an object with this syntax is either
>                 permanent(4) or readOnly(5), it cannot be modified.
>                 Conversely, if the value is either other(1), volatile(2)
>                 or nonVolatile(3), it cannot be modified to be
>                 permanent(4) or readOnly(5).  (All illegal modifications
>                 result in a 'wrongValue' error.)
> 
>                 Every usage of this textual convention is required to
>                 specify the columnar objects which a permanent(4) row
>                 must at a minimum allow to be writable.";
>        };
> 
>        typedef TDomain {
>            type        Pointer;
>            description
>                "Denotes a kind of transport service.
> 
>                 Some possible values, such as snmpUDPDomain, are defined
>                 in the SNMPv2-TM MIB module.  Other possible values are
>                 defined in other MIB modules."
>            reference
>                "The SNMPv2-TM MIB module is defined in RFC 3417."
>        };
> 
>        typedef TAddressOrZero {
>            type        OctetString (0..255);
>            description
>                "Denotes a transport service address.
> 
>                 A TAddress value is always interpreted within the context
>                 of a TDomain value.  Thus, each definition of a TDomain
>                 value must be accompanied by a definition of a textual
>                 convention for use with that TDomain.  Some possible
>                 textual conventions, such as SnmpUDPAddress for
>                 snmpUDPDomain, are defined in the SNMPv2-TM MIB module.
>                 Other possible textual conventions are defined in other
>                 MIB modules.
> 
>                 A zero-length TAddress value denotes an unknown transport
>                 service address."
>            reference
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 46]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>                "The SNMPv2-TM MIB module is defined in RFC 3417."
>        };
> 
>        typedef TAddress {
>            type        TAddressOrZero (1..255);
>            description
>                "Denotes a transport service address.
> 
>                 This type does not allow a zero-length TAddress value."
>        };
> 
>    };
> 
> 
> 
> 7. Security Considerations
> 
>    This document presents an extension of the SMIng data definition
>    language which supports the mapping of SMIng data definitions so that
>    they can be used with the SNMP management framework.  The language
>    extension and the mapping itself has no security impact on the
>    Internet.
> 
> 8. 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.
> 
>    Furthmore, several discussions within the SMING Working Group
>    reflected experience with SMIv2 and influenced this specification at
>    some points.
> 
> Normative References
> 
>    [RFCxxx1]  Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
>               Structure of Management Information",
>               draft-irtf-nmrg-sming-06.txt, October 2003.
> 
>    [RFCxxx2]  Strauss, F. and J. Schoenwaelder, "SMIng Core Modules",
>               draft-irtf-nmrg-sming-modules-04.txt, October 2003.
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 47]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", RFC 2119, BCP 14, March 1997.
> 
>    [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
>               Specifications: ABNF", RFC 2234, November 1997.
> 
> Informative References
> 
>    [RFC3410]  Case, J., Mundy, R., Partain, D. and B. Stewart,
>               "Introduction to Version 3 of the  Internet-standard
>               Network Management Framework", RFC 3410, December 2002.
> 
>    [RFC3411]  Harrington, D., Presuhn, R. and B. Wijnen, "An
>               Architecture for Describing Simple Network Management
>               Protocol (SNMP) Management Frameworks", RFC 3411, STD 62,
>               December 2002.
> 
>    [RFC2578]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Structure of Management
>               Information Version 2 (SMIv2)", RFC 2578, STD 58, April
>               1999.
> 
>    [RFC2579]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Textual Conventions for
>               SMIv2", RFC 2579, STD 59, April 1999.
> 
>    [RFC2580]  McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
>               Rose, M. and S. Waldbusser, "Conformance Statements for
>               SMIv2", RFC 2580, STD 60, April 1999.
> 
>    [RFC1155]  Rose, M. and K. McCloghrie, "Structure and Identification
>               of Management Information for TCP/IP-based Internets", RFC
>               1155, STD 16, May 1990.
> 
>    [RFC1212]  Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC
>               1212, STD 16, March 1991.
> 
>    [RFC1215]  Rose, M., "A Convention for Defining Traps for use with
>               the SNMP", RFC 1215, March 1991.
> 
>    [ASN1]     International Organization for Standardization,
>               "Specification of Abstract Syntax Notation One (ASN.1)",
>               International Standard 8824, December 1987.
> 
>    [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.
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 48]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    [IEEE754]  Institute of Electrical and Electronics Engineers, "IEEE
>               Standard for Binary Floating-Point Arithmetic", ANSI/IEEE
>               Standard 754-1985, August 1985.
> 
>    [RFC3418]  Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
>               Waldbusser, "Management Information Base (MIB) for the
>               Simple Network Management Protocol (SNMP)", RFC 3418, STD
>               62, December 2002.
> 
>    [RFC3416]  Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
>               Waldbusser, "Version 2 of the Protocol Operations for the
>               Simple  Network Management Protocol (SNMP)", RFC 3416, STD
>               62, December 2002.
> 
> 
> Authors' Addresses
> 
>    Frank Strauss
>    TU Braunschweig
>    Muehlenpfordtstrasse 23
>    38106 Braunschweig
>    Germany
> 
>    Phone: [phone]
>    EMail: [e-mail]
>    URI:   http://www.ibr.cs.tu-bs.de/
> 
> 
>    Juergen Schoenwaelder
>    International University Bremen
>    P.O. Box 750 561
>    28725 Bremen
>    Germany
> 
>    Phone: [phone]
>    EMail: [e-mail]
>    URI:   http://www.eecs.iu-bremen.de/
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 49]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
> Intellectual Property Statement
> 
>    The IETF takes no position regarding the validity or scope of any
>    intellectual property or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; neither does it represent that it
>    has made any effort to identify any such rights.  Information on the
>    IETF's procedures with respect to rights in standards-track and
>    standards-related documentation can be found in BCP-11.  Copies of
>    claims of rights made available for publication 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 implementors or users of this specification can
>    be obtained from the IETF Secretariat.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights which may cover technology that may be required to practice
>    this standard.  Please address the information to the IETF Executive
>    Director.
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assignees.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 50]
> 
> Internet-Draft             SMIng SNMP Mapping               October 2003
> 
> 
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Acknowledgement
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Strauss & Schoenwaelder    Expires April 28, 2004              [Page 51]
>