rfc3410.txt

开发snmp的开发包有两个开放的SNMP开发库

   collectively referred to as "SMIv1".  Note that due to the initial
   requirement that the SMI be protocol-independent, the first two SMI
   documents do not provide a means for defining event notifications
   (traps).  Instead, the SNMP protocol document defines a few
   standardized event notifications (generic traps) and provides a means
   for additional event notifications to be defined.  The last document
   specifies a straight-forward approach towards defining event
   notifications used with the SNMPv1 protocol.  At the time that it was
   written, use of traps in the Internet-Standard network management
   framework was controversial.  As such, RFC 1215 was put forward with
   the status of "Informational", which was never updated because it was
   believed that the second version of the SNMP Framework would replace
   the first version.

3.2.  Management Information

   The data definition language described in the first two documents was
   first used to define the now-historic MIB-I as specified in RFC 1066
   [8], and was subsequently used to define MIB-II as specified in RFC
   1213 [6].

   Later, after the publication of MIB-II, a different approach to the
   management information definition was taken from the earlier approach
   of having a single committee staffed by generalists work on a single
   document to define the Internet-Standard MIB.  Rather, many mini-MIB
   documents were produced in a parallel and distributed fashion by
   groups chartered to produce a specification for a focused portion of
   the Internet-Standard MIB and staffed by personnel with expertise in
   those particular areas ranging from various aspects of network
   management, to system management, and application management.



Case, et. al.                Informational                      [Page 6]

RFC 3410           Applicability Statements for SNMP       December 2002


3.3.  Protocol Operations

   The third document, STD 15 [5], describes the SNMPv1 protocol
   operations performed by protocol data units (PDUs) on lists of
   variable bindings and describes the format of SNMPv1 messages.  The
   operators defined by SNMPv1 are:  get, get-next, get-response, set-
   request, and trap.  Typical layering of SNMP on a connectionless
   transport service is also defined.

3.4.  SNMPv1 Security and Administration

   STD 15 [5] also describes an approach to security and administration.
   Many of these concepts are carried forward and some, particularly
   security, are extended by the SNMPv3 Framework.

   The SNMPv1 Framework describes the encapsulation of SNMPv1 PDUs in
   SNMP messages between SNMP entities and distinguishes between
   application entities and protocol entities.  In SNMPv3, these are
   renamed applications and engines, respectively.

   The SNMPv1 Framework also introduces the concept of an authentication
   service supporting one or more authentication schemes.  In addition
   to authentication, SNMPv3 defines the additional security capability
   referred to as privacy.  (Note: some literature from the security
   community would describe SNMPv3 security capabilities as providing
   data integrity, source authenticity, and confidentiality.)  The
   modular nature of the SNMPv3 Framework permits both changes and
   additions to the security capabilities.

   Finally, the SNMPv1 Framework introduces access control based on a
   concept called an SNMP MIB view.  The SNMPv3 Framework specifies a
   fundamentally similar concept called view-based access control.  With
   this capability, SNMPv3 provides the means for controlling access to
   information on managed devices.

   However, while the SNMPv1 Framework anticipated the definition of
   multiple authentication schemes, it did not define any such schemes
   other than a trivial authentication scheme based on community
   strings.  This was a known fundamental weakness in the SNMPv1
   Framework but it was thought at that time that the definition of
   commercial grade security might be contentious in its design and
   difficult to get approved because "security" means many different
   things to different people.  To that end, and because some users do
   not require strong authentication, the SNMPv1 architected an
   authentication service as a separate block to be defined "later" and
   the SNMPv3 Framework provides an architecture for use within that
   block as well as a definition for its subsystems.




Case, et. al.                Informational                      [Page 7]

RFC 3410           Applicability Statements for SNMP       December 2002


4.  The SNMPv2 Management Framework

   The SNMPv2 Management Framework is described in [8-13] and
   coexistence and transition issues relating to SNMPv1 and SNMPv2 are
   discussed in [15].

   SNMPv2 provides several advantages over SNMPv1, including:

   *  expanded data types (e.g., 64 bit counter)

   *  improved efficiency and performance (get-bulk operator)

   *  confirmed event notification (inform operator)

   *  richer error handling (errors and exceptions)

   *  improved sets, especially row creation and deletion

   *  fine tuning of the data definition language

   However, the SNMPv2 Framework, as described in these documents, is
   incomplete in that it does not meet the original design goals of the
   SNMPv2 project.  The unmet goals included provision of security and
   administration delivering so-called "commercial grade" security with:

   *  authentication:  origin identification, message integrity, and
      some aspects of replay protection;

   *  privacy:  confidentiality;

   *  authorization and access control; and

   *  suitable remote configuration and administration capabilities for
      these features.

   The SNMPv3 Management Framework, as described in this document and
   the companion documents, addresses these significant deficiencies.

5.  The SNMPv3 Working Group

   This document, and its companion documents, were produced by the
   SNMPv3 Working Group of the Internet Engineering Task Force (IETF).
   The SNMPv3 Working Group was chartered to prepare recommendations for
   the next generation of SNMP.  The goal of the Working Group was to
   produce the necessary set of documents that provide a single standard
   for the next generation of core SNMP functions.  The single, most
   critical need in the next generation is a definition of security and
   administration that makes SNMP-based management transactions secure



Case, et. al.                Informational                      [Page 8]

RFC 3410           Applicability Statements for SNMP       December 2002


   in a way which is useful for users who wish to use SNMPv3 to manage
   networks, the systems that make up those networks, and the
   applications which reside on those systems, including manager-to-
   agent, agent-to-manager, and manager-to-manager transactions.

   In the several years prior to the chartering of the Working Group,
   there were a number of activities aimed at incorporating security and
   other improvements to SNMP.  These efforts included:

   *  "SNMP Security" circa 1991-1992 (RFC 1351 - RFC 1353),

   *  "SMP" circa 1992-1993, and

   *  "The Party-based SNMPv2" (sometimes called "SNMPv2p") circa
      1993-1995 (RFC 1441 - RFC 1452).

   Each of these efforts incorporated commercial grade, industrial
   strength security including authentication, privacy, authorization,
   view-based access control, and administration, including remote
   configuration.

   These efforts fed the development of the SNMPv2 Management Framework
   as described in RFCs 1902 - 1908.  However, the Framework described
   in those RFCs had no standards-based security and administrative
   framework of its own; rather, it was associated with multiple
   security and administrative frameworks, including:

   *  "The Community-based SNMPv2" (SNMPv2c) as described in RFC 1901
      [16],

   *  "SNMPv2u" as described in RFCs 1909 and 1910, and

   *  "SNMPv2*."

   SNMPv2c had the most support within the IETF but had no security and
   administration whereas both SNMPv2u and SNMPv2* had security but
   lacked a consensus of support within the IETF.

   The SNMPv3 Working Group was chartered to produce a single set of
   specifications for the next generation of SNMP, based upon a
   convergence of the concepts and technical elements of SNMPv2u and
   SNMPv2*, as was suggested by an advisory team which was formed to
   provide a single recommended approach for SNMP evolution.








Case, et. al.                Informational                      [Page 9]

RFC 3410           Applicability Statements for SNMP       December 2002


   In so doing, the Working Group charter defined the following
   objectives:

   *  accommodate the wide range of operational environments with
      differing management demands;

   *  facilitate the need to transition from previous, multiple
      protocols to SNMPv3;

   *  facilitate the ease of setup and maintenance activities.

   In the initial work of the SNMPv3 Working Group, the group focused on
   security and administration, including:

   *  authentication and privacy,

   *  authorization and view-based access control, and

   *  standards-based remote configuration of the above.

   The SNMPv3 Working Group did not "reinvent the wheel", but reused the
   SNMPv2 Draft Standard documents, i.e., RFCs 1902 through 1908 for
   those portions of the design that were outside the focused scope.

   Rather, the primary contributors to the SNMPv3 Working Group, and the
   Working Group in general, devoted their considerable efforts to
   addressing the missing link -- security and administration -- and in
   the process made invaluable contributions to the state-of-the-art of
   management.

   They produced a design based on a modular architecture with
   evolutionary capabilities with emphasis on layering.  As a result,
   SNMPv3 can be thought of as SNMPv2 with additional security and
   administration capabilities.

   In doing so, the Working Group achieved the goal of producing a
   single specification which has not only the endorsement of the IETF
   but also has security and administration.

6.  SNMPv3 Framework Module Specifications

   The specification of the SNMPv3 Management Framework is partitioned
   in a modular fashion among several documents.  It is the intention of
   the SNMPv3 Working Group that, with proper care, any or all of the
   individual documents can be revised, upgraded, or replaced as
   requirements change, new understandings are obtained, and new
   technologies become available.




Case, et. al.                Informational                     [Page 10]

RFC 3410           Applicability Statements for SNMP       December 2002


   Whenever feasible, the initial document set which defines the SNMPv3
   Management Framework leverages prior investments defining and
   implementing the SNMPv2 Management Framework by incorporating by
   reference each of the specifications of the SNMPv2 Management
   Framework.

   The SNMPv3 Framework augments those specifications with
   specifications for security and administration for SNMPv3.

   The documents which specify the SNMPv3 Management Framework follow
   the same architecture as those of the prior versions and can be
   organized for expository purposes into four main categories as
   follows:

   *  the data definition language,

   *  Management Information Base (MIB) modules,

   *  protocol operations, and

   *  security and administration.

   The first three sets of documents are incorporated from SNMPv2.  The
   documents in the fourth set are new to SNMPv3, but, as described
   previously, build on significant prior related works.

6.1.  Data Definition Language

   The specifications of the data definition language include STD 58,
   RFC 2578, "Structure of Management Information Version 2 (SMIv2)"
   [17], and related specifications.  These documents are updates of
   RFCs 1902 - 1904 [9-11] which have evolved independently from the
   other parts of the framework and were republished with minor
   editorial changes as STD 58, RFCs 2578 - 2580 [17-19] when promoted
   from Draft Standard to full Standard.

   The Structure of Management Information (SMIv2) defines fundamental
   data types, an object model, and the rules for writing and revising
   MIB modules.  Related specifications include STD 58, RFCs 2579, 2580.

   STD 58, RFC 2579, "Textual Conventions for SMIv2" [18], defines an
   initial set of shorthand abbreviations which are available for use