rfc3410.txt

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

   within all MIB modules for the convenience of human readers and
   writers.







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


   STD 58, RFC 2580, "Conformance Statements for SMIv2" [19], defines
   the format for compliance statements which are used for describing
   requirements for agent implementations and capability statements
   which can be used to document the characteristics of particular
   implementations.

   The term "SMIv2" is somewhat ambiguous because users of the term
   intend it to have at least two different meanings.  Sometimes the
   term is used to refer the entire data definition language of STD 58,
   defined collectively in RFCs 2578 - 2580 whereas at other times it is
   used to refer to only the portion of the data definition language
   defined in RFC 2578.  This ambiguity is unfortunate but is rarely a
   significant problem in practice.

6.2.  MIB Modules

   MIB modules usually contain object definitions, may contain
   definitions of event notifications, and sometimes include compliance
   statements specified in terms of appropriate object and event
   notification groups.  As such, MIB modules define the management
   information maintained by the instrumentation in managed nodes, made
   remotely accessible by management agents, conveyed by the management
   protocol, and manipulated by management applications.

   MIB modules are defined according to the rules defined in the
   documents which specify the data definition language, principally the
   SMI as supplemented by the related specifications.

   There is a large and growing number of standards-track MIB modules,
   as defined in the periodically updated "Internet Official Protocol
   Standards" list [20].  As of this writing, there are more than 100
   standards-track MIB modules with a total number of defined objects
   exceeding 10,000.  In addition, there is an even larger and growing
   number of enterprise-specific MIB modules defined unilaterally by
   various vendors, research groups, consortia, and the like resulting
   in an unknown and virtually uncountable number of defined objects.

   In general, management information defined in any MIB module,
   regardless of the version of the data definition language used, can
   be used with any version of the protocol.  For example, MIB modules
   defined in terms of the SNMPv1 SMI (SMIv1) are compatible with the
   SNMPv3 Management Framework and can be conveyed by the protocols
   specified therein.  Furthermore, MIB modules defined in terms of the
   SNMPv2 SMI (SMIv2) are compatible with SNMPv1 protocol operations and
   can be conveyed by it.  However, there is one noteworthy exception:
   the Counter64 datatype which can be defined in a MIB module defined





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


   in SMIv2 format but which cannot be conveyed by an SNMPv1 protocol
   engine.  It can be conveyed by an SNMPv2 or an SNMPv3 engine, but
   cannot be conveyed by an engine which exclusively supports SNMPv1.

6.3.  Protocol Operations and Transport Mappings

   The specifications for the protocol operations and transport mappings
   of the SNMPv3 Framework are incorporated by reference to the two
   SNMPv2 Framework documents which have subsequently been updated.

   The specification for protocol operations is found in STD 62, RFC
   3416, "Version 2 of the Protocol Operations for the Simple Network
   Management Protocol (SNMP)" [21].

   The SNMPv3 Framework is designed to allow various portions of the
   architecture to evolve independently.  For example, it might be
   possible for a new specification of protocol operations to be defined
   within the Framework to allow for additional protocol operations.

   The specification of transport mappings is found in STD 62, RFC 3417,
   "Transport Mappings for the Simple Network Management Protocol
   (SNMP)" [22].

6.4.  SNMPv3 Security and Administration

   The document series pertaining to SNMPv3 Security and Administration
   defined by the SNMPv3 Working Group consists of seven documents at
   this time:

      RFC 3410, "Introduction and Applicability Statements for the
      Internet-Standard Management Framework", which is this document.

      STD 62, RFC 3411, "An Architecture for Describing Simple Network
      Management Protocol (SNMP) Management Frameworks" [23], describes
      the overall architecture with special emphasis on the architecture
      for security and administration.

      STD 62, RFC 3412, "Message Processing and Dispatching for the
      Simple Network Management Protocol (SNMP)" [24], describes the
      possibility of multiple message processing models and the
      dispatcher portion that can be a part of an SNMP protocol engine.

      STD 62, RFC 3413, "Simple Network Management Protocol (SNMP)
      Applications" [25], describes the five initial types of
      applications that can be associated with an SNMPv3 engine and
      their elements of procedure.





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


      STD 62, RFC 3414, "User-Based Security Model (USM) for Version 3
      of the Simple Network Management Protocol (SNMPv3)" [26],
      describes the threats against which protection is provided, as
      well as the mechanisms, protocols, and supporting data used to
      provide SNMP message-level security with the user-based security
      model.

      STD 62, RFC 3415, "View-based Access Control Model (VCAM) for the
      Simple Network Management Protocol (SNMP)" [27], describes how
      view-based access control can be applied within command responder
      and notification originator applications.

      RFC 2576, "SNMPv3 Coexistence and Transition" [28], describes
      coexistence between the SNMPv3 Management Framework, the SNMPv2
      Management Framework, and the original SNMPv1 Management
      Framework, and is in the process of being updated by a Work in
      Progress.

7.  Document Summaries

   The following sections provide brief summaries of each document with
   slightly more detail than is provided in the overviews above.

