GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3216

Network Working Group C. Elliott Request for Comments: 3216 Cisco Systems Category: Informational D. Harrington

                                                    Enterasys Networks
                                                              J. Jason
                                                     Intel Corporation
                                                      J. Schoenwaelder
                                                            F. Strauss
                                                       TU Braunschweig
                                                              W. Weiss
                                                     Ellacoya Networks
                                                         December 2001
                          SMIng Objectives

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

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

Abstract

 This document describes the objectives for a new data definition
 language, suitable for the modeling of network management constructs,
 that can be directly mapped into SNMP and COPS-PR protocol
 operations.
 The purpose of this document is to serve as a set of objectives that
 a subsequent language specification should try to address.  It
 captures the results of the working group discussions towards
 consensus on the SMIng objectives.

Table of Contents

 1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
 2.     Motivation . . . . . . . . . . . . . . . . . . . . . . . .   3
 3.     Background . . . . . . . . . . . . . . . . . . . . . . . .   4
 4.     Specific Objectives for SMIng  . . . . . . . . . . . . . .   4
 4.1    Accepted Objectives  . . . . . . . . . . . . . . . . . . .   5
 4.1.1  The Set of Specification Documents . . . . . . . . . . . .   6
 4.1.2  Textual Representation . . . . . . . . . . . . . . . . . .   6
 4.1.3  Human Readability  . . . . . . . . . . . . . . . . . . . .   6

Elliott, et al. Informational [Page 1] RFC 3216 SMIng Objectives December 2001

 4.1.4  Rigorously Defined Syntax  . . . . . . . . . . . . . . . .   6
 4.1.5  Accessibility  . . . . . . . . . . . . . . . . . . . . . .   7
 4.1.6  Language Extensibility . . . . . . . . . . . . . . . . . .   7
 4.1.7  Special Characters in Text . . . . . . . . . . . . . . . .   7
 4.1.8  Naming . . . . . . . . . . . . . . . . . . . . . . . . . .   8
 4.1.9  Namespace Control  . . . . . . . . . . . . . . . . . . . .   8
 4.1.10 Modules  . . . . . . . . . . . . . . . . . . . . . . . . .   8
 4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . .   9
 4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . .   9
 4.1.13 Protocol Independence  . . . . . . . . . . . . . . . . . .   9
 4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . .  10
 4.1.15 Translation to Other Data Definition Languages . . . . . .  10
 4.1.16 Base Data Types  . . . . . . . . . . . . . . . . . . . . .  10
 4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . .  11
 4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . .  11
 4.1.19 Instance Pointers  . . . . . . . . . . . . . . . . . . . .  11
 4.1.20 Row Pointers . . . . . . . . . . . . . . . . . . . . . . .  12
 4.1.21 Constraints on Pointers  . . . . . . . . . . . . . . . . .  12
 4.1.22 Base Type Set  . . . . . . . . . . . . . . . . . . . . . .  12
 4.1.23 Extended Data Types  . . . . . . . . . . . . . . . . . . .  12
 4.1.24 Units, Formats, and Default Values of Defined Types and
        Attributes . . . . . . . . . . . . . . . . . . . . . . . .  13
 4.1.25 Table Existence Relationships  . . . . . . . . . . . . . .  13
 4.1.26 Table Existence Relationships (2)  . . . . . . . . . . . .  14
 4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . .  14
 4.1.28 Containment  . . . . . . . . . . . . . . . . . . . . . . .  14
 4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . .  15
 4.1.30 Reusable vs. Final Attribute Groups  . . . . . . . . . . .  15
 4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . .  16
 4.1.32 Creation/Deletion  . . . . . . . . . . . . . . . . . . . .  16
 4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . .  16
 4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . .  16
 4.1.35 Extension Rules  . . . . . . . . . . . . . . . . . . . . .  17
 4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . .  17
 4.1.37 No Redundancy  . . . . . . . . . . . . . . . . . . . . . .  17
 4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . .  17
 4.1.39 Allow Refinement of All Definitions in Conformance
        Statements . . . . . . . . . . . . . . . . . . . . . . . .  18
 4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . .  18
 4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . .  19
 4.1.42 Instance Naming  . . . . . . . . . . . . . . . . . . . . .  19
 4.1.43 Length of Identifiers  . . . . . . . . . . . . . . . . . .  19
 4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . .  20
 4.2    Nice-to-Have Objectives  . . . . . . . . . . . . . . . . .  20
 4.2.1  Methods  . . . . . . . . . . . . . . . . . . . . . . . . .  20
 4.2.2  Unions . . . . . . . . . . . . . . . . . . . . . . . . . .  21
 4.2.3  Float Data Types . . . . . . . . . . . . . . . . . . . . .  21
 4.2.4  Comments . . . . . . . . . . . . . . . . . . . . . . . . .  22

Elliott, et al. Informational [Page 2] RFC 3216 SMIng Objectives December 2001

 4.2.5  Referencing Tagged Rows  . . . . . . . . . . . . . . . . .  22
 4.2.6  Arrays . . . . . . . . . . . . . . . . . . . . . . . . . .  22
 4.2.7  Internationalization . . . . . . . . . . . . . . . . . . .  23
 4.2.8  Separate Data Modelling from Management Protocol Mapping .  23
 4.3    Rejected Objectives  . . . . . . . . . . . . . . . . . . .  24
 4.3.1  Incomplete Translations  . . . . . . . . . . . . . . . . .  24
 4.3.2  Attribute Value Constraints  . . . . . . . . . . . . . . .  24
 4.3.3  Attribute Transaction Constraints  . . . . . . . . . . . .  25
 4.3.4  Method Constraints . . . . . . . . . . . . . . . . . . . .  25
 4.3.5  Agent Capabilities . . . . . . . . . . . . . . . . . . . .  25
 4.3.6  Relationships  . . . . . . . . . . . . . . . . . . . . . .  26
 4.3.7  Procedures . . . . . . . . . . . . . . . . . . . . . . . .  26
 4.3.8  Associations . . . . . . . . . . . . . . . . . . . . . . .  26
 4.3.9  Association Cardinalities  . . . . . . . . . . . . . . . .  27
 4.3.10 Categories of Modules  . . . . . . . . . . . . . . . . . .  27
 4.3.11 Mapping Modules to Files . . . . . . . . . . . . . . . . .  27
 4.3.12 Simple Grammar . . . . . . . . . . . . . . . . . . . . . .  28
 4.3.13 Place of Module Information  . . . . . . . . . . . . . . .  28
 4.3.14 Module Namespace . . . . . . . . . . . . . . . . . . . . .  29
 4.3.15 Hyphens in Identifiers . . . . . . . . . . . . . . . . . .  29
 5.     Security Considerations  . . . . . . . . . . . . . . . . .  30
 6.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  30
 7.     References . . . . . . . . . . . . . . . . . . . . . . . .  30
 8.     Authors' Addresses . . . . . . . . . . . . . . . . . . . .  31
 9.     Full Copyright Statement . . . . . . . . . . . . . . . . .  33

1. Introduction

 This document describes the objectives for a new data definition
 language that can be mapped into SNMP [1], [2] and COPS-PR [3]
 protocol operations.  It may also be translated into SMIv2 [4], [5],
 [6] MIBs and SPPI [7] PIBs.  Concepts such as attributes, attribute
 groups, methods, conventions for organization into reusable data
 structures, and mechanisms for representing relationships are
 discussed.

2. Motivation

 As networking technology has evolved, a diverse set of technologies
 has been deployed to manage the resulting products.  These vary from
 Web based products, to standard management protocols and text
 scripts.  The underlying systems to be manipulated are represented in
 varying ways including implicitly in the system programming, via
 proprietary data descriptions, or with standardized descriptions
 using a range of technologies including MIBs, PIBs, or LDAP schemas.
 The result is that management interfaces for network protocols,
 services, and applications such as Differentiated Services may be
 represented in many different, inconsistent fashions.

Elliott, et al. Informational [Page 3] RFC 3216 SMIng Objectives December 2001

 The SMIng working group has been chartered to define a new data
 definition language that will eliminate the need for a separate SMIv2
 and SPPI language.  That is, the new language should address the
 needs for the current SMIv2 and SPPI languages so that over time we
 can all use the new language instead.
 Another motivation is to permit a more expressive and complete
 representation of the modeled information.  Examples of additional
 expressiveness and completeness that are considered are the ability
 to formally define table existence relationships, the expression of
 instance creation/deletion capabilities, and the ability to define
 attribute groups using inheritance.  These additional features are
 discussed in subsequent sections.
 It has been recognized that the two main goals of (a) merging
 SMIv2/SPPI and (b) enhancing the state of art in network management
 data modeling can lead to conflicts.  In such cases, the SMIng
 working group's consensus is to focus on enhancing the state of art
 in network management data modeling.

3. Background

 The Network Management Research Group (NMRG) of the Internet Research
 Task Force (IRTF) has researched the issues of creating a protocol-
 independent data definition language that could be used by multiple
 protocols.  Because SMIv2 and SPPI are very similar, the NMRG focused
 on merging these two languages, but also researched ways to abstract
 the objectives to produce a language that could be used for other
 protocols, such as LDAP and Diameter.  The NMRG has published the
 results of their work in a meanwhile expired Internet Draft, but has
 submitted their specification as one proposal to consider in the
 development of the SMIng language.
 The SMIng Working Group has accepted their submission for
 consideration, and to use their proposal to better understand the
 objectives and possible obstacles to be overcome.  Where useful, the
 NMRG proposal has been referenced in the details below.

4. Specific Objectives for SMIng

 The following sections define the objectives for the definition of a
 new data definition language.  The objectives have been organized as
 follows: accepted objectives (Section 4.1), nice-to-have objectives
 (Section 4.2), and rejected objectives (Section 4.3).  Each objective
 has the following information:
 o  Type: a field that identifies the type of objective, using one of
    the following values:

Elliott, et al. Informational [Page 4] RFC 3216 SMIng Objectives December 2001

  • basic: considered a basic objective for SMIng and is contained

in SMIv2 and/or SPPI.

  • align: supported in different ways in SMIv2 and SPPI and they

must be aligned.

  • fix: considered a fix for a known problem in SMIv2 and/or SPPI.
  • new: considered a new feature.
 o  From: a field that defines the origin of the objective and that
    contains one or more of the following values:
  • SMI: exists in SMIv2.
  • SPPI: exists in SPPI.
  • NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI.
  • Charter: exists in working group charter.
  • WG: proposed during working group discussions.
 o  Description: a quick description of the objective.
 o  Motivation: rationale for the objective.
 o  Notes: optional notes about an objective.  For example, for nice-
    to-have or rejected this may contain reasoning why this objective
    is not required by the SMIng working group, but justification why
    it should be considered anyway.  Notes may be the opinions of the
    participants in the discussion on objectives and as such should
    not be taken as consensus of the working group or the
    recommendation of the objectives editing team.

4.1 Accepted Objectives

 This section represents the list of objectives that have been
 accepted by the SMIng working group as worthwhile and therefore
 deserving of further consideration.  Each of these objectives must be
 evaluated by the working group to determine if the benefit incurs an
 acceptable level of cost.  An accepted objective may subsequently be
 rejected if the cost/benefit analysis determines that the benefit
 does not justify the cost or that the objective is in direct conflict
 with one or more other accepted objectives that are deemed more
 important.

Elliott, et al. Informational [Page 5] RFC 3216 SMIng Objectives December 2001

4.1.1 The Set of Specification Documents

 Type: new
 From: NMRG
 Description: SMIv2 is defined in three documents, based on an
    obsolete ITU ASN.1 specification.  SPPI is defined in one
    document, based on SMIv2.  The core of SMIng must be defined in
    one document and must be independent of external specifications.
 Motivation: Self-containment.

