rfc1909.txt

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

o    on receipt of GetRequest, GetNextRequest, GetBulkRequest, and
     SetRequest operations; and

o    prior to transmission of SNMPv2-Trap and Inform operations.

   Note that application of an SNMPv2 access control policy is never
   performed for Response or Report operations.

4.  Security Considerations

   Security issues are not directly discussed in this memo.






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


5.  Editor's Address

   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   US

   Phone: [phone]
   EMail: [e-mail]

6.  Acknowledgements

   This document is the result of significant work by three major
   contributors:

     Keith McCloghrie (Cisco Systems, [e-mail])
     Marshall T. Rose (Dover Beach Consulting, [e-mail])
     Glenn W. Waters (Bell-Northern Research Ltd., [e-mail])

   The authors wish to acknowledge James M. Galvin of Trusted
   Information Systems who contributed significantly to earlier work on
   which this memo is based, and the general contributions of members of
   the SNMPv2 Working Group, and, in particular, Aleksey Y. Romanov and
   Steven L. Waldbusser.

   A special thanks is extended for the contributions of:

     Uri Blumenthal (IBM)
     Shawn Routhier (Epilogue)
     Barry Sheehan (IBM)
     Bert Wijnen (IBM)

7.  References

[1]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Structure of Management Information for Version 2
     of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
     January 1996.

[2]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Textual Conventions for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1903, January 1996.

[3]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S., Waldbusser, "Conformance Statements for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1904, January 1996.




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


[4]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     S. Waldbusser, "Protocol Operations for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1905, January 1996.

[5]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     Waldbusser, S., "Transport Mappings for Version 2 of the Simple
     Network Management Protocol (SNMPv2)", RFC 1906, January 1996.

[6]  The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     Waldbusser, S., "Management Information Base for Version 2 of the
     Simple Network Management Protocol (SNMPv2)", RFC 1907,
     January 1996.

[7]  Rose, M., and K. McCloghrie, "Structure and Identification of
     Management Information for TCP/IP-based internets", STD 16, RFC
     1155, May 1990.

[8]  Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
     RFC 1212, March 1991.

[9]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
     Network Management Protocol", STD 15, RFC 1157, SNMP Research,
     Performance Systems International, MIT Laboratory for Computer
     Science, May 1990.

[10] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
     Waldbusser, S., "Coexistence between Version 1 and Version 2 of the
     Internet-standard Network Management Framework", RFC 1908, January
     1996.

[11] McCloghrie, K., and F. Kastenholz, "Evolution of the Interfaces
     Group of MIB-II", RFC 1573, Cisco Systems, FTP Software, January
     1994.

[12] Information processing systems - Open Systems Interconnection -
     Specification of Abstract Syntax Notation One (ASN.1),
     International Organization for Standardization.  International
     Standard 8824, (December, 1987).













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


APPENDIX A - Disambiguating the SNMPv2 Protocol Definition

The descriptions in [4] of the role in which an SNMPv2 entity acts when
sending an Inform-Request PDU are ambiguous.  The following updates
serve to remove those ambiguities.

(1)  Add the following sentence to section 2.1:

          Further, when an SNMPv2 entity sends an inform notification,
          it acts in a manager role in respect to initiating the
          operation, but the management information contained in the
          inform notification is associated with that entity acting in
          an agent role.  By convention, the inform is sent from the
          same transport address as the associated agent role is
          listening on.

(2)  Modify the last sentence of the second paragraph in section 2.3:

          This type is used by one SNMPv2 entity, acting in a manager
          role, to notify another SNMPv2 entity, also acting in a
          manager role, of management information associated with the
          sending SNMPv2 entity acting in an agent role.

(3)  Modify the second paragraph of section 4.2 (concerning the
     generation of Inform-Request PDUs):

          It is mandatory that all SNMPv2 entities acting in a manager
          role be able to generate the following PDU types: GetRequest-
          PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
          and Response-PDU; further, all such implementations must be
          able to receive the following PDU types: Response-PDU,
          SNMPv2-Trap-PDU, InformRequest-PDU.  It is mandatory that all
          dual-role SNMPv2 entities must be able to generate an Inform-
          Request PDU.

(4)  Modify the first paragraph of section 4.2.7:

          An InformRequest-PDU is generated and transmitted at the
          request of an application in a SNMPv2 entity acting in a
          manager role, that wishes to notify another application (via
          an SNMPv2 entity also acting in a manager role) of information
          in a MIB view which is accessible to the sending SNMPv2 entity
          when acting in an agent role.








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


APPENDIX B - Who Sends Inform-Requests?

B.1.   Management Philosophy

   Ever since its beginnings as SGMP, through its definition as SNMPv1,
   and continuing with the definition of SNMPv2, SNMP has embodied more
   than just a management protocol and the definitions of MIB objects.
   Specifically, SNMP has also had a fundamental philosophy of
   management, consisting of a number of design strategies.  These
   strategies have always included the following:

(1)  The impact of incorporating an SNMP agent into a system should be
     minimal, so that both: a) it is feasible to do so even in the
     smallest/cheapest of systems, and b) the operational role and
     performance of a system is not compromised by the inclusion of an
     SNMP agent.  This promotes widespread development, which allows
     ubiquitous deployment of manageable systems.

(2)  Every system (potentially) incorporates an SNMP agent.  In
     contrast, the number of SNMP managers is limited.  Thus, there is a
     significantly larger number of SNMP agents than SNMP managers.
     Therefore, overall system development/complexity/cost is optimized
     if the SNMP agent is allowed to be simple and any required
     complexity is performed by an SNMP manager.

(3)  The number of unsolicited messages generated by SNMP agents is
     minimized.  This enables the amount of network management traffic
     to be controlled by the small number of SNMP managers which are
     (more) directly controlled by network operators.  In fact, this
     control is considered of greater importance than any additional
     protocol overhead which might be incurred.  Monitoring of network
     state at any significant level of detail is accomplished primarily
     by SNMP managers polling for the appropriate information, with the
     use of unsolicited messages confined to those situations where it
     is necessary to properly guide an SNMP manager regarding the timing
     and focus of its polling.  This strategy is sometimes referred to
     as "trap-directed polling".

B.2.   The Danger of Trap Storms

   The need for such control over the amount of network management
   traffic is due to the potential that the SNMP manager receiving an
   unsolicited message does not want, no longer wants, or already knows
   of the information contained in the message.  This potential is
   significantly reduced by having the majority of messages be specific
   requests for information by SNMP managers and responses (to those
   requests) from SNMP agents.




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


   The danger of not having the amount of network management be
   controlled in this manner is the potential for a "storm" of useless
   traps.  As a simple example of "useless", consider that after a
   building power outage, every device in the network sends a coldStart
   trap, even though every SNMP manager and every network operator
   already knows what happened.  For a simple example of "storm",
   consider the result if each transmitted trap caused the sending of
   another.  The greater the number of problems in the state of the
   network, the greater the risk of such a storm occurring, especially
   in the unstructured, heterogeneous environment typical of today's
   internets.

   While SNMP philosophy considers the above to be more important than
   any lack of reliability in unsolicited messages, some
   users/developers have been wary of using traps because of the use
   (typically) of an unreliable transport protocol and because traps are
   not acknowledged.  However, following this logic would imply that
   having acknowledged-traps would make them reliable; of course, this
   is false since no amount of re- transmission will succeed if the
   receiver and/or the connectivity to the receiver is down.  A SNMP
   manager cannot just sit and wait and assume the network is fine just
   because it is not receiving any unsolicited messages.

B.3.   Inform-Requests

   One of the new features of SNMPv2 is the Inform-request PDU.  The
   Inform-Request contains management information specified in terms of
   MIB objects for a context supported by the sender.  Since by
   definition, an SNMPv2 manager does not itself have managed objects
   (see sections 3.3), the managed objects contained in the Inform-
   request belong to a context of an SNMPv2 agent, just like the managed
   objects contained in an SNMPv2-Trap.

   However, it is not the purpose of an Inform-request to change the
   above described philosophy, i.e., it would be wrong to consider it as
   an "acknowledged trap".  To do so, would make the likelihood and
   effect of trap storms worse.  Recall the building power outage
   example:  with regular traps, the SNMP manager's buffer just
   overflows when it receives messages faster than it can cope with; in
   contrast, if every device in the network were to send a coldStart
   Inform-request, then after a power outage, all will re-transmit their
   Inform-request several times unless the receiving SNMP managers send
   responses.  In the best case when no messages are lost or re-
   transmitted, there are twice as many useless messages; in the worst
   case, the SNMP manager is unable to respond at all and every message
   is re-transmitted its maximum number of times.





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


   The above serves to explain the rationale behind the definition (see
   Appendix A's update to section 4.2.7 of [4]) that:

     An InformRequest-PDU is generated and transmitted at the request of
     an application in a SNMPv2 entity acting in a manager role, that
     wishes to notify another application (via an SNMPv2 entity also
     acting in a manager role) of information in a MIB view which is
     accessible to the sending SNMPv2 entity when acting in an agent
     role.

   This definition says that SNMPv2 agents do not send Inform-Requests,
   which has three implications (ordered in terms of importance):

(1)  the number of devices which send Inform-requests is required to be
     a small subset of all devices in the network;

(2)  while some devices traditionally considered to be SNMP agents are
     perfectly capable of sending Inform-requests, the overall system
     development/complexity/cost is not increased as it would be by
     having to configure/re-configure every SNMPv2 agent as to which
     Inform-requests to send where and how often; and

(3)  the cost of implementing an SNMPv2 agent in the smallest/cheapest
     system is not increased.



























McCloghrie                    Experimental                     [Page 19]