7.1.  Structure of Management Information

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB).  Collections of related objects are defined
   in MIB modules.  These modules are written in the SNMP data
   definition language, which evolved from an adapted subset of OSI's
   Abstract Syntax Notation One (ASN.1) [29] language.  STD 58, RFCs
   2578, 2579, 2580, collectively define the data definition language,
   specify the base data types for objects, specify a core set of
   short-hand specifications for data types called textual conventions,
   and specify a few administrative assignments of object identifier
   (OID) values.

   The SMI is divided into three parts:  module definitions, object
   definitions, and notification definitions.

   (1) Module definitions are used when describing information modules.
       An ASN.1 macro, MODULE-IDENTITY, is used to convey concisely the
       semantics of an information module.

   (2) Object definitions are used when describing managed objects.  An
       ASN.1 macro, OBJECT-TYPE, is used to convey concisely the syntax
       and semantics of a managed object.




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


   (3) Notification definitions are used when describing unsolicited
       transmissions of management information.  An ASN.1 macro,
       NOTIFICATION-TYPE, is used to convey concisely the syntax and
       semantics of a notification.

   As noted earlier, the term "SMIv2" is somewhat ambiguous because
   users of the term intend it to have at least two different meanings.
   Sometimes the term is used to refer to the entire data definition
   language of STD 58, defined collectively in RFCs 2578 - 2580 whereas
   at other times it is used to refer to only the portion of the data
   definition language defined in RFC 2578.  This ambiguity is
   unfortunate but is rarely a significant problem in practice.

7.1.1.  Base SMI Specification

   STD 58, RFC 2578 specifies the base data types for the data
   definition language, which include: Integer32, enumerated integers,
   Unsigned32, Gauge32, Counter32, Counter64, TimeTicks, INTEGER, OCTET
   STRING, OBJECT IDENTIFIER, IpAddress, Opaque, and BITS.  It also
   assigns values to several object identifiers.  STD 58, RFC 2578
   further defines the following constructs of the data definition
   language:

   *  IMPORTS to allow the specification of items that are used in a MIB
      module, but defined in another MIB module.

   *  MODULE-IDENTITY to specify for a MIB module a description and
      administrative information such as contact and revision history.

   *  OBJECT-IDENTITY and OID value assignments to specify an OID value.

   *  OBJECT-TYPE to specify the data type, status, and the semantics of
      managed objects.

   *  SEQUENCE type assignment to list the columnar objects in a table.

   *  NOTIFICATION-TYPE construct to specify an event notification.

7.1.2.  Textual Conventions

   When designing a MIB module, it is often useful to specify, in a
   short-hand way, the semantics for a set of objects with similar
   behavior.  This is done by defining a new data type using a base data
   type specified in the SMI.  Each new type has a different name, and
   specifies a base type with more restrictive semantics.  These newly
   defined types are termed textual conventions, and are used for the
   convenience of humans reading a MIB module and potentially by
   "intelligent" management applications.  It is the purpose of STD 58,



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


   RFC 2579, Textual Conventions for SMIv2 [18], to define the
   construct, TEXTUAL-CONVENTION, of the data definition language used
   to define such new types and to specify an initial set of textual
   conventions available to all MIB modules.

7.1.3.  Conformance Statements

   It may be useful to define the acceptable lower-bounds of
   implementation, along with the actual level of implementation
   achieved.  It is the purpose of STD 58, RFC 2580, Conformance
   Statements for SMIv2 [19], to define the constructs of the data
   definition language used for these purposes.  There are two kinds of
   constructs:

   (1) Compliance statements are used when describing requirements for
       agents with respect to object and event notification definitions.
       The MODULE-COMPLIANCE construct is used to convey concisely such
       requirements.

   (2) Capability statements are used when describing capabilities of
       agents with respect to object and event notification definitions.
       The AGENT-CAPABILITIES construct is used to convey concisely such
       capabilities.

   Finally, collections of related objects and collections of related
   event notifications are grouped together to form a unit of
   conformance.  The OBJECT-GROUP construct is used to convey concisely
   the objects in and the semantics of an object group.  The
   NOTIFICATION-GROUP construct is used to convey concisely the event
   notifications in and the semantics of an event notification group.

7.2.  Protocol Operations

   The management protocol provides for the exchange of messages which
   convey management information between the agents and the management
   stations.  The form of these messages is a message "wrapper" which
   encapsulates a Protocol Data Unit (PDU).

   It is the purpose of STD 62, RFC 3416, "Version 2 of the Protocol
   Operations for the Simple Network Management Protocol (SNMP)" [21],
   to define the operations of the protocol with respect to the sending
   and receiving of the PDUs.

7.3.  Transport Mappings

   SNMP messages may be used over a variety of protocol suites.  It is
   the purpose of STD 62, RFC 3417, "Transport Mappings for the Simple
   Network Management Protocol (SNMP)" [22], to define how SNMP messages



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


   map onto an initial set of transport domains.  Other mappings may be
   defined in the future.

   Although several mappings are defined, the mapping onto UDP is the
   preferred mapping.  As such, to provide for the greatest level of
   interoperability, systems which choose to deploy other mappings
   should also provide for proxy service to the UDP mapping.

7.4.  Protocol Instrumentation