rfc3216.txt

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

   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