rfc3216.txt

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

   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: [e-mail]


   David Harrington
   Enterasys Networks
   35 Industrial Way
   P.O. Box 5005
   Rochester, NH 03866-5005
   USA

   EMail: [e-mail]


   Jamie Jason
   Intel Corporation
   MS JF3-206
   2111 NE 25th Ave.
   Hillsboro, OR 97124
   USA

   EMail: [e-mail]


   Juergen Schoenwaelder
   TU Braunschweig
   Muehlenpfordtstr. 23
   38106 Braunschweig
   Germany

   EMail: [e-mail]
   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: [e-mail]
   URI:   http://www.ibr.cs.tu-bs.de/


   Walter Weiss
   Ellacoya Networks
   7 Henry Clay Dr.
   Merrimack, NH. 03054
   USA

   EMail: [e-mail]


































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]