rfc1351.txt

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

       classes that are authorized to be processed by the
       specified target party when received from the specified
       subject party.

3.12   SNMP Proxy Party

   A SNMP proxy party is a SNMP party that performs management
   operations by communicating with another, logically remote party.

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

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

   The transparency principle that defines the behavior of a SNMP party
   in general applies in particular to a SNMP proxy party:

       The manner in which one SNMP party processes
       SNMP protocol messages received from another
       SNMP party 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 management framework,
   and it is the architectural cornerstone upon which large management
   systems may be built. Consistent with this philosophy, although the
   implementation of SNMP proxy agents in certain environments may
   resemble that of a transport-layer bridge, this particular
   implementation strategy (or any other!) does not merit special



Davin, Galvin, & McCloghrie                                    [Page 12]

RFC 1351               SNMP Administrative Model               July 1992


   recognition either in the SNMP management architecture or in standard
   mechanisms for proxy administration.

   Implicit in the transparency principle is the requirement that the
   semantics of SNMP management operations are preserved between any two
   SNMP 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 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 SNMP
   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.

3.13   Procedures

   This section describes the procedures followed by a SNMP protocol
   entity in processing SNMP messages. These procedures are independent
   of the particular authentication and privacy protocols that may be in
   use.

3.13.1   Generating a Request

   This section describes the procedure followed by a SNMP protocol
   entity whenever either a management request or a trap notification is
   to be transmitted by a SNMP party.

    1. An ASN.1 SnmpMgmtCom value is constructed for
       which the srcParty component identifies the originating
       party, for which the dstParty component identifies the
       receiving party, and for which the other component
       represents the desired management operation.





Davin, Galvin, & McCloghrie                                    [Page 13]

RFC 1351               SNMP Administrative Model               July 1992


    2. The local database is consulted to determine the
       authentication protocol and other relevant information
       for the originating SNMP party.

    3. An ASN.1 SnmpAuthMsg value is constructed with
       the following properties:

        o Its authInfo component is constructed according
          to the authentication protocol specified for the
          originating party.

          In particular, if the authentication protocol for the
          originating SNMP party is identified as noAuth,
          then this component corresponds to the OCTET
          STRING value of zero length.

        o Its authData component is the constructed
          SnmpMgmtCom value.

    4. The local database is consulted to determine the privacy
       protocol and other relevant information for the receiving
       SNMP party.

    5. An ASN.1 SnmpPrivMsg value is constructed with the
       following properties:

        o Its privDst component identifies the receiving
          SNMP party.

        o Its privData component is the (possibly
          encrypted) serialization of the SnmpAuthMsg
          value according to the conventions of [3] and [1].

          In particular, if the privacy protocol for the
          receiving SNMP party is identified as noPriv, then
          the privData component is unencrypted.
          Otherwise, the privData component is processed
          according to the privacy protocol.

    6. The constructed SnmpPrivMsg value is serialized
       according to the conventions of [3] and [1].

    7. The serialized SnmpPrivMsg value is transmitted
       using the transport address and transport domain for
       the receiving SNMP party.






Davin, Galvin, & McCloghrie                                    [Page 14]

RFC 1351               SNMP Administrative Model               July 1992


3.13.2   Processing a Received Communication

   This section describes the procedure followed by a SNMP protocol
   entity whenever a management communication is received.

    1. If the received message is not the serialization (according
       to the conventions of [3] and [1]) of an ASN.1
       SnmpPrivMsg value, then that message is discarded
       without further processing.

    2. The local database is consulted for information about
       the receiving SNMP party identified by the privDst
       component of the SnmpPrivMsg value.

    3. If information about the receiving SNMP party is absent
       from the local database, or specifies a transport domain
       and address which indicates that the receiving party's
       operation is not realized by the local SNMP protocol
       entity, then the received message is discarded without
       further processing.

    4. An ASN.1 OCTET STRING value is constructed
       (possibly by decryption, according to the privacy
       protocol in use) from the privData component of said
       SnmpPrivMsg value.

       In particular, if the privacy protocol recorded for the
       party is noPriv, then the OCTET STRING value
       corresponds exactly to the privData component of the
       SnmpPrivMsg value.

    5. If the OCTET STRING value is not the serialization
       (according to the conventions of [3] and [1]) of an ASN.1
       SnmpAuthMsg value, then the received message is
       discarded without further processing.

    6. If the dstParty component of the authData
       component of the obtained SnmpAuthMsg value is
       not the same as the privDst component of the
       SnmpPrivMsg value, then the received message is
       discarded without further processing.

    7. The local database is consulted for information about
       the originating SNMP party identified by the srcParty
       component of the authData component of the
       SnmpAuthMsg value.