4.1.2 Textual Representation

 Type: basic
 From: SMI, SPPI, WG
 Description: SMIng definitions must be represented in a textual
    format.
 Motivation: General IETF consensus.

4.1.3 Human Readability

 Type: basic
 From: WG
 Description: The syntax must make it easy for humans to directly read
    and write SMIng modules.  It must be possible for SMIng module
    authors to produce SMIng modules with text editing tools.
 Motivation: The syntax must make it easy for humans to read and write
    SMIng modules.

4.1.4 Rigorously Defined Syntax

 Type: new
 From: NMRG
 Description: There must be a rigorously defined syntax for the SMIng
    language.

Elliott, et al. Informational [Page 6] RFC 3216 SMIng Objectives December 2001

 Motivation: An unambiguous language promotes consistency across
    vendors so that different parsers produce the same results.  It
    also provides authoritative rules to SMIng modules designers.

4.1.5 Accessibility

 Type: align
 From: SMI, SPPI
 Description: Attribute definitions must indicate whether attributes
    can be read, written, created, deleted, and whether they are
    accessible for notifications, or are not accessible.  Align PIB-
    ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
 Motivation: Alignment of SMIv2 and SPPI.

4.1.6 Language Extensibility

 Type: new
 From: NMRG
 Description: The language must have characteristics, so that future
    modules can contain information of future syntax without breaking
    original SMIng parsers.
    E.g., when SMIv2 introduced REFERENCEs it would have been nice if
    it would not have broken SMIv1 parsers.
 Motivation: Achieve language extensibility without breaking core
    compatibility.

4.1.7 Special Characters in Text

 Type: new
 From: WG
 Description: Allow an escaping mechanism to encode special
    characters, e.g. double quotes and new-line characters, in text
    such as DESCRIPTIONs or REFERENCEs.
 Motivation: ABNF can contain literal characters enclosed in double
    quotes; to provide the ABNF grammar, there must be the ability to
    escape special characters.

Elliott, et al. Informational [Page 7] RFC 3216 SMIng Objectives December 2001

4.1.8 Naming

 Type: basic
 From: SMI, SPPI
 Description: SMIng must provide mechanisms to uniquely identify
    attributes, groups of attributes, and events.  It is necessary to
    specify how name collisions are handled.
 Motivation: Already in SMIv2 and SPPI.

4.1.9 Namespace Control

 Type: basic
 From: SMI, SPPI
 Description: There must be a hierarchical, centrally-controlled
    namespace for standard named items, and a distributed namespace
    must be supported to allow vendor-specific naming and to assure
    unique module names across vendors and organizations.
 Motivation: Need to unambiguously identify definitions of various
    kinds.  Some SMI implementations have problems with different
    objects from multiple modules but with the same name.
    Furthermore, the probability of module name clashes rises over
    time (for example, different vendors defining their own SYSTEM-
    MIB).
 Notes: An example naming scheme is the one employed by the Java
    programming language with a central naming authority assigning the
    top-level names.

4.1.10 Modules

 Type: basic
 From: SMI, SPPI
 Description: SMIng must provide a mechanism for uniquely identifying
    a module, and specifying the status, contact person, revision
    information, and the purpose of a module.
    SMIng must provide mechanisms to group definitions into modules
    and it must provide rules for referencing definitions from other
    modules.

Elliott, et al. Informational [Page 8] RFC 3216 SMIng Objectives December 2001

 Motivation: Modularity and independent advancement of documents.
 Notes: Text about module conformance has been moved to Section
    4.1.11.

4.1.11 Module Conformance

 Type: basic
 From: SMI, SPPI
 Description: SMIng must provide mechanisms to detail the minimum
    requirements implementers must meet to claim conformance to a
    standard based on the module.
 Motivation: Ability to convey conformance requirements.

4.1.12 Arbitrary Unambiguous Identities

 Type: basic
 From: SMI
 Description: SMI allows the use of OBJECT-IDENTITIES to define
    unambiguous identities without the need of a central registry.
    SMI uses OIDs to represent values that represent references to
    such identities.  SMIng needs a similar mechanism (a statement to
    register identities, and a base type to represent values).
 Motivation: SMI Compatibility.
 Notes: This is an obvious objective.  Additionally, everything not on
    the wire, such as modules, will still be assigned OIDs.
    It is yet to be determined whether the assignment of the OID
    occurs within the core or within a protocol-specific mapping.

4.1.13 Protocol Independence

 Type: basic
 From: Charter
 Description: SMIng must define data definitions in support of the
    SNMP and COPS-PR protocols.  SMIng may define data definitions in
    support of other protocols.

Elliott, et al. Informational [Page 9] RFC 3216 SMIng Objectives December 2001

 Motivation: So data definitions may be used with multiple protocols
    and multiple versions of those protocols.

4.1.14 Protocol Mapping

 Type: basic
 From: Charter
 Description: The SMIng working group, in accordance with the working
    group charter, will define mappings of protocol independent data
    definitions to protocols based upon installed implementations.
    The SMIng working group can define mappings to other protocols as
    long as this does not impede the progress on other objectives.
 Motivation: SMIng working group charter.

4.1.15 Translation to Other Data Definition Languages

 Type: basic
 From: Charter
 Description: SMIng language constructs must, wherever possible, be
    translatable to SMIv2 and SPPI.  At the time of standardization of
    a SMIng language, existing SMIv2 MIBs and SPPI PIBs on the
    standards track will not be required to be translated to the SMIng
    language.  New MIBs/PIBs will be defined using the SMIng language.
 Motivation: Provide best-effort backwards compatibility for existing
    tools while not placing an unnecessary burden on MIBs/PIBs that
    are already on the standards track.

