rfc1445.txt

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

          o    Its partyPrivPublic component is called the public
               privacy key and represents any public value that may be
               needed to support the privacy protocol.  The significance
               of this component is specific to the privacy protocol.

          If, for all SNMPv2 parties realized by a SNMPv2 entity, the
          authentication protocol is noAuth and the privacy protocol is
          noPriv, then that entity is called non-secure.


          2.2.  SNMPv2 Entity

          A SNMPv2 entity is an actual process which performs network
          management operations by generating and/or responding to
          SNMPv2 protocol messages in the manner specified in [2].  When
          a SNMPv2 entity is acting as a particular SNMPv2 party (see
          Section 2.1), the operation of that entity must be restricted
          to the subset of all possible operations that is
          administratively defined for that party.

          By definition, the operation of a SNMPv2 entity requires no
          concurrency between processing of any single protocol message
          (by a particular SNMPv2 party) and processing of any other
          protocol message (by a potentially different SNMPv2 party).
          Accordingly, implementation of a SNMPv2 entity to support more
          than one party need not be multi-threaded.  However, there may
          be situations where implementors may choose to use multi-
          threading.

          Architecturally, every SNMPv2 entity maintains a local
          database that represents all SNMPv2 parties known to it -
          those whose operation is realized locally, those whose
          operation is realized by proxy interactions with remote
          parties or devices, and those whose operation is realized by
          remote entities.  In addition, every SNMPv2 entity maintains a
          local database that represents all managed object resources
          (see Section 2.8) which are known to the SNMPv2 entity.
          Finally, every SNMPv2 entity maintains a local database that
          represents an access control policy (see Section 2.11) that
          defines the access privileges accorded to known SNMPv2
          parties.







          Galvin & McCloghrie                                   [Page 6]





          RFC 1445       Administrative Model for SNMPv2      April 1993


          2.3.  SNMPv2 Management Station

          A SNMPv2 management station is the operational role assumed by
          a SNMPv2 party when it initiates SNMPv2 management operations
          by the generation of appropriate SNMPv2 protocol messages or
          when it receives and processes trap notifications.

          Sometimes, the term SNMPv2 management station is applied to
          partial implementations of the SNMPv2 (in graphics
          workstations, for example) that focus upon this operational
          role.  Such partial implementations may provide for
          convenient, local invocation of management services, but they
          may provide little or no support for performing SNMPv2
          management operations on behalf of remote protocol users.


          2.4.  SNMPv2 Agent

          A SNMPv2 agent is the operational role assumed by a SNMPv2
          party when it performs SNMPv2 management operations in
          response to received SNMPv2 protocol messages such as those
          generated by a SNMPv2 management station (see Section 2.3).

          Sometimes, the term SNMPv2 agent is applied to partial
          implementations of the SNMPv2 (in embedded systems, for
          example) that focus upon this operational role.  Such partial
          implementations provide for realization of SNMPv2 management
          operations on behalf of remote users of management services,
          but they may provide little or no support for local invocation
          of such services.


          2.5.  View Subtree

          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.

          When the OBJECT IDENTIFIER prefix identifying a view subtree
          is longer than the OBJECT IDENTIFIER of an object type defined
          according to the SMI [3], then the use of such a view subtree
          for access control has granularity at the object instance
          level.  Such granularity is considered beyond the scope of a





          Galvin & McCloghrie                                   [Page 7]





          RFC 1445       Administrative Model for SNMPv2      April 1993


          SNMPv2 entity acting in an agent role.  As such, no
          implementation of a SNMPv2 entity acting in an agent role is
          required to support values of viewSubtree [6] which have more
          sub-identifiers than is necessary to identify a particular
          leaf object type.  However, access control information is also
          used in determining which SNMPv2 entities acting in a manager
          role should receive trap notifications (Section 4.2.6 of [2]).
          As such, agent implementors might wish to provide instance-
          level granularity in order to allow a management station to
          use fine-grain configuration of trap notifications.


          2.6.  MIB View

          A MIB view is a subset of the set of all instances of all
          object types defined according to the SMI [3] (i.e., of the
          universal set of all instances of all MIB objects), subject to
          the following constraints:

          o    Each element of a MIB view is uniquely named by an ASN.1
               OBJECT IDENTIFIER value.  As such, identically named
               instances of a particular object type (e.g., in different
               agents) must be contained within different MIB views.
               That is, a particular object instance name resolves
               within a particular MIB view to at most one object
               instance.

          o    Every MIB view is defined as a collection of view
               subtrees.


          2.7.  Proxy Relationship

          A proxy relationship exists when, in order to process a
          received management request, a SNMPv2 entity must communicate
          with another, logically remote, entity.  A SNMPv2 entity which
          processes management requests using a proxy relationship is
          termed a SNMPv2 proxy agent.

          When communication between a logically remote party and a
          SNMPv2 entity is via the SNMPv2 (over any transport protocol),
          then the proxy party is called a SNMPv2 native proxy
          relationship.  Deployment of SNMPv2 native proxy relationships
          is a means whereby the processing or bandwidth costs of
          management may be amortized or shifted - thereby facilitating





          Galvin & McCloghrie                                   [Page 8]





          RFC 1445       Administrative Model for SNMPv2      April 1993


          the construction of large management systems.

          When communication between a logically remote party and a
          SNMPv2 entity party is not via the SNMPv2, then the proxy
          party is called a SNMPv2 foreign proxy relationship.
          Deployment of foreign proxy relationships is a means whereby
          otherwise unmanageable devices or portions of an internet may
          be managed via the SNMPv2.

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

               The manner in which one SNMPv2 entity processes SNMPv2
               protocol messages received from another SNMPv2 entity is
               entirely transparent to the latter.

          The transparency principle derives directly from the
          historical SNMP philosophy of divorcing architecture from
          implementation.  To this dichotomy are attributable many of
          the most valuable benefits in both the information and
          distribution models of the Internet-standard Network
          Management Framework, and it is the architectural cornerstone
          upon which large management systems may be built.  Consistent
          with this philosophy, although the implementation of SNMPv2
          proxy agents in certain environments may resemble that of a
          transport-layer bridge, this particular implementation
          strategy (or any other!) does not merit special recognition
          either in the SNMPv2 management architecture or in standard
          mechanisms for proxy administration.

          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.  For this
          reason, proxy configurations that admit Set operations that
          apply to information at multiple locations are discouraged,
          although such operations are not explicitly precluded by the
          architecture in those rare cases where they might be supported
          in a conformant way.

          Also implicit in the transparency principle is the requirement
          that, throughout its interaction with a proxy agent, a





          Galvin & McCloghrie                                   [Page 9]





          RFC 1445       Administrative Model for SNMPv2      April 1993


          management station is supplied with no information about the
          nature or progress of the proxy mechanisms by which its
          requests are realized.  That is, it should seem to the
          management station - except for any distinction in underlying
          transport address - as if it were interacting via SNMPv2
          directly with the proxied device.  Thus, a timeout in the
          communication between a proxy agent and its proxied device
          should be represented as a timeout in the communication
          between the management station and the proxy 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 agent and
          management station.


          2.8.  SNMPv2 Context

          A SNMPv2 context is a collection of managed object resources
          accessible by a SNMPv2 entity.  The object resources
          identified by a context are either local or remote.

          A SNMPv2 context referring to local object resources is
          identified as a MIB view.  In this case, a SNMPv2 entity uses
          local mechanisms to access the management information
          identified by the SNMPv2 context.

          A remote SNMPv2 context referring to remote object resources
          is identified as a proxy relationship.  In this case, a SNMPv2
          entity acts as a proxy agent to access the management
          information identified by the SNMPv2 context.


          2.9.  SNMPv2 Management Communication

          A SNMPv2 management communication is a communication from one
          specified SNMPv2 party to a second specified SNMPv2 party
          about management information that is contained in a SNMPv2
          context accessible by the appropriate SNMPv2 entity.  In
          particular, a SNMPv2 management communication may be

          o    a query by the originating party about information
               accessible to the addressed party (e.g., getRequest,
               getNextRequest, or getBulkRequest),







          Galvin & McCloghrie                                  [Page 10]





          RFC 1445       Administrative Model for SNMPv2      April 1993


          o    an indicative assertion to the addressed party about
               information accessible to the originating party (e.g.,
               Response, InformRequest, or SNMPv2-Trap),

          o    an imperative assertion by the originating party about
               information accessible to the addressed party (e.g.,
               setRequest), or

          o    a confirmation to the addressed party about information
               received by the originating party (e.g., a Response
               confirming an InformRequest).

          A management communication is represented by an ASN.1 value
          with the following syntax:

               SnmpMgmtCom ::= [2] IMPLICIT SEQUENCE {
                 dstParty
                    OBJECT IDENTIFIER,
                 srcParty
                    OBJECT IDENTIFIER,
                 context
                    OBJECT IDENTIFIER,
                 pdu
                    PDUs
               }

          For each SnmpMgmtCom value that represents a SNMPv2 management
          communication, the following statements are true:

          o    Its dstParty component is called the destination and
               identifies the SNMPv2 party to which the communication is
               directed.

          o    Its srcParty component is called the source and
               identifies the SNMPv2 party from which the communication
               is originated.

          o    Its context component identifies the SNMPv2 context
               containing the management information referenced by the
               communication.

          o    Its pdu component has the form and significance
               attributed to it in [2].







          Galvin & McCloghrie                                  [Page 11]





          RFC 1445       Administrative Model for SNMPv2      April 1993


          2.10.  SNMPv2 Authenticated Management Communication

          A SNMPv2 authenticated management communication is a SNMPv2
          management communication (see Section 2.9) for which the
          originating SNMPv2 party is (possibly) reliably identified and
          for which the integrity of the transmission of the
          communication is (possibly) protected.  An authenticated
          management communication is represented by an ASN.1 value with
          the following syntax:

               SnmpAuthMsg ::= [1] IMPLICIT SEQUENCE {