tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 3780

Experimental
Pages: 64
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

SMIng - Next Generation Structure of Management Information

Part 1 of 3, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                         F. Strauss
Request for Comments: 3780                               TU Braunschweig
Category: Experimental                                  J. Schoenwaelder
                                         International University Bremen
                                                                May 2004


      SMIng - Next Generation Structure of Management Information

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This memo defines the base SMIng (Structure of Management
   Information, Next Generation) language.  SMIng is a data definition
   language that provides a protocol-independent representation for
   management information.  Separate RFCs define mappings of SMIng to
   specific management protocols, including SNMP.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  The History of SMIng . . . . . . . . . . . . . . . . . .  4
       1.2.  Terms of Requirement Levels. . . . . . . . . . . . . . .  5
   2.  SMIng Data Modeling. . . . . . . . . . . . . . . . . . . . . .  5
       2.1.  Identifiers. . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Base Types and Derived Types . . . . . . . . . . . . . . . . .  7
       3.1.  OctetString. . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.  Pointer. . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.  ObjectIdentifier . . . . . . . . . . . . . . . . . . . .  9
       3.4.  Integer32. . . . . . . . . . . . . . . . . . . . . . . . 10
       3.5.  Integer64. . . . . . . . . . . . . . . . . . . . . . . . 11
       3.6.  Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . 12
       3.7.  Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . 13
       3.8.  Float32. . . . . . . . . . . . . . . . . . . . . . . . . 13
       3.9.  Float64. . . . . . . . . . . . . . . . . . . . . . . . . 14
       3.10. Float128 . . . . . . . . . . . . . . . . . . . . . . . . 15
       3.11. Enumeration. . . . . . . . . . . . . . . . . . . . . . . 17
       3.12. Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Top      ToC       Page 2 
       3.13. Display Formats. . . . . . . . . . . . . . . . . . . . . 18
   4.  The SMIng File Structure . . . . . . . . . . . . . . . . . . . 20
       4.1.  Comments . . . . . . . . . . . . . . . . . . . . . . . . 20
       4.2.  Textual Data . . . . . . . . . . . . . . . . . . . . . . 21
       4.3.  Statements and Arguments . . . . . . . . . . . . . . . . 21
   5.  The module Statement . . . . . . . . . . . . . . . . . . . . . 21
       5.1.  The module's import Statement. . . . . . . . . . . . . . 22
       5.2.  The module's organization Statement. . . . . . . . . . . 23
       5.3.  The module's contact Statement . . . . . . . . . . . . . 23
       5.4.  The module's description Statement . . . . . . . . . . . 23
       5.5.  The module's reference Statement . . . . . . . . . . . . 23
       5.6.  The module's revision Statement. . . . . . . . . . . . . 23
             5.6.1. The revision's date Statement . . . . . . . . . . 24
             5.6.2. The revision's description Statement. . . . . . . 24
       5.7.  Usage Example. . . . . . . . . . . . . . . . . . . . . . 24
   6.  The extension Statement. . . . . . . . . . . . . . . . . . . . 25
       6.1.  The extension's status Statement . . . . . . . . . . . . 25
       6.2.  The extension's description Statement. . . . . . . . . . 26
       6.3.  The extension's reference Statement. . . . . . . . . . . 26
       6.4.  The extension's abnf Statement . . . . . . . . . . . . . 26
       6.5.  Usage Example. . . . . . . . . . . . . . . . . . . . . . 26
   7.  The typedef Statement. . . . . . . . . . . . . . . . . . . . . 27
       7.1.  The typedef's type Statement . . . . . . . . . . . . . . 27
       7.2.  The typedef's default Statement. . . . . . . . . . . . . 27
       7.3.  The typedef's format Statement . . . . . . . . . . . . . 27
       7.4.  The typedef's units Statement. . . . . . . . . . . . . . 28
       7.5.  The typedef's status Statement . . . . . . . . . . . . . 28
       7.6.  The typedef's description Statement. . . . . . . . . . . 29
       7.7.  The typedef's reference Statement. . . . . . . . . . . . 29
       7.8.  Usage Examples . . . . . . . . . . . . . . . . . . . . . 29
   8.  The identity Statement . . . . . . . . . . . . . . . . . . . . 30
       8.1.  The identity's parent Statement. . . . . . . . . . . . . 30
       8.2.  The identity's status Statement. . . . . . . . . . . . . 30
       8.3.  The identity' description Statement. . . . . . . . . . . 31
       8.4.  The identity's reference Statement . . . . . . . . . . . 31
       8.5.  Usage Examples . . . . . . . . . . . . . . . . . . . . . 31
   9.  The class Statement. . . . . . . . . . . . . . . . . . . . . . 32
       9.1.  The class' extends Statement . . . . . . . . . . . . . . 32
       9.2.  The class' attribute Statement . . . . . . . . . . . . . 32
             9.2.1. The attribute's type Statement. . . . . . . . . . 32
             9.2.2. The attribute's access Statement. . . . . . . . . 32
             9.2.3. The attribute's default Statement . . . . . . . . 33
             9.2.4. The attribute's format Statement. . . . . . . . . 33
             9.2.5. The attribute's units Statement . . . . . . . . . 33
             9.2.6. The attribute's status Statement. . . . . . . . . 34
             9.2.7. The attribute's description Statement . . . . . . 34
             9.2.8. The attribute's reference Statement . . . . . . . 34
       9.3.  The class' unique Statement. . . . . . . . . . . . . . . 35

Top      ToC       Page 3 
       9.4.  The class' event Statement . . . . . . . . . . . . . . . 35
             9.4.1. The event's status Statement. . . . . . . . . . . 35
             9.4.2. The event's description Statement . . . . . . . . 35
             9.4.3. The event's reference Statement . . . . . . . . . 36
       9.5.  The class' status Statement. . . . . . . . . . . . . . . 36
       9.6.  The class' description Statement . . . . . . . . . . . . 36
       9.7.  The class' reference Statement . . . . . . . . . . . . . 37
       9.8.  Usage Example. . . . . . . . . . . . . . . . . . . . . . 37
   10. Extending a Module . . . . . . . . . . . . . . . . . . . . . . 38
   11. SMIng Language Extensibility . . . . . . . . . . . . . . . . . 39
   12. Security Considerations. . . . . . . . . . . . . . . . . . . . 41
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
       14.1. Normative References . . . . . . . . . . . . . . . . . . 42
       14.2. Informative References . . . . . . . . . . . . . . . . . 42
   Appendix A.  NMRG-SMING Module . . . . . . . . . . . . . . . . . . 44
   Appendix B.  SMIng ABNF Grammar. . . . . . . . . . . . . . . . . . 53
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 64

1.  Introduction

   In traditional management systems, management information is viewed
   as a collection of managed objects, residing in a virtual information
   store, termed the Management Information Base (MIB).  Collections of
   related objects are defined in MIB modules.  These modules are
   written in conformance with a specification language, the Structure
   of Management Information (SMI).  There are different versions of the
   SMI.  The SMI version 1 (SMIv1) is defined in [RFC1155], [RFC1212],
   [RFC1215], and the SMI version 2 (SMIv2) in [RFC2578], [RFC2579], and
   [RFC2580].  Both are based on adapted subsets of OSI's Abstract
   Syntax Notation One, ASN.1 [ASN1].

   In a similar fashion, policy provisioning information is viewed as a
   collection of Provisioning Classes (PRCs) and Provisioning Instances
   (PRIs) residing in a virtual information store, termed the Policy
   Information Base (PIB).  Collections of related Provisioning Classes
   are defined in PIB modules.  PIB modules are written using the
   Structure of Policy Provisioning Information (SPPI) [RFC3159] which
   is an adapted subset of SMIv2.

   The SMIv1 and the SMIv2 are bound to the Simple Network Management
   Protocol (SNMP) [RFC3411], while the SPPI is bound to the Common Open
   Policy Service Provisioning (COPS-PR) Protocol [RFC3084].  Even
   though the languages have common rules, it is hard to use common data
   definitions with both protocols.  It is the purpose of this document
   to define a common data definition language, named SMIng, that can

Top      ToC       Page 4 
   formally specify data models independent of specific protocols and
   applications.  The appendix of this document defines a core module
   that supplies common SMIng definitions.

   A companion document contains an SMIng language extension to define
   SNMP specific mappings of SMIng definitions in compatibility with
   SMIv2 MIB modules [RFC3781].  Additional language extensions may be
   added in the future, e.g., to define COPS-PR specific mappings of
   SMIng definitions in a way that is compatible with SPPI PIBs.

   Section 2 gives an overview of the basic concepts of data modeling
   using SMIng, while the subsequent sections present the concepts of
   the SMIng language in detail: the base types, the SMIng file
   structure, and all SMIng core statements.

   The remainder of the document describes extensibility features of the
   language and rules to follow when changes are applied to a module.
   Appendix B contains the grammar of SMIng in ABNF [RFC2234] notation.

1.1.  The History of SMIng

   SMIng started in 1999 as a research project to address some drawbacks
   of SMIv2, the current data modeling language for management
   information bases.  Primarily, its partial dependence on ASN.1 and a
   number of exception rules turned out to be problematic.  In 2000, the
   work was handed over to the IRTF Network Management Research Group
   where it was significantly detailed.  Since the work of the RAP
   Working Group on COPS-PR and SPPI emerged in 1999/2000, SMIng was
   split into two parts: a core data definition language (defined in
   this document) and protocol mappings to allow the application of core
   definitions through (potentially) multiple management protocols.  The
   replacement of SMIv2 and SPPI by a single merged data definition
   language was also a primary goal of the IETF SMING Working Group that
   was chartered at the end of 2000.

   The requirements for a new data definition language were discussed
   several times within the IETF SMING Working Group and changed
   significantly over time [RFC3216], so that another proposal (in
   addition to SMIng), named SMI Data Structures (SMI-DS), was presented
   to the Working Group.  In the end, neither of the two proposals found
   enough consensus and support, and the attempt to merge the existing
   concepts did not succeed, resulting in the Working Group being closed
   down in April 2003.

   In order to record the work of the NMRG (Network Management Research
   Group) on SMIng, this memo and the accompanying memo on the SNMP
   protocol mapping [RFC3781] have been published for informational
   purposes.