4.1.16 Base Data Types

 Type: basic
 From: SMI, SPPI
 Description: SMIng must support the base data types Integer32,
    Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString,
    and OID.
 Motivation: Most are already common.  Unsigned64 and Integer64 are in
    SPPI, must fix in SMI.  Note that Counter and Gauge types can be
    regarded as derived types instead of base types.

Elliott, et al. Informational [Page 10] RFC 3216 SMIng Objectives December 2001

4.1.17 Enumerations

 Type: basic
 From: SMI, SPPI
 Description: SMIng must provide support for enumerations.  Enumerated
    values must be a part of the enumeration definition.
 Motivation: SMIv2 already has enumerated numbers.
 Notes: Enumerations have the implicit constraint that the attribute
    is constrained to the values for the enumeration.

4.1.18 Discriminated Unions

 Type: new
 From: WG
 Description: SMIng must support discriminated unions.
 Motivation: Allows to group related attributes together, such as
    InetAddressType (discriminator) and InetAddress, InetAddressIPv4,
    InetAddressIPv6 (union).  The lack of discriminated unions has
    also lead to relatively complex sparse table work-around in some
    DISMAN mid-level manager MIBs.
 Notes: Discriminated unions have the property that the union
    attribute type is constrained by the value of the discriminator
    attribute.

4.1.19 Instance Pointers

 Type: basic
 From: SMI, SPPI
 Description: SMIng must allow specifying pointers to instances (i.e.,
    a pointer to a particular attribute in a row).
 Motivation: It is common practice in MIBs and PIBs to point to other
    instances.

Elliott, et al. Informational [Page 11] RFC 3216 SMIng Objectives December 2001

4.1.20 Row Pointers

 Type: align
 From: SMI, SPPI
 Description: SMIng must allow specifying pointers to rows.
 Motivation: It is common practice in MIBs and PIBs to point to other
    rows (see RowPointer, PIB-REFERENCES).

4.1.21 Constraints on Pointers

 Type: align
 From: SPPI
 Description: SMIng must allow specifying the types of objects to
    which a pointer may point.
 Motivation: Allows code generators to detect and reject illegal
    pointers automatically.  Can also be used to automatically
    generate more reasonable implementation-specific data structures.
 Notes: Pointer constraints are a special case of attribute value
    constraints (Section 4.3.2) in which the prefix of the OID (row or
    instance pointer) value is limited to be only from a particular
    table.

4.1.22 Base Type Set

 Type: basic
 From: SMI, SPPI
 Description: SMIng must support a fixed set of base types of fixed
    size and precision.  The list of base types must not be extensible
    unless the SMI itself changes.
 Motivation: Interoperability.

4.1.23 Extended Data Types

 Type: align
 From: SMI, SPPI

Elliott, et al. Informational [Page 12] RFC 3216 SMIng Objectives December 2001

 Description: SMIng must support a mechanism to derive new types,
    which provide additional semantics (e.g., Counters, Gauges,
    Strings, etc.), from base types.  It may be desirable to also
    allow the derivation of new types from derived types.  New types
    must be as restrictive or more restrictive than the types that
    they are specializing.
 Motivation: SMI uses application types and textual conventions.  SPPI
    uses derived types.

4.1.24 Units, Formats, and Default Values of Defined Types and

     Attributes
 Type: fix
 From: NMRG
 Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS and
    DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs.
    In a similar fashion units and default values must be applicable
    to defined types and format information must be applicable to
    attributes.
 Motivation: Some MIBs introduce TCs such as KBytes and every usage of
    the TC then specifies the UNITS "KBytes".  It would simplify
    things if the UNITS were attached to the type definition itself.
 Notes: The SMIng WG must clarify the behavior if an attribute uses a
    defined type and both, the attribute and the defined type, have
    units/default/format information.

4.1.25 Table Existence Relationships

 Type: align
 From: SMI, SPPI
 Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in the
    SNMP/COPS-PR protocol mappings.
 Motivation: These three table existence relationships exist either in
    the SMIv2 or the SPPI.

Elliott, et al. Informational [Page 13] RFC 3216 SMIng Objectives December 2001

4.1.26 Table Existence Relationships (2)

 Type: new
 From: NMRG
 Description: SMIng must support EXPANDS and REORDERS relationships in
    the SNMP/COPS-PR protocol mappings.
 Motivation: A REORDERS statement allows indexing orders to be
    swapped.  An EXPANDS statement formally states that there is a 1:n
    existence relationship between table rows.

4.1.27 Attribute Groups

 Type: new
 From: NMRG
 Description: An attribute group is a named, reusable set of
    attributes that are meaningful together.  It can be reused as the
    type of attributes in other attribute groups (see also Section
    4.1.28).  This is similar to `structs' in C.
 Motivation: Required to map the same grouping of attributes into SNMP
    and COPS-PR tables.  Allows to do index reordering without having
    to redefine the attribute group.  Allows to group related
    attributes together (e.g. InetAddressType, InetAddress).
    The ability to group attributes provides an indication that the
    attributes are meaningful together.

4.1.28 Containment

 Type: new
 From: NMRG
 Description: SMIng must provide support for the creation of new
    attribute groups from attributes of more basic types and
    potentially other attribute groups.
 Motivation: Simplifies the reuse of attribute groups such as
    InetAddressType and InetAddress pairs.

Elliott, et al. Informational [Page 14] RFC 3216 SMIng Objectives December 2001

 Notes: Containment has the implicit existence constraint that if an
    instance of a contained attribute group exists, then the
    corresponding instance of the containing attribute group must also
    exist.

4.1.29 Single Inheritance

 Type: new
 From: NMRG
 Description: SMIng must provide support for mechanisms to extend
    attribute groups through single inheritance.
 Motivation: Allows to extend attribute groups, like a generic
    DiffServ scheduler, with attributes for a specific scheduler,
    without cut&paste.
 Notes: Single inheritance with multiple levels (e.g., C derives from
    B, and B derives from A) must be allowed.
    Inheritance has the implicit existence constraint that if an
    instance of a derived attribute group exists, then the
    corresponding instance of the base attribute group must also
    exist.
    Inheritance could help to add attributes to an attribute group
    that are specific to a certain protocol mapping and do not appear
    in the protocol-neutral attribute group.

4.1.30 Reusable vs. Final Attribute Groups

 Type: new
 From: NMRG, WG
 Description: SMIng must differentiate between "final" and reusable
    attribute groups, where the reuse of attribute groups covers
    inheritance and containment.
 Motivation: This information gives people more information how
    attribute groups can and should be used.  It hinders them from
    misusing them.
 Notes: This objective attempts to convey the idea that some attribute
    groups are not meant to stand on their own and instead only make
    sense if contained within another attribute group.

Elliott, et al. Informational [Page 15] RFC 3216 SMIng Objectives December 2001

4.1.31 Events

 Type: basic
 From: SMI, SPPI
 Description: SMIng must provide mechanisms to define events which
    identify significant state changes.
 Motivation: These represent the protocol-independent events that lead
    to SMI notifications or SPPI reports.

4.1.32 Creation/Deletion

 Type: align
 From: SMI, SPPI
 Description: SMIng must support a mechanism to define
    creation/deletion operations for instances.  Specific
    creation/deletion errors, such as INSTALL-ERRORS, must be
    supported.
 Motivation: Available for row creation in SMI, and available in SPPI.

4.1.33 Range and Size Constraints

 Type: basic
 From: SMI, SPPI
 Description: SMIng must allow specifying range and size constraints
    where applicable.
 Motivation: The SMI and SPPI both support range and size constraints.

4.1.34 Uniqueness

 Type: basic
 From: SPPI
 Description: SMIng must allow the specification of uniqueness
    constraints on attributes.  SMIng must allow the specification of
    multiple independent uniqueness constraints.

Elliott, et al. Informational [Page 16] RFC 3216 SMIng Objectives December 2001

 Motivation: Knowledge of the uniqueness constraints on attributes
    allows to verify protocol specific mappings (e.g. INDEX clauses).
    The knowledge can also be used by code generators to improve
    generated implementation-specific data structures.

4.1.35 Extension Rules

 Type: basic
 From: SMI, SPPI
 Description: SMIng must provide clear rules how one can extend SMIng
    modules without causing interoperability problems "over the wire".
 Motivation: SMIv2 and SPPI have extension rules.

4.1.36 Deprecate Use of IMPLIED Keyword

 Type: fix
 From: WG
 Description: The SMIng SNMP mapping must deprecate the use of the
    IMPLIED indexing schema.
 Motivation: IMPLIED is confusing and most people don't understand it.
    The solution (IMPLIED) is worse than the problem it is trying to
    solve and therefore for the sake of simplicity, the use of IMPLIED
    should be deprecated.

4.1.37 No Redundancy

 Type: fix
 From: NMRG
 Description: The SMIng language must avoid redundancy.
 Motivation: Remove any textual redundancy for things like table
    entries and SEQUENCE definitions, which only increase
    specifications without providing any value.

4.1.38 Compliance and Conformance

 Type: basic
 From: SMI, SPPI

Elliott, et al. Informational [Page 17] RFC 3216 SMIng Objectives December 2001

 Description: SMIng must provide a mechanism for compliance and
    conformance specifications for protocol-independent definitions as
    well as for protocol mappings.
 Motivation: This capability exists in SMIv2 and SPPI.  The NMRG
    proposal has the ability to express much of this information at
    the protocol-dependent layer.  Some compliance or conformance
    information may be protocol-independent, therefore there is also a
    need to be able to express this information protocol-independent
    part.

4.1.39 Allow Refinement of All Definitions in Conformance Statements

 Type: fix
 From: WG
 Description: SMIv2, RFC 2580, Section 3.1 says:
       The OBJECTS clause, which must be present, is used to specify
       each object contained in the conformance group.  Each of the
       specified objects must be defined in the same information
       module as the OBJECT-GROUP macro appears, and must have a MAX-
       ACCESS clause value of "accessible-for-notify", "read-only",
       "read-write", or "read-create".
    The last sentence forbids to put a not-accessible INDEX object
    into an OBJECT-GROUP.  Hence, you can not refine its syntax in a
    compliance definition.  For more details, see
    http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
 Motivation: This error should not be repeated in SMIng.

4.1.40 Categories

 Type: basic
 From: SPPI
 Description: SMIng must provide a mechanism to group definitions into
    subject categories.  Concrete instances may only exist in the
    scope of a given subject category or context.
 Motivation: To scope the categories to which a module applies.  In
    SPPI this is used to allow a division of labor between multiple
    client types.

Elliott, et al. Informational [Page 18] RFC 3216 SMIng Objectives December 2001

4.1.41 Core Language Keywords vs. Defined Identifiers

 Type: fix
 From: NMRG
 Description: In SMI and SPPI modules some language keywords (macros
    and a number of basetypes) have to be imported from different SMI
    language defining modules, e.g. OBJECT-TYPE, MODULE-IDENTITY,
    Integer32 must to be imported from SNMPv2-SMI and TEXTUAL-
    CONVENTION must be imported from SNMPv2-TC, if used.  MIB authors
    are continuously confused about these import rules.  In SMIng only
    defined identifiers must be imported.  All SMIng language keywords
    must be implicitly known and there must not be a need to import
    them from any module.
 Motivation: Reduce confusion.  Clarify the set of language keywords.

4.1.42 Instance Naming

 Type: align
 From: SMI, SPPI
 Description: Instance naming in SMIv2 and SPPI is different.  SMIng
    must align the instance naming (either in the protocol neutral
    model or the protocol mappings).
 Motivation: COPS-PR and SNMP have different instance identification
    schemes that must be handled.
 Notes: A solution requires to investigate how close the naming
    schemes dictated by the protocols are.  Perhaps it is feasible to
    have a single instance naming scheme in both SNMP and COPS-PR,
    even though the current SPPI and SMIv2 are different.

4.1.43 Length of Identifiers

 Type: fix
 From: NMRG
 Description: The allowed length of the various kinds of identifiers
    must be extended from the current `should not exceed 32' (maybe
    even from the `must not exceed 64') rule.
 Motivation: Reflect current practice of definitions.

Elliott, et al. Informational [Page 19] RFC 3216 SMIng Objectives December 2001

 Notes: The 32-rule was added back in the days where compilers could
    not deal with long identifiers.  This rule is continuously
    violated these days and it does not make sense to keep it.

4.1.44 Assign OIDs in the Protocol Mappings

 Type: new
 From: NMRG
 Description: SMIng must not assign OIDs to reusable definition of
    attributes, attribute groups, events, etc.  Instead, SNMP and
    COPS-PR mappings must assign OIDs to the mapped items.
 Motivation: Assignment of OIDs in protocol neutral definitions can
    complicate reuse.  OIDs of synonymous attributes are not the same
    in SMI and SPPI definitions.  MIBs and PIBs are already registered
    in different parts of the OID namespace.

4.2 Nice-to-Have Objectives

 This section represents the list of recommended objectives that would
 be nice to have.  However, these are not automatically thought of as
 accepted objectives as, for example, they may entail a non-trivial
 amount of work in underlying protocols to support or they may be
 regarded as less important than other contradicting objectives that
 are accepted.

4.2.1 Methods

 Type: new
 From: WG
 Description: SMIng should support a mechanism to define method
    signatures (parameters, return values, exception) that are
    implemented on agents.
 Motivation: Methods are needed to support the definition of
    operational interfaces such as found in [RFC2925] (ping,
    traceroute and lookup operations).  Also, the ability to define
    constructor/destructor interfaces could address issues such as
    encountered with SNMP's RowStatus solution.
 Notes: Is it possible to do methods without changing the underlying
    protocol?  There is agreement that methods are useful, but
    disagreement upon the impact - one end of the spectrum sees this
    as a documentation tool for existing SNMP capabilities, while the

Elliott, et al. Informational [Page 20] RFC 3216 SMIng Objectives December 2001

    other end sees this as a protocol update, moving forward, to
    natively support methods.  The proposal is to wait and see if this
    is practical to implement as a syntax that is useful and can map
    to the protocol.

4.2.2 Unions

 Type: new
 From: WG
 Description: SMIng should support a standard format for unions.
 Motivation: Allows an attribute to contain one of many types of
    values.  The lack of unions has also lead to relatively complex
    sparse table work-around in some DISMAN mid-level managers.
    Despite from discriminated unions (see Section 4.1.18), this kind
    of union has no accompanied explicit discriminator attribute that
    selects the union's type of value.
 Notes: The thought is that SNMP and COPS-PR can already support
    unions because they do not care about what data type goes with a
    particular OID.

4.2.3 Float Data Types

 Type: new
 From: WG, NMRG
 Description: SMIng should support the base data types Float32,
    Float64, Float128.
 Motivation: Missing base types can hurt later on, because they cannot
    be added without changing the language, even as an SMIng
    extension.  Lesson learned from the SMIv1/v2 debate about
    Counter64/Integer64/...
 Notes: There is no mention as to whether or not the underlying
    protocols will have to natively support float data types.  This is
    left to the mapping.  However, it seems imperative that the float
    data type needs to be added to the set of intrinsic types in the
    SMIng language at the creation of the language as it will be
    impossible to add them later without changing the language.

Elliott, et al. Informational [Page 21] RFC 3216 SMIng Objectives December 2001

4.2.4 Comments

 Type: fix
 From: NMRG
 Description: The syntax of comments should be well defined,
    unambiguous and intuitive to most people, e.g., the C++/Java `//'
    syntax.
 Motivation: ASN.1 Comments (and thus SMI and SPPI comments) have been
    a constant source of confusion.  People use arbitrary lengthy
    strings of dashes (`-----------') in the wrong assumption that
    this is always treated as a comment.  Some implementations try to
    accept these syntactically wrong constructs which even raises
    confusion.  We should get rid of this problem.
 Notes: If the SMIng working group adopts a C-like syntax, then the
    C++/Java single-line comment should be adopted as well.

4.2.5 Referencing Tagged Rows

 Type: align
 From: SPPI
 Description: PIB and MIB row attributes reference a group of entries
    in another table.  SPPI formalizes this by introducing PIB-TAG and
    PIB-REFERENCES clauses.  This functionality should be retained in
    SMIng.
 Motivation: SPPI formalizes tag references.  Some MIBs also use tag
    references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2 does
    not provide a formal notation.

4.2.6 Arrays

 Type: new
 From: WG
 Description: SMIng should allow the definition of a SEQUENCE OF
    attributes or attribute groups (Section 4.1.27).
 Motivation: The desire for the ability to have variable-length,
    multi-valued objects.

Elliott, et al. Informational [Page 22] RFC 3216 SMIng Objectives December 2001

 Notes: Some issues with arrays are still unclear.  As long as there
    are no concepts to solve the problems with access semantics (how
    to achieve atomic access to arbitrary-sized arrays) and their
    mappings to SNMP and COPS-PR protocol operations, arrays cannot be
    more than a nice to have objective.

4.2.7 Internationalization

 Type: new
 From: WG
 Description: Informational text (DESCRIPTION, REFERENCE, ...) should
    allow i18nized encoding, probably UTF-8.
 Motivation: There has been some demand for i18n in the past.  The BCP
    RFC 2277 demands for internationalization.
 Notes: Although English is the language of IETF documents, SMIng
    should allow other languages for private use.

4.2.8 Separate Data Modelling from Management Protocol Mapping

 Type: new
 From: NMRG
 Description: It should be possible to separate the domain specific
    data modelling work from the network management protocol specific
    work.
 Motivation: Today, working groups designing new protocols are forced
    to care about the design of SNMP MIBs and maybe COPR-PR PIBs to
    manage the new protocol.  This means that experts in a specific
    domain are faced with details of at least one foreign (network
    management) technology.  This leads to hard work and long revision
    processes.  It would be a win to separate the task of pure data
    modelling which can be done by the domain experts easily from the
    network management protocol specific mappings.  The mapping to
    SNMP and/or COPS-PR can be done (a) later separately and (b) by
    network management experts.  This required NM expertise no longer
    hinders the progress of the domain specific working groups.

Elliott, et al. Informational [Page 23] RFC 3216 SMIng Objectives December 2001

4.3 Rejected Objectives

 This section represents the list of objectives that were rejected
 during the discussion on the objectives.  Those objectives that have
 been rejected need not be addressed by SMIng.  This does not imply
 that they must not be addressed.

4.3.1 Incomplete Translations

 Type: basic
 From: WG
 Description: Reality sucks.  All information expressed in SMIng may
    not be directly translatable to a MIB or PIB construct, but all
    information should be able to be conveyed in documentation or via
    other mechanisms.
 Motivation: SMIng working group requires this to ease transition.
 Notes: The SMIng language itself cannot require what compilers do
    that translate SMIng into something else.  So this seems to fall
    out of the scope of the current working group charter.

4.3.2 Attribute Value Constraints

 Type: new
 From: WG
 Description: SMIng should provide mechanisms to formally specify
    constraints between values of multiple attributes.
 Motivation: Constraints on attribute values occur where one or more
    attributes may affect the value or range of values for another
    attribute.  One such relationship exists in IPsec, where the type
    of security algorithm determines the range of possible values for
    other attributes such as the corresponding key size.
 Notes: This objective as is has been rejected as too general, and
    therefore virtually impossible to implement.  However, constraints
    that are implicit with discriminated unions (Section 4.1.18),
    enumerated types (Section 4.1.17), pointer constraints (Section
    4.1.21)), etc., are accepted and these implicit constraints are
    mentioned in the respective objectives.

Elliott, et al. Informational [Page 24] RFC 3216 SMIng Objectives December 2001

4.3.3 Attribute Transaction Constraints

 Type: new
 From: WG
 Description: SMIng should provide a mechanism to formally express
    that certain sets of attributes can only be modified in
    combination.
 Motivation: COPS-PR always does operations on table rows in a single
    transaction.  There are SMIv2 attribute combinations that need to
    be modified together (such as InetAddressType, InetAddress).
 Notes: Alternative is to either use Methods (Section 4.2.1) or assume
    that all attributes in an attribute group (Section 4.1.27) are to
    be considered atomic.

4.3.4 Method Constraints

 Type: new
 From: WG
 Description: Method definitions should provide constraints on
    parameters.
 Motivation: None.
 Notes: Unless methods (Section 4.2.1) are done, there is no use for
    this.  Furthermore, this objective has not been motivated by any
    proponent.

4.3.5 Agent Capabilities

 Type: basic
 From: SMI
 Description: SMIng should provide mechanisms to describe agent
    implementations.
 Motivation: To permit manager to determine variations from the
    standard for an implementation.
 Notes: Agent capabilities should not be part of SMIng, but should
    instead be a separate capabilities table.

Elliott, et al. Informational [Page 25] RFC 3216 SMIng Objectives December 2001

4.3.6 Relationships

 Type: new
 From: NMRG, WG
 Description: Ability to formally depict existence dependency, value
    dependency, aggregation, containment, and other relationships
    between attributes or attribute groups.
 Motivation: Helps humans to understand the conceptual model of a
    module.  Helps implementers of MIB compilers to generate more
    `intelligent' code.
 Notes: This objective was deemed too general to be useful and instead
    the individual types of relationship objectives (e.g., pointers,
    inheritance, containment, etc.)  are evaluated on a case-by-case
    basis with the specific relationships deemed useful being included
    as accepted objectives.

4.3.7 Procedures

 Type: new
 From: WG
 Description: SMIng should support a mechanism to formally define
    procedures that are used by managers when interacting with an
    agent.
 Motivation: None.
 Notes: This objective has not been motivated by any proponent.

4.3.8 Associations

 Type: new
 From: WG
 Description: SMIng should provide mechanisms to explicitly specify
    associations.
 Motivation: None.
 Notes: This objective has not been motivated by any proponent.

Elliott, et al. Informational [Page 26] RFC 3216 SMIng Objectives December 2001

4.3.9 Association Cardinalities

 Type: new
 From: WG
 Description: Cardinalities between associations should be formally
    defined.
 Motivation: If you have an association between attribute groups A and
    B, the cardinality of A indicates how many instances of A may be
    associated with a single instance of B.  Our discussions in
    Minneapolis indicated that we want to convey "how many" instances
    are associated in order to define the best mapping algorithm -
    whether a new table, a single pointer, etc.  For example, do we
    use RowPointer or an integer index into another table? Do we map
    to a table that holds instances of the association/relationship
    itself?
 Notes: Without associations (Section 4.3.8), this has no use.

4.3.10 Categories of Modules

 Type: new
 From: WG
 Description: The SMIng documents should give clear guidance on which
    kind of information (with respect to generality, type/attribute
    group/extension/..) should be put in which kind of a module.
    E.g., in SMIv2 we don't like to import Utf8String from SYSAPPL-
    MIB, but we also do not like to introduce a redundant definition.
    A module review process should probably be described that ensures
    that generally useful definitions do not go into device or service
    specific modules.
 Motivation: Bad experience with SMIv2.
 Notes: It is not clear how this can be done with the language to be
    created by SMIng WG.

4.3.11 Mapping Modules to Files

 Type: new
 From: NMRG

Elliott, et al. Informational [Page 27] RFC 3216 SMIng Objectives December 2001

 Description: There should be a clear statement how SMIng modules are
    mapped to files (1:1, n:1?) and how files should be named (by
    module name in case of 1:1 mapping?).
 Motivation: SMI implementations show up a variety of filename
    extensions (.txt, .smi, .my, none).  Some expect all modules in a
    single file, others don't.  This makes it more difficult to
    exchange modules.
 Notes: This is just an implementation detail and is best left to a
    BCP and not made a part of the language definition.

4.3.12 Simple Grammar

 Type: new
 From: NMRG
 Description: The grammar of the language should be as simple as
    possible.  It should be free of exception rules.  A measurement of
    simplicity is shortness of the ABNF grammar.
 Motivation: Ease of implementation.  Ease of learning/understanding.
 Notes: This seems like an obvious objective, however shortness of the
    ABNF grammar is not necessarily a reflection of the simplicity of
    the grammar.

4.3.13 Place of Module Information

 Type: fix
 From: NMRG
 Description: Module specific information (organization, contact,
    description, revision information) should be bound to the module
    itself and not to an artificial node (like SMIv2 MODULE-IDENTITY).
 Motivation: Simplicity and design cleanup.
 Notes: This does not seem to be a problem with the current SMI.
    Although simplification is a good thing, this detail is not
    considered an objective.

Elliott, et al. Informational [Page 28] RFC 3216 SMIng Objectives December 2001

4.3.14 Module Namespace

 Type: new
 From: WG
 Description: Currently the namespace of modules is flat and there is
    no structure in module naming causing the potential risk of name
    clashes.  Possible solutions:
  • Assume module names are globally unique (just as SMIv1/v2),

just give some recommendations on module names.

  • Force all organizations, WGs and vendors to apply a name prefix

(e.g. CISCO-GAGA-MIB, IETF-DISMAN-SCRIPT-MIB?).

  • Force enterprises to apply a prefix based on the enterprise

number (e.g. ENT2021-SOME-MIB).

  • Put module names in a hierarchical domain based namespace (e.g.

DISMAN-SCRIPT-MIB.ietf.org).

 Motivation: Reduce risk of module name clashes.
 Notes: Some aspects of this objective overlap with other objectives
    (namespace control (Section 4.1.9)) and other aspects were thought
    best left to a BCP.

4.3.15 Hyphens in Identifiers

 Type: fix
 From: NMRG
 Description: There has been some confusion whether hyphens are
    allowed in SMIv2 identifiers: Module names are allowed to contain
    hyphens.  Node identifiers usually are not.  But for example
    `mib-2' is a frequently used identifier that contains a hyphen due
    to its SMIv1 origin, when hyphen were not disallowed.  Similarly,
    a number of named numbers of enumeration types contain hyphens
    violating an SMIv2 rule.
    SMIng should simply allow hyphens in all kinds of identifiers.  No
    exceptions.
 Motivation: Reduce confusion and exceptions.  Requires, however, that
    implementation mappings properly quote hyphens where appropriate.

Elliott, et al. Informational [Page 29] RFC 3216 SMIng Objectives December 2001

 Notes: This nit-picking is not worth to be subject to the discussion
    on objectives.  However, SMIng should care about the fact that
    compilers have to map SMIng to programming languages where a
    hyphen is a minus and thus not allowed in identifiers.

5. Security Considerations

 This document defines objectives for a language with which to write
 and read descriptions of management information.  The language itself
 has no security impact on the Internet.

6. Acknowledgements

 Thanks to Dave Durham, whose work on the original NIM (Network
 Information Model) draft was used in generating this document.
 Thanks to Andrea Westerinen for her contributions on the original NIM
 requirements and SMIng objectives drafts.

7. References

 [1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
     Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
 [2] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser, "Protocol
     Operations for Version 2 of the Simple Network Management
     Protocol (SNMPv2)", RFC 1905, January 1996.
 [3] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
     Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS
     Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
 [4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
     M. and S. Waldbusser, "Structure of Management Information
     Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
     M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
     RFC 2579, April 1999.
 [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
     Statements for SMIv2", STD 58, RFC 2580, April 1999.
 [7] 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.

Elliott, et al. Informational [Page 30] RFC 3216 SMIng Objectives December 2001

8. Authors' Addresses

 Chris Elliott
 Cisco Systems
 7025 Kit Creek Road
 Research Triangle Park, NC 27709
 USA
 EMail: chelliot@cisco.com
 David Harrington
 Enterasys Networks
 35 Industrial Way
 P.O. Box 5005
 Rochester, NH 03866-5005
 USA
 EMail: dbh@enterasys.com
 Jamie Jason
 Intel Corporation
 MS JF3-206
 2111 NE 25th Ave.
 Hillsboro, OR 97124
 USA
 EMail: jamie.jason@intel.com
 Juergen Schoenwaelder
 TU Braunschweig
 Muehlenpfordtstr. 23
 38106 Braunschweig
 Germany
 EMail: schoenw@ibr.cs.tu-bs.de
 URI:   http://www.ibr.cs.tu-bs.de/

Elliott, et al. Informational [Page 31] RFC 3216 SMIng Objectives December 2001

 Frank Strauss
 TU Braunschweig
 Muehlenpfordtstr. 23
 38106 Braunschweig
 Germany
 EMail: strauss@ibr.cs.tu-bs.de
 URI:   http://www.ibr.cs.tu-bs.de/
 Walter Weiss
 Ellacoya Networks
 7 Henry Clay Dr.
 Merrimack, NH. 03054
 USA
 EMail: wweiss@ellacoya.com

Elliott, et al. Informational [Page 32] RFC 3216 SMIng Objectives December 2001

9. Full Copyright Statement

 Copyright (C) The Internet Society (2001).  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 assigns.
 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
 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.

Elliott, et al. Informational [Page 33]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3216.txt · Last modified: 2001/12/10 18:33 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki