rfc1452.txt

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

          If a MIB module is changed to conform to the SNMPv2 framework,
          then each occurrence of the TRAP-TYPE macro must be changed to
          a corresponding invocation of the NOTIFICATION-TYPE macro:

          (1)  The IMPORTS statement must not reference RFC-1215.

          (2)  The ENTERPRISES clause must be removed.

          (3)  The VARIABLES clause must be renamed to the OBJECTS
               clause.







          Case, McCloghrie, Rose & Waldbusser                   [Page 6]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          (4)  The STATUS clause must be added.

          (5)  The value of an invocation of the NOTIFICATION-TYPE macro
               is an OBJECT IDENTIFIER, not an INTEGER, and must be
               changed accordingly.


          2.3.  Compliance Statements

          For those information modules which are "standard", a
          corresponding invocation of the MODULE-COMPLIANCE macro must
          be included within the information module (or in a companion
          information module), and any commentary text in the
          information module which relates to compliance must be
          removed.  Typically this editing can occur when the
          information module undergoes review.


          2.4.  Capabilities Statements

          In the current framework, the informational document [9] uses
          the MODULE-CONFORMANCE macro to describe an agent's
          capabilities with respect to one or more MIB modules.
          Converting such a description for use with the SNMPv2
          framework requires these changes:

          (1)  Use the macro name AGENT-CAPABILITIES instead of MODULE-
               CONFORMANCE.

          (2)  The STATUS clause must be added.

          (3)  For all occurrences of the CREATION-REQUIRES clause, note
               the slight change in semantics, and omit this clause if
               appropriate.
















          Case, McCloghrie, Rose & Waldbusser                   [Page 7]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          3.  Protocol Operations

          The SNMPv2 documents which deal with protocol operations are:

               Protocol Operations for SNMPv2 [10], which defines the
               syntax and semantics of the operations conveyed by the
               protocol; and,

               Transport Mappings for SNMPv2 [11], which defines how the
               protocol operations are carried over different transport
               services.

          The following section considers two areas: the proxy behavior
          between a SNMPv2 entity and a SNMPv1 agent; and, the behavior
          of "bi-lingual" protocol entities acting in a manager role.


          3.1.  Proxy Agent Behavior

          To achieve coexistence at the protocol-level, a proxy
          mechanism may be used.  A SNMPv2 entity acting in an agent
          role may be implemented and configured to act in the role of a
          proxy agent.


          3.1.1.  SNMPv2 -> SNMPv1

          When converting requests from a SNMPv2 entity acting in a
          manager role into requests sent to a SNMPv1 entity acting in
          an agent role:

          (1)  If a GetRequest-PDU, GetNextRequest-PDU, or SetRequest-
               PDU is received, then it is passed unaltered by the proxy
               agent.

          (2)  If a GetBulkRequest-PDU is received, the proxy agent sets
               the non-repeaters and max-repetitions fields to zero, and
               sets the tag of the PDU to GetNextRequest-PDU.


          3.1.2.  SNMPv1 -> SNMPv2

          When converting responses received from a SNMPv1 entity acting
          in an agent role into responses sent to a SNMPv2 entity acting
          in a manager role:





          Case, McCloghrie, Rose & Waldbusser                   [Page 8]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          (1)  If a GetResponse-PDU is received, then it is passed
               unaltered by the proxy agent.  Note that even though a
               SNMPv2 entity will never generate a Response-PDU with a
               error-status field having a value of `noSuchName',
               `badValue', or `readOnly', the proxy agent must not
               change this field.  This allows the SNMPv2 entity acting
               in a manager role to interpret the response correctly.

               If a GetResponse-PDU is received with an error-status
               field having a value of `tooBig', the proxy agent will
               remove the contents of the variable-bindings field before
               propagating the response.  Note that even though a SNMPv2
               entity will never generate a `tooBig' in response to a
               GetBulkRequestPDU, the proxy agent must propagate such a
               response.

          (2)  If a Trap-PDU is received, then it is mapped into a
               SNMPv2-Trap-PDU.  This is done by prepending onto the
               variable-bindings field two new bindings: sysUpTime.0
               [12], which takes its value from the timestamp field of
               the Trap-PDU; and, snmpTrapOID.0 [13], which is
               calculated thusly: if the value of generic-trap field is
               `enterpriseSpecific', then the value used is the
               concatenation of the enterprise field from the Trap-PDU
               with two additional sub-identifiers, `0', and the value
               of the specific-trap field; otherwise, the value of the
               corresponding trap defined in [13] is used.  (For
               example, if the value of the generic-trap field is
               `coldStart', then the coldStart trap [13] is used.) Then,
               one new binding is appended onto the variable-bindings
               field: snmpTrapEnterpriseOID.0 [13], which takes its
               value from the enterprise field of the Trap-PDU.  To
               determine the destinations for the SNMPv2-Trap-PDU, the
               proxy agent applies the procedures defined in Section
               4.2.6 of [10], with the exception that no check is made
               to see if the instances associated with this trap are
               present in the proxy agent's view.













          Case, McCloghrie, Rose & Waldbusser                   [Page 9]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          3.2.  Bi-lingual Manager Behavior

          To achieve coexistence at the protocol-level, a protocol
          entity acting in a manager role might support both SNMPv1 and
          SNMPv2.  When a management application needs to contact a
          protocol entity acting in an agent role, the entity acting in
          a manager role consults a local database to select the correct
          management protocol to use.

          In order to provide transparency to management applications,
          the entity acting in a manager role must map operations as if
          it were acting as a proxy agent.






































          Case, McCloghrie, Rose & Waldbusser                  [Page 10]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


          4.  Acknowledgements

          The comments of the SNMP version 2 working group are
          gratefully acknowledged:

               Beth Adams, Network Management Forum
               Steve Alexander, INTERACTIVE Systems Corporation
               David Arneson, Cabletron Systems
               Toshiya Asaba
               Fred Baker, ACC
               Jim Barnes, Xylogics, Inc.
               Brian Bataille
               Andy Bierman, SynOptics Communications, Inc.
               Uri Blumenthal, IBM Corporation
               Fred Bohle, Interlink
               Jack Brown
               Theodore Brunner, Bellcore
               Stephen F. Bush, GE Information Services
               Jeffrey D. Case, University of Tennessee, Knoxville
               John Chang, IBM Corporation
               Szusin Chen, Sun Microsystems
               Robert Ching
               Chris Chiotasso, Ungermann-Bass
               Bobby A. Clay, NASA/Boeing
               John Cooke, Chipcom
               Tracy Cox, Bellcore
               Juan Cruz, Datability, Inc.
               David Cullerot, Cabletron Systems
               Cathy Cunningham, Microcom
               James R. (Chuck) Davin, Bellcore
               Michael Davis, Clearpoint
               Mike Davison, FiberCom
               Cynthia DellaTorre, MITRE
               Taso N. Devetzis, Bellcore
               Manual Diaz, DAVID Systems, Inc.
               Jon Dreyer, Sun Microsystems
               David Engel, Optical Data Systems
               Mike Erlinger, Lexcel
               Roger Fajman, NIH
               Daniel Fauvarque, Sun Microsystems
               Karen Frisa, CMU
               Shari Galitzer, MITRE
               Shawn Gallagher, Digital Equipment Corporation
               Richard Graveman, Bellcore
               Maria Greene, Xyplex, Inc.





          Case, McCloghrie, Rose & Waldbusser                  [Page 11]





          RFC 1452    Coexistence between SNMPv1 and SNMPv2   April 1993


               Michel Guittet, Apple
               Robert Gutierrez, NASA
               Bill Hagerty, Cabletron Systems
               Gary W. Haney, Martin Marietta Energy Systems
               Patrick Hanil, Nokia Telecommunications
               Matt Hecht, SNMP Research, Inc.
               Edward A. Heiner, Jr., Synernetics Inc.
               Susan E. Hicks, Martin Marietta Energy Systems
               Geral Holzhauer, Apple
               John Hopprich, DAVID Systems, Inc.
               Jeff Hughes, Hewlett-Packard
               Robin Iddon, Axon Networks, Inc.
               David Itusak
               Kevin M. Jackson, Concord Communications, Inc.