rfc1909.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   SNMPv2 message.

   An SNMPv2 entity is not required to process multiple protocol
   messages concurrently, regardless of whether such messages require it
   to assume the identity of the same or different administrative
   entity.  Thus, an implementation of an SNMPv2 entity which supports
   more than one administrative entity need not be multi-threaded.
   However, there may be situations where implementors may choose to use
   multi-threading.

   An SNMPv2 entity listens for incoming, unsolicited SNMPv2 messages on
   each transport service address for which it is configured to do so.
   It is a local matter whether an SNMPv2 entity also listens for SNMPv2
   messages on any other transport service addresses.  In the absence of
   any other information on where to listen, an SNMPv2 entity must
   listen on the transport service addresses corresponding to the
   standard transport-layer "ports" [5] on its local network-layer
   addresses.

3.2.  SNMPv2 Agent

   An SNMPv2 agent is the operational role assumed by an SNMPv2 entity
   when it acts in an agent role.  Specifically, an SNMPv2 agent
   performs SNMPv2 management operations in response to received SNMPv2
   protocol messages (except for inform notifications).

   In order to be manageable, all network components need to be
   instrumented.  SNMPv2 access to the instrumented information is via
   the managed objects supported by an SNMPv2 agent in one or more
   contexts.







McCloghrie                    Experimental                      [Page 7]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


3.3.  SNMPv2 Manager

   An SNMPv2 manager is the operational role assumed by an SNMPv2 entity
   when it acts in a manager role on behalf of management applications.
   Specifically, an SNMPv2 manager initiates SNMPv2 management
   operations by the generation of appropriate SNMPv2 protocol messages,
   or when it receives and processes trap and inform notifications.

   It is interesting to consider the case of managing an SNMPv2 manager.
   It is highly desirable that an SNMPv2 manager, just like any other
   networking application, be instrumented for the purposes of being
   managed.  Such instrumentation of an SNMPv2 manager (just like for
   any other networking application) is accessible via the managed
   objects supported by an SNMPv2 agent.  As such, an SNMPv2 manager is
   no different from any other network application in that it has
   instrumentation, but does not itself have managed objects.

   That is, an SNMPv2 manager does not itself have managed objects.
   Rather, it is an associated SNMPv2 agent supporting managed objects
   which provides access to the SNMPv2 manager's instrumentation.

3.4.  SNMPv2 Dual-Role Entity

   An SNMPv2 entity which sometimes acts in an agent role and sometimes
   acts in a manager role, is termed an SNMPv2 dual-role entity.  An
   SNMPv2 dual-role entity initiates requests by acting in a manager
   role, and processes requests regarding management information
   accessible to it (locally or via proxy) through acting in an agent
   role.  In the case of sending inform notifications, an SNMPv2 dual-
   role entity acts in a manager role in initiating an inform
   notification containing management information which is accessible to
   it when acting in an agent role.

   An SNMPv2 entity which can act only in an SNMPv2 manager role is not
   SNMP-manageable, since there is no way to access its management
   instrumentation.  In order to be SNMP-manageable, an SNMPv2 entity
   must be able to act in an SNMPv2 agent role in order to allow its
   instrumentation to be accessed.  Thus, it is highly desirable that
   all SNMPv2 entities be either SNMPv2 agents or SNMPv2 dual-role
   entities.

   There are two categories of SNMPv2 dual-role entities:  proxy SNMPv2
   agents and (so-called) mid-level managers.  Proxy SNMPv2 agents only
   forward requests/responses; they do not originate requests.  In
   contrast, mid-level managers often originate requests.  (Note that
   the term proxy SNMPv2 agent does not include an SNMPv2 agent which
   translates SNMPv2 requests into the requests of some other management
   protocol; see section 2.6.)



McCloghrie                    Experimental                      [Page 8]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


3.5.  View Subtree and Families

   A view subtree is the set of all MIB object instances which have a
   common ASN.1 OBJECT IDENTIFIER prefix to their names.  A view subtree
   is identified by the OBJECT IDENTIFIER value which is the longest
   OBJECT IDENTIFIER prefix common to all (potential) MIB object
   instances in that subtree.

   A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
   (called the family name) together with a bitstring value (called the
   family mask).  The family mask indicates which sub-identifiers of the
   associated family name are significant to the family's definition.

   For each possible managed object instance, that instance belongs to a
   particular view subtree family if both of the following conditions
   are true:

o    the OBJECT IDENTIFIER name of the managed object instance contains
     at least as many sub-identifiers as does the family name, and

o    each sub-identifier in the OBJECT IDENTIFIER name of the managed
     object instance matches the corresponding sub-identifier of the
     family name whenever the corresponding bit of the associated family
     mask is non-zero.

   When the configured value of the family mask is all ones, the view
   subtree family is identical to the single view subtree identified by
   the family name.

   When the configured value of the family mask is shorter than required
   to perform the above test, its value is implicitly extended with
   ones.  Consequently, a view subtree family having a family mask of
   zero length always corresponds to a single view subtree.

3.6.  MIB View

   A MIB view is a subset of the set of all instances of all object
   types defined according to the SMI [1] within an SNMPv2 context,
   subject to the following constraints:

o    It is possible to specify a MIB view which contains the full set of
     all object instances within an SNMPv2 context.

o    Each object instance within a MIB view is uniquely named by an
     ASN.1 OBJECT IDENTIFIER value.

   As such, identically named instances of a particular object type must
   be contained within different SNMPv2 contexts.  That is, a particular



McCloghrie                    Experimental                      [Page 9]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   object instance name resolves within a particular SNMPv2 context to
   at most one object instance.

   A MIB view is defined as a collection of view subtree families, where
   each view subtree family has a type.  The type determines whether the
   view subtree family is included in, or excluded from, the MIB view.

   A managed object instance is contained/not contained within the MIB
   view according to the view subtree families to which the instance
   belongs:

o    If a managed object instance belongs to none of the relevant
     subtree families, then that instance is not in the MIB view.

o    If a managed object instance belongs to exactly one of the relevant
     subtree families, then that instance is included in, or excluded
     from, the relevant MIB view according to the type of that subtree
     family.

o    If a managed object instance belongs to more than one of the
     relevant subtree families, then that instance is included in, or
     excluded from, the relevant MIB view according to the type of a
     particular one of the subtree families to which it belongs.  The
     particular subtree family is the one for which, first, the
     associated family name comprises the greatest number of sub-
     identifiers, and, second, the associated family name is
     lexicographically greatest.

3.7.  SNMPv2 Context

   An SNMPv2 context is a collection of management information
   accessible by an SNMPv2 entity.  The collection of management
   information identified by a context is either local or proxy.

   For a local SNMPv2 context which is realized by an SNMPv2 entity,
   that SNMPv2 entity uses locally-defined mechanisms to access the
   management information identified by the SNMPv2 context.

   For a proxy SNMPv2 context, the SNMPv2 entity acts as a proxy SNMPv2
   agent to access the management information identified by the SNMPv2
   context.

   The term remote SNMPv2 context is used at an SNMPv2 manager to
   indicate a SNMPv2 context (either local or proxy) which is not
   realized by the local SNMPv2 entity (i.e.,  the local SNMPv2 entity
   uses neither locally-defined mechanisms, nor acts as a proxy SNMPv2
   agent, to access the management information identified by the SNMPv2
   context).



McCloghrie                    Experimental                     [Page 10]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


3.7.1.  Local SNMPv2 Context

   A local context refers to a collection of MIB objects which
   (logically) belong to a single entity within a managed device.  When
   an SNMPv2 entity accesses that management information, it does so
   using locally-defined mechanisms.

   Because a device may contain several such local entities, each local
   context has associated with it a "local entity" name.  Further,
   because management information changes over time, each local context
   also has associated with it an associated temporal domain, termed its
   "local time".  This allows, for example, one context to refer to the
   current values of a device's parameters, and a different context to
   refer to the values that the same parameters for the same device will
   have after the device's next restart.

3.7.2.  Proxy SNMPv2 Context

   A proxy relationship exists when a proxy SNMPv2 agent processes a
   received SNMPv2 message (a request or a response) by forwarding it to
   another entity, solely according to the SNMPv2 context of the
   received message.  Such a context is called a proxy SNMPv2 context.
   When an SNMPv2 entity processes management requests/responses for a
   proxy context, it is operating as a proxy SNMPv2 agent.

   The transparency principle that defines the behavior of an SNMPv2
   entity in general, applies in particular to a proxy SNMPv2 context:

     The manner in which a receiving SNMPv2 entity processes SNMPv2
     protocol messages sent by another SNMPv2 entity is entirely
     transparent to the sending SNMPv2 entity.

   Implicit in the transparency principle is the requirement that the
   semantics of SNMPv2 management operations are preserved between any
   two SNMPv2 peers.  In particular, the "as if simultaneous" semantics
   of a

   Set operation are extremely difficult to guarantee if its scope
   extends to management information resident at multiple network
   locations.  Note however, that agents which support the forwarding of
   Set operations concerning information at multiple locations are not
   considered to be proxy SNMPv2 agents (see section 2.6 above).

   Also implicit in the transparency principle is the requirement that,
   throughout its interaction with a proxy SNMPv2 agent, an SNMPv2
   manager is supplied with no information about the nature or progress
   of the proxy mechanisms used to perform its requests.  That is, it
   should seem to the SNMPv2 manager (except for any distinction in an



McCloghrie                    Experimental                     [Page 11]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   underlying transport address) as if it were interacting via SNMPv2
   directly with the proxied device.  Thus, a timeout in the
   communication between a proxy SNMPv2 agent and its proxied device
   should be represented as a timeout in the communication between the
   SNMPv2 manager and the proxy SNMPv2 agent.  Similarly, an error
   response from a proxied device should - as much as possible - be
   represented by the corresponding error response in the interaction
   between the proxy SNMPv2 agent and SNMPv2 manager.

3.8.  SNMPv2 PDUs and Operations

   An SNMPv2 PDU is defined in [4].  Each SNMPv2 PDU specifies a
   particular operation, one of:

               GetBulkRequest
               GetNextRequest
               GetRequest
               Inform
               Report
               Response
               SNMPv2-Trap
               SetRequest

3.8.1.  The Report-PDU

   [4] requires that an administrative framework which makes use of the
   Report-PDU must define its usage and semantics.  With this
   administrative framework, the Report-PDU differs from the other PDU
   types described in [4] in that it is not a protocol operation between
   SNMPv2 managers and agents, but rather is an aspect of error-
   reporting between SNMPv2 entities. Specifically, it is an interaction
   between two protocol engines.

   A communication between SNMPv2 entities is in the form of an SNMPv2
   message.  Such a message is formatted as a "wrapper" encapsulating a
   PDU according to the "Elements of Procedure" for the security model
   used for transmission of the message.

   While processing a received communication, an SNMPv2 entity may
   determine that the received message is unacceptable due to a problem
   associated with the contents of the message "wrapper".  In this case,
   an appropriate counter is incremented and the received message is
   discarded without further processing (and without transmission of a
   Response-PDU).

   However, if an SNMPv2 entity acting in the agent role makes such a
   determination, then after incrementing the appropriate counter, it
   may be required to generate a Report-PDU and to send it to the



McCloghrie                    Experimental                     [Page 12]

RFC 1909        An SNMPv2 Administrative Infrastructure    February 1996


   transport address which originated the received message.

   If the agent is able to determine the value of the request-id field
   of the received PDU [4], then it must use that value for the
   request-id field of the Report-PDU.  Otherwise, the value 2147483647
   is used.

   The error-status and error-index fields of the Report-PDU are always
   set to zero.  The variable-bindings field contains a single variable:
   the identity of the counter which was incremented and its new value.

   There is at least one case in which a Report-PDU must not be sent by
   an SNMPv2 entity acting in the agent role: if the received message
   was tagged as a Report-PDU.  Particular security models may identify
   other such cases.

3.9.  SNMPv2 Access Control Policy

   An SNMPv2 access policy specifies the types of SNMPv2 operations
   authorized for a particular identity using a particular level of
   security, and if the operation is to be performed on a local SNMPv2
   context, two accessible MIB views.  The two MIB views are a read-view
   and a write-view.  A read-view is a set of object instances
   authorized for the identity when reading objects.  Reading objects
   occurs when processing a retrieval (get, get-next, get-bulk)
   operation and when sending a notification.  A write-view is the set
   of object instances authorized for the identity when writing objects.
   Writing objects occurs when processing a set operation.  An
   identity's access rights may be different at different agents.

   A security model defines how an SNMPv2 access policy is derived;
   however, the application of an SNMPv2 access control policy is
   performed only: