rfc3216.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,852 行 · 第 1/4 页

   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.