Davin, Galvin, & McCloghrie                                    [Page 15]

RFC 1351               SNMP Administrative Model               July 1992


    8. If information about the originating SNMP party is
       absent from the local database, then the received
       message is discarded without further processing.

    9. The obtained SnmpAuthMsg value is evaluated
       according to the authentication protocol and other
       relevant information associated with the originating
       SNMP party in the local database.

       In particular, if the authentication protocol is identified
       as noAuth, then the SnmpAuthMsg value is always
       evaluated as authentic.

   10. If the SnmpAuthMsg value is evaluated as
       unauthentic, then the received message is discarded
       without further processing, and an authentication failure
       is noted.

   11. The ASN.1 SnmpMgmtCom value is extracted from
       the authData component of the SnmpAuthMsg
       value.

   12. The local database is consulted for access privileges
       permitted by the local access policy to the originating
       SNMP party with respect to the receiving SNMP party.

   13. The management communication class is determined
       from the ASN.1 tag value associated with the
       SnmpMgmtCom value.

   14. If the management communication class of the received
       message is either 16 or 4 (i.e., Trap or GetResponse) and
       this class is not among the access privileges, then the
       received message is discarded without further processing.

   15. If the management communication class of the received
       message is not among the access privileges, then the
       received message is discarded without further processing
       after generation and transmission of a response message.
       This response message is directed to the originating
       SNMP party on behalf of the receiving SNMP party. Its
       var-bind-list and request-id components are identical
       to those of the received request. Its error-index
       component is zero and its error-status component is
       readOnly.

   16. If the proxied party associated with the receiving SNMP
       party in the local database is identified as noProxy,



Davin, Galvin, & McCloghrie                                    [Page 16]

RFC 1351               SNMP Administrative Model               July 1992


       then the management operation represented by the
       SnmpMgmtCom value is performed by the receiving
       SNMP protocol entity with respect to the MIB view
       identified with the receiving SNMP party according to
       the procedures set forth in [1].

   17. If the proxied party associated with the receiving SNMP
       party in the local database is not identified as noProxy,
       then the management operation represented by the
       SnmpMgmtCom value is performed through
       appropriate cooperation between the receiving SNMP
       party and the identified proxied party.

       In particular, if the transport domain associated with
       the identified proxied party in the local database is
       rfc1351Domain, then the operation requested by
       the received message is performed by the generation of a
       corresponding request to the proxied party on behalf of
       the receiving party. If the received message requires a
       response from the local SNMP protocol entity, then that
       response is subsequently generated from the response (if
       any) received from the proxied party corresponding to
       the newly generated request.

3.13.3   Generating a Response

   This section describes the procedure followed by a SNMP protocol
   entity whenever a response to a management request is generated.

   The procedure for generating a response to a SNMP management request
   is identical to the procedure for transmitting a request (see Section
   3.13.1), except for the derivation of the transport domain and
   address information.  In this case, the response is transmitted using
   the transport domain and address from which the corresponding request
   originated -- even if that is different from the transport
   information recorded in the local database.

4.  Application of the Model

   This section describes how the administrative model set forth above
   is applied to realize effective network management in a variety of
   configurations and environments. Several types of administrative
   configurations are identified, and an example of each is presented.

4.1   Non-Secure Minimal Agent Configuration