Top      ToC       Page 5 
   Note that throughout these documents, the term "SMIng" refers to the
   specific data modeling language that is specified in this document,
   whereas the term "SMING" refers to the general effort within the IETF
   Working Group to define a new management data definition language as
   an SMIv2 successor and probably an SPPI merger, for which "SMIng" and
   "SMI-DS" were two specific proposals.

1.2.  Terms of Requirement Levels

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  SMIng Data Modeling

   SMIng is a language designed to specify management information in a
   structured way readable to computer programs, e.g., MIB compilers, as
   well as to human readers.

   Management information is modeled in classes.  Classes can be defined
   from scratch or by derivation from a parent class.  Derivation from
   multiple parent classes is not possible.  The concept of classes is
   described in Section 9.

   Each class has a number of attributes.  Each attribute represents an
   atomic piece of information of a base type, a sub-type of a base
   type, or another class.  The concept of attributes is described in
   Section 9.2.

   The base types of SMIng include signed and unsigned integers, octet
   strings, enumeration types, bitset types, and pointers.  Pointers are
   references to class instances, attributes of class instances, or
   arbitrary identities.  The SMIng type system is described in Section
   3.

   Related class and type definitions are defined in modules.  A module
   may refer to definitions from other modules by importing identifiers
   from those modules.  Each module may serve one or multiple purposes:

   o  the definition of management classes,

   o  the definition of events,

   o  the definition of derived types,

   o  the definition of arbitrary untyped identities serving as values
      of pointers,

Top      ToC       Page 6 
   o  the definition of SMIng extensions allowing the local module or
      other modules to specify information beyond the scope of the base
      SMIng in a machine readable notation.  Some extensions for the
      application of SMIng in the SNMP framework are defined in
      [RFC3781],

   o  the definition of information beyond the scope of the base SMIng
      statements, based on locally defined or imported SMIng extensions.

   Each module is identified by an upper-case identifier.  The names of
   all standard modules must be unique (but different versions of the
   same module should have the same name).  Developers of enterprise
   modules are encouraged to choose names for their modules that will
   have a low probability of colliding with standard or other enterprise
   modules, e.g., by using the enterprise or organization name as a
   prefix.

2.1.  Identifiers

   Identifiers are used to identify different kinds of SMIng items by
   name.  Each identifier is valid in a namespace which depends on the
   type of the SMIng item being defined:

   o  The global namespace contains all module identifiers.

   o  Each module defines a new namespace.  A module's namespace may
      contain definitions of extension identifiers, derived type
      identifiers, identity identifiers, and class identifiers.
      Furthermore, a module may import identifiers of these kinds from
      other modules.  All these identifiers are also visible within all
      inner namespaces of the module.

   o  Each class within a module defines a new namespace.  A class'
      namespace may contain definitions of attribute identifiers and
      event identifiers.

   o  Each enumeration type and bitset type defines a new namespace of
      its named numbers.  These named numbers are visible in each
      expression of a corresponding value, e.g., default values and
      sub-typing restrictions.

   o  Extensions may define additional namespaces and have additional
      rules of other namespaces' visibility.

   Within every namespace each identifier MUST be unique.

Top      ToC       Page 7 
   Each identifier starts with an upper-case or lower-case character,
   dependent on the kind of SMIng item, followed by zero or more
   letters, digits, and hyphens.

   All identifiers defined in a namespace MUST be unique and SHOULD NOT
   only differ in case.  Identifiers MUST NOT exceed 64 characters in
   length.  Furthermore, the set of all identifiers defined in all
   modules of a single standardization body or organization SHOULD be
   unique and mnemonic.  This promotes a common language for humans to
   use when discussing a module.

   To reference an item that is defined in the local module, its
   definition MUST sequentially precede the reference.  Thus, there MUST
   NOT be any forward references.

   To reference an item that is defined in an external module it MUST be
   imported (Section 5.1).  Identifiers that are neither defined nor
   imported MUST NOT be visible in the local module.

   When identifiers from external modules are referenced, there is the
   possibility of name collisions.  As such, if different items with the
   same identifier are imported or if imported identifiers collide with
   identifiers of locally defined items, then this ambiguity is resolved
   by prefixing those identifiers with the names of their modules and
   the namespace operator `::', i.e., `Module::item'.  Of course, this
   notation can be used to refer to identifiers even when there is no
   name collision.

   Note that SMIng core language keywords MUST NOT be imported.  See the
   `...Keyword' rules of the SMIng ABNF grammar in Appendix B for a list
   of those keywords.

3.  Base Types and Derived Types

   SMIng has a set of base types, similar to those of many programming
   languages, but with some differences due to special requirements from
   the management information model.

   Additional types may be defined, derived from those base types or
   from other derived types.  Derived types may use subtyping to
   formally restrict the set of possible values.  An initial set of
   commonly used derived types is defined in the SMIng standard module
   NMRG-SMING [RFC3781].

   The different base types and their derived types allow different
   kinds of subtyping, namely size restrictions of octet strings
   (Section 3.1), range restrictions of numeric types (Section 3.4

Top      ToC       Page 8 
   through Section 3.10), restricted pointer types (Section 3.2), and
   restrictions on the sets of named numbers for enumeration types
   (Section 3.11) and bit sets (Section 3.12).

3.1.  OctetString

   The OctetString base type represents arbitrary binary or textual
   data.  Although SMIng has a theoretical size limitation of 2^16-1
   (65535) octets for this base type, module designers should realize
   that there may be implementation and interoperability limitations for
   sizes in excess of 255 octets.

   Values of octet strings may be denoted as textual data enclosed in
   double quotes or as arbitrary binary data denoted as a `0x'-prefixed
   hexadecimal value of an even number of at least two hexadecimal
   digits, where each pair of hexadecimal digits represents a single
   octet.  Letters in hexadecimal values MAY be upper-case, but lower-
   case characters are RECOMMENDED.  Textual data may contain any number
   (possibly zero) of any 7-bit displayable ASCII characters, including
   tab characters, spaces, and line terminator characters (nl or cr &
   nl).  Some characters require a special encoding (see Section 4.2).
   Textual data may span multiple lines, where each subsequent line
   prefix containing only white space up to the column where the first
   line's data starts SHOULD be skipped by parsers for a better text
   formatting.

   When defining a type derived (directly or indirectly) from the
   OctetString base type, the size in octets may be restricted by
   appending a list of size ranges or explicit size values, separated by
   pipe `|' characters, with the whole list enclosed in parenthesis.  A
   size range consists of a lower bound, two consecutive dots `..', and
   an upper bound.  Each value can be given in decimal or `0x'-prefixed
   hexadecimal notation.  Hexadecimal numbers must have an even number
   of at least two digits.  Size restricting values MUST NOT be
   negative.  If multiple values or ranges are given, they all MUST be
   disjoint and MUST be in ascending order.  If a size restriction is
   applied to an already size restricted octet string, the new
   restriction MUST be equal or more limiting, that is, raising the
   lower bounds, reducing the upper bounds, removing explicit size
   values or ranges, or splitting ranges into multiple ranges with
   intermediate gaps.

Top      ToC       Page 9 
   Value Examples:

      "This is a multiline
       textual data example."         // legal
      "This is "illegally" quoted."   // illegal quotes
      "This is \"legally\" quoted."   // legally encoded quotes
      "But this is 'ok', as well."    // legal apostrophe quoting
      ""                              // legal zero length
      0x123                           // illegal odd hex length
      0x534d496e670a                  // legal octet string

   Restriction Examples:

      OctetString (0 | 4..255)        // legal size spec
      OctetString (4)                 // legal exact size
      OctetString (-1 | 1)            // illegal negative size
      OctetString (5 | 0)             // illegal ordering
      OctetString (1 | 1..10)         // illegal overlapping

3.2.  Pointer

   The Pointer base type represents values that reference class
   instances, attributes of class instances, or arbitrary identities.
   The only values of the Pointer type that can be present in a module
   can refer to identities.  They are denoted as identifiers of the
   concerned identities.

   When defining a type derived (directly or indirectly) from the
   Pointer base type, the values may be restricted to a specific class,
   attribute or identity, and all (directly or indirectly) derived items
   thereof by appending the identifier of the appropriate construct
   enclosed in parenthesis.

   Value Examples:

      null                          // legal identity name
      snmpUDPDomain                 // legal identity name

   Restriction Examples:

      Pointer (snmpTransportDomain) // legal restriction

3.3.  ObjectIdentifier

   The ObjectIdentifier base type represents administratively assigned
   names for use with SNMP and COPS-PR.  This type SHOULD NOT be used in
   protocol independent SMIng modules.  It is meant to be used in SNMP
   and COPS-PR mappings of attributes of type Pointer (Section 3.2).

Top      ToC       Page 10 
   Values of this type may be denoted as a sequence of numerical non-
   negative sub-identifier values in which each MUST NOT exceed 2^32-1
   (4294967295).  Sub-identifiers may be denoted in decimal or `0x'-
   prefixed hexadecimal.  They are separated by single dots and without
   any intermediate white space.  Alternatively (and preferred in most
   cases), the first element may be a previously defined or imported
   lower-case identifier, representing a static object identifier
   prefix.

   Although the number of sub-identifiers in SMIng object identifiers is
   not limited, module designers should realize that there may be
   implementations that stick with the SMIv1/v2 limit of 128 sub-
   identifiers.

   Object identifier derived types cannot be restricted in any way.

   Value Examples:

      1.3.6.1                     // legal numerical oid
      mib-2.1                     // legal oid with identifier prefix
      internet.4.1.0x0627.0x01    // legal oid with hex subids
      iso.-1                      // illegal negative subid
      iso.org.6                   // illegal non-heading identifier
      IF-MIB::ifNumber.0          // legal fully qualified instance oid

3.4.  Integer32

   The Integer32 base type represents integer values between
   -2^31 (-2147483648) and 2^31-1 (2147483647).

   Values of type Integer32 may be denoted as decimal or hexadecimal
   numbers, where only decimal numbers can be negative.  Decimal numbers
   other than zero MUST NOT have leading zero digits.  Hexadecimal
   numbers are prefixed by `0x' and MUST have an even number of at least
   two hexadecimal digits, where letters MAY be upper-case, but lower-
   case characters are RECOMMENDED.

   When defining a type derived (directly or indirectly) from the
   Integer32 base type, the set of possible values may be restricted by
   appending a list of ranges or explicit values, separated by pipe `|'
   characters, and the whole list enclosed in parenthesis.  A range
   consists of a lower bound, two consecutive dots `..', and an upper
   bound.  Each value can be given in decimal or `0x'-prefixed
   hexadecimal notation.  Hexadecimal numbers must have an even number
   of at least two digits.  If multiple values or ranges are given they
   all MUST be disjoint and MUST be in ascending order.  If a value
   restriction is applied to an already restricted type, the new
   restriction MUST be equal or more limiting, that is raising the lower

Top      ToC       Page 11 
   bounds, reducing the upper bounds, removing explicit values or
   ranges, or splitting ranges into multiple ranges with intermediate
   gaps.

   Value Examples:

      015                         // illegal leading zero
      -123                        // legal negative value
      - 1                         // illegal intermediate space
      0xabc                       // illegal hexadecimal value length
      -0xff                       // illegal sign on hex value
      0x80000000                  // illegal value, too large
      0xf00f                      // legal hexadecimal value

   Restriction Examples:

      Integer32 (0 | 5..10)       // legal range spec
      Integer32 (5..10 | 2..3)    // illegal ordering
      Integer32 (4..8 | 5..10)    // illegal overlapping

3.5.  Integer64

   The Integer64 base type represents integer values between
   -2^63 (-9223372036854775808) and 2^63-1 (9223372036854775807).

   Values of type Integer64 may be denoted as decimal or hexadecimal
   numbers, where only decimal numbers can be negative.  Decimal numbers
   other than zero MUST NOT have leading zero digits.  Hexadecimal
   numbers are prefixed by `0x' and MUST have an even number of
   hexadecimal digits, where letters MAY be upper-case, but lower-case
   characters are RECOMMENDED.

   When defining a type derived (directly or indirectly) from the
   Integer64 base type, the set of possible values may be restricted by
   appending a list of ranges or explicit values, separated by pipe `|'
   characters, with the whole list enclosed in parenthesis.  A range
   consists of a lower bound, two consecutive dots `..', and an upper
   bound.  Each value can be given in decimal or `0x'-prefixed
   hexadecimal notation.  Hexadecimal numbers must have an even number
   of at least two digits.  If multiple values or ranges are given, they
   all MUST be disjoint and MUST be in ascending order.  If a value
   restriction is applied to an already restricted type, the new
   restriction MUST be equal or more limiting, that is raising the lower
   bounds, reducing the upper bounds, removing explicit values or
   ranges, or splitting ranges into multiple ranges with intermediate
   gaps.

Top      ToC       Page 12 
   Value Examples:

      015                         // illegal leading zero
      -123                        // legal negative value
      - 1                         // illegal intermediate space
      0xabc                       // illegal hexadecimal value length
      -0xff                       // illegal sign on hex value
      0x80000000                  // legal value

   Restriction Examples:

      Integer64 (0 | 5..10)       // legal range spec
      Integer64 (5..10 | 2..3)    // illegal ordering
      Integer64 (4..8 | 5..10)    // illegal overlapping

3.6.  Unsigned32

   The Unsigned32 base type represents positive integer values between 0
   and 2^32-1 (4294967295).

   Values of type Unsigned32 may be denoted as decimal or hexadecimal
   numbers.  Decimal numbers other than zero MUST NOT have leading zero
   digits.  Hexadecimal numbers are prefixed by `0x' and MUST have an
   even number of hexadecimal digits, where letters MAY be upper-case,
   but lower-case characters are RECOMMENDED.

   When defining a type derived (directly or indirectly) from the
   Unsigned32 base type, the set of possible values may be restricted by
   appending a list of ranges or explicit values, separated by pipe `|'
   characters, with the whole list enclosed in parenthesis.  A range
   consists of a lower bound, two consecutive dots `..', and an upper
   bound.  Each value can be given in decimal or `0x'-prefixed
   hexadecimal notation.  Hexadecimal numbers must have an even number
   of at least two digits.  If multiple values or ranges are given, they
   all MUST be disjoint and MUST be in ascending order.  If a value
   restriction is applied to an already restricted type, the new
   restriction MUST be equal or more limiting, that is raising the lower
   bounds, reducing the upper bounds, removing explicit values or
   ranges, or splitting ranges into multiple ranges with intermediate
   gaps.

   Value Examples:

      015                         // illegal leading zero
      -123                        // illegal negative value
      0xabc                       // illegal hexadecimal value length
      0x80000000                  // legal hexadecimal value
      0x8080000000                // illegal value, too large

Top      ToC       Page 13 
   Restriction Examples:

      Unsigned32 (0 | 5..10)       // legal range spec
      Unsigned32 (5..10 | 2..3)    // illegal ordering
      Unsigned32 (4..8 | 5..10)    // illegal overlapping

3.7.  Unsigned64

   The Unsigned64 base type represents positive integer values between 0
   and 2^64-1 (18446744073709551615).

   Values of type Unsigned64 may be denoted as decimal or hexadecimal
   numbers.  Decimal numbers other than zero MUST NOT have leading zero
   digits.  Hexadecimal numbers are prefixed by `0x' and MUST have an
   even number of hexadecimal digits, where letters MAY be upper-case,
   but lower-case characters are RECOMMENDED.

   When defining a type derived (directly or indirectly) from the
   Unsigned64 base type, the set of possible values may be restricted by
   appending a list of ranges or explicit values, separated by pipe `|'
   characters, with the whole list enclosed in parenthesis.  A range
   consists of a lower bound, two consecutive dots `..', and an upper
   bound.  Each value can be given in decimal or `0x'-prefixed
   hexadecimal notation.  Hexadecimal numbers must have an even number
   of at least two digits.  If multiple values or ranges are given, they
   all MUST be disjoint and MUST be in ascending order.  If a value
   restriction is applied to an already restricted type, the new
   restriction MUST be equal or more limiting, that is raising the lower
   bounds, reducing the upper bounds, removing explicit values or
   ranges, or splitting ranges into multiple ranges with intermediate
   gaps.

   Value Examples:

      015                         // illegal leading zero
      -123                        // illegal negative value
      0xabc                       // illegal hexadecimal value length
      0x8080000000                // legal hexadecimal value

   Restriction Examples:

      Unsigned64 (1..10000000000) // legal range spec
      Unsigned64 (5..10 | 2..3)   // illegal ordering

3.8.  Float32

   The Float32 base type represents floating point values of single
   precision as described by [IEEE754].

Top      ToC       Page 14 
   Values of type Float32 may be denoted as a decimal fraction with an
   optional exponent, as known from many programming languages.  See the
   grammar rule `floatValue' of Appendix B for the detailed syntax.
   Special values are `snan' (signalling Not-a-Number), `qnan' (quiet
   Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
   infinity).  Note that -0.0 and +0.0 are different floating point
   values.  0.0 is equal to +0.0.

   When defining a type derived (directly or indirectly) from the
   Float32 base type, the set of possible values may be restricted by
   appending a list of ranges or explicit values, separated by pipe `|'
   characters, with the whole list enclosed in parenthesis.  A range
   consists of a lower bound, two consecutive dots `..', and an upper
   bound.  If multiple values or ranges are given, they all MUST be
   disjoint and MUST be in ascending order.  If a value restriction is
   applied to an already restricted type, the new restriction MUST be
   equal or more limiting, that is raising the lower bounds, reducing
   the upper bounds, removing explicit values or ranges, or splitting
   ranges into multiple ranges with intermediate gaps.  The special
   values `snan', `qnan', `neginf', and `posinf' must be explicitly
   listed in restrictions if they shall be included, where `snan' and
   `qnan' cannot be used in ranges.

   Note that encoding is not subject to this specification.  It has to
   be described by protocols that transport objects of type Float32.
   Note also that most floating point encodings disallow the
   representation of many values that can be written as decimal
   fractions as used in SMIng for human readability.  Therefore,
   explicit values in floating point type restrictions should be handled
   with care.

   Value Examples:

      00.1                       // illegal leading zero
      3.1415                     // legal value
      -2.5E+3                    // legal negative exponential value

   Restriction Examples:

      Float32 (-1.0..1.0)        // legal range spec
      Float32 (1 | 3.3 | 5)      // legal, probably unrepresentable 3.3
      Float32 (neginf..-0.0)     // legal range spec
      Float32 (-10.0..10.0 | 0)  // illegal overlapping

Top      ToC       Page 15 
3.9.  Float64

   The Float64 base type represents floating point values of double
   precision as described by [IEEE754].

   Values of type Float64 may be denoted as a decimal fraction with an
   optional exponent, as known from many programming languages.  See the
   grammar rule `floatValue' of Appendix B for the detailed syntax.
   Special values are `snan' (signalling Not-a-Number), `qnan' (quiet
   Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
   infinity).  Note that -0.0 and +0.0 are different floating point
   values.  0.0 is equal to +0.0.

   When defining a type derived (directly or indirectly) from the
   Float64 base type, the set of possible values may be restricted by
   appending a list of ranges or explicit values, separated by pipe `|'
   characters, with the whole list enclosed in parenthesis.  A range
   consists of a lower bound, two consecutive dots `..', and an upper
   bound.  If multiple values or ranges are given, they all MUST be
   disjoint and MUST be in ascending order.  If a value restriction is
   applied to an already restricted type, the new restriction MUST be
   equal or more limiting, that is raising the lower bounds, reducing
   the upper bounds, removing explicit values or ranges, or splitting
   ranges into multiple ranges with intermediate gaps.  The special
   values `snan', `qnan', `neginf', and `posinf' must be explicitly
   listed in restrictions if they shall be included, where `snan' and
   `qnan' cannot be used in ranges.

   Note that encoding is not subject to this specification.  It has to
   be described by protocols that transport objects of type Float64.
   Note also that most floating point encodings disallow the
   representation of many values that can be written as decimal
   fractions as used in SMIng for human readability.  Therefore,
   explicit values in floating point type restrictions should be handled
   with care.

   Value Examples:

      00.1                       // illegal leading zero
      3.1415                     // legal value
      -2.5E+3                    // legal negative exponential value

   Restriction Examples:

      Float64 (-1.0..1.0)        // legal range spec
      Float64 (1 | 3.3 | 5)      // legal, probably unrepresentable 3.3
      Float64 (neginf..-0.0)     // legal range spec
      Float64 (-10.0..10.0 | 0)  // illegal overlapping

Top      ToC       Page 16 
3.10.  Float128

   The Float128 base type represents floating point values of quadruple
   precision as described by [IEEE754].

   Values of type Float128 may be denoted as a decimal fraction with an
   optional exponent, as known from many programming languages.  See the
   grammar rule `floatValue' of Appendix B for the detailed syntax.
   Special values are `snan' (signalling Not-a-Number), `qnan' (quiet
   Not-a-Number), `neginf' (negative infinity), and `posinf' (positive
   infinity).  Note that -0.0 and +0.0 are different floating point
   values.  0.0 is equal to +0.0.

   When defining a type derived (directly or indirectly) from the
   Float128 base type, the set of possible values may be restricted by
   appending a list of ranges or explicit values, separated by pipe `|'
   characters, with the whole list enclosed in parenthesis.  A range
   consists of a lower bound, two consecutive dots `..', and an upper
   bound.  If multiple values or ranges are given, they all MUST be
   disjoint and MUST be in ascending order.  If a value restriction is
   applied to an already restricted type, the new restriction MUST be
   equal or more limiting, that is raising the lower bounds, reducing
   the upper bounds, removing explicit values or ranges, or splitting
   ranges into multiple ranges with intermediate gaps.  The special
   values `snan', `qnan', `neginf', and `posinf' must be explicitly
   listed in restrictions if they shall be included, where `snan' and
   `qnan' cannot be used in ranges.

   Note that encoding is not subject to this specification.  It has to
   be described by protocols that transport objects of type Float128.
   Note also that most floating point encodings disallow the
   representation of many values that can be written as decimal
   fractions as used in SMIng for human readability.  Therefore,
   explicit values in floating point type restrictions should be handled
   with care.

   Value Examples:

      00.1                       // illegal leading zero
      3.1415                     // legal value
      -2.5E+3                    // legal negative exponential value

   Restriction Examples:

      Float128 (-1.0..1.0)        // legal range spec
      Float128 (1 | 3.3 | 5)      // legal, probably unrepresentable 3.3
      Float128 (neginf..-0.0)     // legal range spec
      Float128 (-10.0..10.0 | 0)  // illegal overlapping

Top      ToC       Page 17 
3.11.  Enumeration

   The Enumeration base type represents values from a set of integers in
   the range between -2^31 (-2147483648) and 2^31-1 (2147483647), where
   each value has an assigned name.  The list of those named numbers has
   to be comma-separated, enclosed in parenthesis, and appended to the
   `Enumeration' keyword.  Each named number is denoted by its lower-
   case identifier followed by the assigned integer value, denoted as a
   decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis.
   Hexadecimal numbers must have an even number of at least two digits.
   Every name and every number in an enumeration type MUST be unique.
   It is RECOMMENDED that values be positive, start at 1, and be
   numbered contiguously.  All named numbers MUST be given in ascending
   order.

   Values of enumeration types may be denoted as decimal or `0x'-
   prefixed hexadecimal numbers or preferably as their assigned names.
   Hexadecimal numbers must have an even number of at least two digits.

   When types are derived (directly or indirectly) from an enumeration
   type, the set of named numbers may be equal or restricted by removing
   one or more named numbers, but no named numbers may be added or
   changed regarding its name, value, or both.

   Type and Value Examples:

   Enumeration (up(1), down(2), testing(3))
   Enumeration (down(2), up(1)) // illegal order

   0                            // legal (though not recommended) value
   up                           // legal value given by name
   2                            // legal value given by number

3.12.  Bits

   The Bits base type represents bit sets.  That is, a Bits value is a
   set of flags identified by small integer numbers starting at 0.  Each
   bit number has an assigned name.  The list of those named numbers has
   to be comma-separated, enclosed in parenthesis, and appended to the
   `Bits' keyword.  Each named number is denoted by its lower-case
   identifier followed by the assigned integer value, denoted as a
   decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis.
   Hexadecimal numbers must have an even number of at least two digits.
   Every name and every number in a bits type MUST be unique.  It is
   RECOMMENDED that numbers start at 0 and be numbered contiguously.
   Negative numbers are forbidden.  All named numbers MUST be given in
   ascending order.

Top      ToC       Page 18 
   Values of bits types may be denoted as a comma-separated list of
   decimal or `0x'-prefixed hexadecimal numbers or preferably their
   assigned names enclosed in parenthesis.  Hexadecimal numbers must
   have an even number of at least two digits.  There MUST NOT be any
   element (by name or number) listed more than once.  Elements MUST be
   listed in ascending order.

   When defining a type derived (directly or indirectly) from a bits
   type, the set of named numbers may be restricted by removing one or
   more named numbers, but no named numbers may be added or changed
   regarding its name, value, or both.

   Type and Value Examples:

      Bits (readable(0), writable(1), executable(2))
      Bits (writable(1), readable(0) // illegal order

      ()                          // legal empty value
      (readable, writable, 2)     // legal value
      (0, readable, executable)   // illegal, readable(0) appears twice
      (writable, 4)               // illegal, element 4 out of range

3.13.  Display Formats

   Attribute and type definitions allow the specification of a format to
   be used when a value of that attribute or an attribute of that type
   is displayed.  Format specifications are represented as textual data.

   When the attribute or type has an underlying base type of Integer32,
   Integer64, Unsigned32, or Unsigned64, the format consists of an
   integer-format specification containing two parts.  The first part is
   a single character suggesting a display format, either: `x' for
   hexadecimal, `d' for decimal, `o' for octal, or `b' for binary.  For
   all types, when rendering the value, leading zeros are omitted, and
   for negative values, a minus sign is rendered immediately before the
   digits.  The second part is always omitted for `x', `o', and `b', and
   need not be present for `d'.  If present, the second part starts with
   a hyphen and is followed by a decimal number, which defines the
   implied decimal point when rendering the value.  For example `d-2'
   suggests that a value of 1234 be rendered as `12.34'.

   When the attribute or type has an underlying base type of
   OctetString, the format consists of one or more octet-format
   specifications.  Each specification consists of five parts, with each
   part using and removing zero or more of the next octets from the

Top      ToC       Page 19 
   value and producing the next zero or more characters to be displayed.
   The octets within the value are processed in order of significance,
   most significant first.

   The five parts of a octet-format specification are:

   1. The (optional) repeat indicator.  If present, this part is a `*',
      and indicates that the current octet of the value is to be used as
      the repeat count.  The repeat count is an unsigned integer (which
      may be zero) specifying how many times the remainder of this
      octet-format specification should be successively applied.  If the
      repeat indicator is not present, the repeat count is one.

   2. The octet length: one or more decimal digits specifying the number
      of octets of the value to be used and formatted by this octet-
      specification.  Note that the octet length can be zero.  If less
      than this number of octets remain in the value, then the lesser
      number of octets are used.

   3. The display format, either: `x' for hexadecimal, `d' for decimal,
      `o' for octal, `a' for ASCII, or `t' for UTF-8 [RFC3629].  If the
      octet length part is greater than one, and the display format part
      refers to a numeric format, then network byte-ordering (big-endian
      encoding) is used to interpret the octets in the value.  The
      octets processed by the `t' display format do not necessarily form
      an integral number of UTF-8 characters.  Trailing octets which do
      not form a valid UTF-8 encoded character are discarded.

   4. The (optional) display separator character.  If present, this part
      is a single character produced for display after each application
      of this octet-specification; however, this character is not
      produced for display if it would be immediately followed by the
      display of the repeat terminator character for this octet
      specification.  This character can be any character other than a
      decimal digit and a `*'.

   5. The (optional) repeat terminator character, which can be present
      only if the display separator character is present and this octet
      specification begins with a repeat indicator.  If present, this
      part is a single character produced after all the zero or more
      repeated applications (as given by the repeat count) of this octet
      specification.  This character can be any character other than a
      decimal digit and a `*'.

   Output of a display separator character or a repeat terminator
   character is suppressed if it would occur as the last character of
   the display.

Top      ToC       Page 20 
   If the octets of the value are exhausted before all the octet format
   specifications have been used, then the excess specifications are
   ignored.  If additional octets remain in the value after interpreting
   all the octet format specifications, then the last octet format
   specification is re-interpreted to process the additional octets,
   until no octets remain in the value.

   Note that for some types, no format specifications are defined.  For
   derived types and attributes that are based on such types, format
   specifications SHOULD be omitted.  Implementations MUST ignore format
   specifications they cannot interpret.  Also note that the SMIng
   grammar (Appendix B) does not specify the syntax of format
   specifications.

   Display Format Examples:

      Base Type   Format              Example Value    Rendered Value
      ----------- ------------------- ---------------- -----------------
      OctetString 255a                "Hello World."   Hello World.
      OctetString 1x:                 "Hello!"         48:65:6c:6c:6f:21
      OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0
      OctetString 1d.1d.1d.1d/2d      0x0a0000010400   10.0.0.1/1024
      OctetString *1x:/1x:            0x02aabbccddee   aa:bb/cc:dd:ee
      Integer32   d-2                 1234             12.34



(page 20 continued on part 2)

Next RFC Part