rfc2571.txt

中、英文RFC文档大全打包下载完全版 .

   |  +-----------------| securityName |---+  |
   |  | Security Model  |              |   |  |
   |  |                 +--------------+   |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  |                         v          |  |
   |  |  +------------------------------+  |  |
   |  |  |                              |  |  |
   |  |  | Model                        |  |  |
   |  |  | Dependent                    |  |  |
   |  |  | Security ID                  |  |  |
   |  |  |                              |  |  |
   |  |  +------------------------------+  |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  +-------------------------|----------+  |
   |                            |             |
   |                            |             |
   +----------------------------|-------------+
                                |
                                v
                             network

3.2.1.  Principal

   A principal is the "who" on whose behalf services are provided or
   processing takes place.

   A principal can be, among other things, an individual acting in a
   particular role; a set of individuals, with each acting in a
   particular role; an application or a set of applications; and
   combinations thereof.

3.2.2.  securityName

   A securityName is a human readable string representing a principal.
   It has a model-independent format, and can be used outside a
   particular Security Model.



SNMPv3 Working Group        Standards Track                    [Page 23]

RFC 2571           Architecture for SNMP Frameworks             April 1999


3.2.3.  Model-dependent security ID

   A model-dependent security ID is the model-specific representation of
   a securityName within a particular Security Model.

   Model-dependent security IDs may or may not be human readable, and
   have a model-dependent syntax. Examples include community names, and
   user names.

   The transformation of model-dependent security IDs into securityNames
   and vice versa is the responsibility of the relevant Security Model.








































SNMPv3 Working Group        Standards Track                    [Page 24]

RFC 2571           Architecture for SNMP Frameworks             April 1999


3.3.  The Naming of Management Information

   Management information resides at an SNMP entity where a Command
   Responder Application has local access to potentially multiple
   contexts.  This application uses a contextEngineID equal to the
   snmpEngineID of its associated SNMP engine.

   +-----------------------------------------------------------------+
   |  SNMP entity (identified by snmpEngineID, example: abcd)        |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  | SNMP engine (identified by snmpEngineID)                   | |
   |  |                                                            | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  | |             | |            | |           | |           | | |
   |  | | Dispatcher  | | Message    | | Security  | | Access    | | |
   |  | |             | | Processing | | Subsystem | | Control   | | |
   |  | |             | | Subsystem  | |           | | Subsystem | | |
   |  | |             | |            | |           | |           | | |
   |  | +-------------+ +------------+ +-----------+ +-----------+ | |
   |  |                                                            | |
   |  +------------------------------------------------------------+ |
   |                                                                 |
   |  +------------------------------------------------------------+ |
   |  |  Command Responder Application                             | |
   |  |  (contextEngineID, example: abcd)                          | |
   |  |                                                            | |
   |  |  example contextNames:                                     | |
   |  |                                                            | |
   |  |  "bridge1"          "bridge2"            "" (default)      | |
   |  |  ---------          ---------            ------------      | |
   |  |      |                  |                   |              | |
   |  +------|------------------|-------------------|--------------+ |
   |         |                  |                   |                |
   |  +------|------------------|-------------------|--------------+ |
   |  |  MIB | instrumentation  |                   |              | |
   |  |  +---v------------+ +---v------------+ +----v-----------+  | |
   |  |  | context        | | context        | | context        |  | |
   |  |  |                | |                | |                |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  | | bridge MIB | | | | bridge MIB | | | | some  MIB  | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | | | other MIB  | |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   +-----------------------------------------------------------------+



SNMPv3 Working Group        Standards Track                    [Page 25]

RFC 2571           Architecture for SNMP Frameworks             April 1999


3.3.1.  An SNMP Context

   An SNMP context, or just "context" for short, is a collection of
   management information accessible by an SNMP entity. An item of
   management information may exist in more than one context. An SNMP
   entity potentially has access to many contexts.

   Typically, there are many instances of each managed object type
   within a management domain. For simplicity, the method for
   identifying instances specified by the MIB module does not allow each
   instance to be distinguished amongst the set of all instances within
   a management domain; rather, it allows each instance to be identified
   only within some scope or "context", where there are multiple such
   contexts within the management domain.  Often, a context is a
   physical device, or perhaps, a logical device, although a context can
   also encompass multiple devices, or a subset of a single device, or
   even a subset of multiple devices, but a context is always defined as
   a subset of a single SNMP entity.  Thus, in order to identify an
   individual item of management information within the management
   domain, its contextName and contextEngineID must be identified in
   addition to its object type and its instance.

   For example, the managed object type ifDescr [RFC2233], is defined as
   the description of a network interface.  To identify the description
   of device-X's first network interface, four pieces of information are
   needed: the snmpEngineID of the SNMP entity which provides access to
   the management information at device-X, the contextName (device-X),
   the managed object type (ifDescr), and the instance ("1").

   Each context has (at least) one unique identification within the
   management domain. The same item of management information can exist
   in multiple contexts. An item of management information may have
   multiple unique identifications.  This occurs when an item of
   management information exists in multiple contexts, and this also
   occurs when a context has multiple unique identifications.

   The combination of a contextEngineID and a contextName unambiguously
   identifies a context within an administrative domain; note that there
   may be multiple unique combinations of contextEngineID and
   contextName that unambiguously identify the same context.

3.3.2.  contextEngineID

   Within an administrative domain, a contextEngineID uniquely
   identifies an SNMP entity that may realize an instance of a context
   with a particular contextName.





SNMPv3 Working Group        Standards Track                    [Page 26]

RFC 2571           Architecture for SNMP Frameworks             April 1999


3.3.3.  contextName

   A contextName is used to name a context. Each contextName MUST be
   unique within an SNMP entity.

3.3.4.  scopedPDU

   A scopedPDU is a block of data containing a contextEngineID, a
   contextName, and a PDU.

   The PDU is an SNMP Protocol Data Unit containing information named in
   the context which is unambiguously identified within an
   administrative domain by the combination of the contextEngineID and
   the contextName. See, for example, RFC1905 for more information about
   SNMP PDUs.

3.4.  Other Constructs

3.4.1.  maxSizeResponseScopedPDU

   The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that
   a PDU's sender would be willing to accept.  Note that the size of a
   scopedPDU does not include the size of the SNMP message header.

3.4.2.  Local Configuration Datastore

   The subsystems, models, and applications within an SNMP entity may
   need to retain their own sets of configuration information.

   Portions of the configuration information may be accessible as
   managed objects.

   The collection of these sets of information is referred to as an
   entity's Local Configuration Datastore (LCD).

3.4.3.  securityLevel

   This architecture recognizes three levels of security:

      -  without authentication and without privacy (noAuthNoPriv)

      -  with authentication but without privacy (authNoPriv)

      -  with authentication and with privacy (authPriv)

   These three values are ordered such that noAuthNoPriv is less than
   authNoPriv and authNoPriv is less than authPriv.




SNMPv3 Working Group        Standards Track                    [Page 27]

RFC 2571           Architecture for SNMP Frameworks             April 1999


   Every message has an associated securityLevel. All Subsystems
   (Message Processing, Security, Access Control) and applications are
   REQUIRED to either supply a value of securityLevel or to abide by the
   supplied value of securityLevel while processing the message and its
   contents.

4.  Abstract Service Interfaces

   Abstract service interfaces have been defined to describe the
   conceptual interfaces between the various subsystems within an SNMP
   entity.  The abstract service interfaces are intended to help clarify
   the externally observable behavior of SNMP entities, and are not
   intended to constrain the structure or organization of
   implementations in any way.  Most specifically, they should not be
   interpreted as APIs or as requirements statements for APIs.

   These abstract service interfaces are defined by a set of primitives
   that define the services provided and the abstract data elements that
   are to be passed when the services are invoked.  This section lists
   the primitives that have been defined for the various subsystems.

4.1.  Dispatcher Primitives

   The Dispatcher typically provides services to the SNMP applications
   via its PDU Dispatcher.  This section describes the primitives
   provided by the PDU Dispatcher.

4.1.1.  Generate Outgoing Request or Notification

   The PDU Dispatcher provides the following primitive for an
   application to send an SNMP Request or Notification to another SNMP
   entity:

   statusInformation =              -- sendPduHandle if success
                                    -- errorIndication if failure
     sendPdu(
     IN   transportDomain           -- transport domain to be used
     IN   transportAddress          -- transport address to be used
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model to use
     IN   securityName              -- on behalf of this principal
     IN   securityL