home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2089 < prev    next >
Text File  |  1997-01-27  |  24KB  |  676 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          B. Wijnen
  8. Request for Comments: 2089                                           IBM
  9. Category: Informational                                          D. Levi
  10.                                                       SNMP Research, Inc
  11.                                                             January 1997
  12.  
  13.                                  V2ToV1
  14.                        Mapping SNMPv2 onto SNMPv1
  15.                      within a bi-lingual SNMP agent
  16.  
  17. Status of this Memo
  18.  
  19.    This memo provides information for the Internet community.  This memo
  20.    does not specify an Internet standard of any kind.  Distribution of
  21.    this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    The goal of this memo is to document a common way of mapping an
  26.    SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP
  27.    agent (one that supports both SNMPv1 and SNMPv2).
  28.  
  29. Table of Contents
  30.  
  31.      1.0  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
  32.      2.0  Mapping SNMPv2 into SNMPv1  . . . . . . . . . . . . . . . .  2
  33.      2.1  Mapping SNMPv2 error-status into SNMPv1 error-status  . . .  3
  34.      2.2  Mapping SNMPv2 exceptions into SNMPv1   . . . . . . . . . .  3
  35.      2.3  Mapping noSuchObject and noSuchInstance   . . . . . . . . .  4
  36.      2.4  Mapping endOfMibView  . . . . . . . . . . . . . . . . . . .  5
  37.      2.5  Mapping SNMPv2 SMI into SNMPv1  . . . . . . . . . . . . . .  5
  38.      3.0  Processing SNMPv1 requests  . . . . . . . . . . . . . . . .  6
  39.      3.1  Processing an SNMPv1 GET request  . . . . . . . . . . . . .  6
  40.      3.2  Processing an SNMPv1 GETNEXT request  . . . . . . . . . . .  7
  41.      3.3  Processing an outgoing SNMPv2 trap  . . . . . . . . . . . .  8
  42.      4.0  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . 10
  43.      5.0  References  . . . . . . . . . . . . . . . . . . . . . . . . 10
  44.      6.0  Security Considerations   . . . . . . . . . . . . . . . . . 10
  45.      7.0  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . 11
  46.      Appendix A.  Background Information  . . . . . . . . . . . . .   12
  47.      A.1  Mapping of error-status Values  . . . . . . . . . . . . .   12
  48.      A.2  SNMPv1 traps without Counter64 varBinds.  . . . . . . . .   12
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Wijnen & Levi                Informational                      [Page 1]
  59.  
  60. RFC 2089                         V2toV1                     January 1997
  61.  
  62.  
  63. 1.0  Introduction
  64.  
  65.    We now have the SNMPv1 protocol (RFC1157 [1]) as a full standard and
  66.    the SNMPv2 protocol (RFC1905 [1]) as a DRAFT standard.  It can be
  67.    expected that many agent implementations will support both SNMPv1 and
  68.    SNMPv2 requests coming from SNMP management entities.  In many cases
  69.    the underlying instrumentation will be implemented using the new
  70.    SNMPv2 SMI and SNMPv2 protocol.  The SNMP engine then gets the task
  71.    to ensure that any SNMPv2 response data coming from such SNMPv2
  72.    compliant instrumentation gets converted to a proper SNMPv1 response
  73.    if the original request came in as an SNMPv1 request.  The SNMP
  74.    engine should also deal with mapping SNMPv2 traps which are generated
  75.    by an application or by the SNMPv2 compliant instrumentation into
  76.    SNMPv1 traps if the agent has been configured to send traps to an
  77.    SNMPv1 manager.
  78.  
  79.    It seems beneficial if all such agents do this mapping in the same
  80.    way. This document describes such a mapping based on discussions and
  81.    perceived consensus on the various mailing lists.  The authors of
  82.    this document have also compared their own implementations of these
  83.    mappings. They had a few minor differences and decided to make their
  84.    implementation behave the same and document this mapping so others
  85.    can benefit from it.
  86.  
  87.    We recommend that all agents implement this same mapping.
  88.  
  89.    Note that the mapping described in this document should also be
  90.    followed by SNMP proxies that provide a mapping between SNMPv1
  91.    management applications and SNMPv2 agents.
  92.  
  93. 2.0  Mapping SNMPv2 into SNMPv1
  94.  
  95.    These are the type of mappings that we need:
  96.  
  97.      o   Mapping of the SNMPv2 error-status into SNMPv1 error-status
  98.  
  99.      o   Mapping of the SNMPv2 exceptions into SNMPv1 error-status
  100.  
  101.      o   Skipping object instances that have a non-SNMPv1 Syntax
  102.          (specifically Counter64)
  103.  
  104.      o   Mapping of SNMPv2 traps into SNMPv1 traps
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Wijnen & Levi                Informational                      [Page 2]
  115.  
  116. RFC 2089                         V2toV1                     January 1997
  117.  
  118.  
  119. 2.1  Mapping SNMPv2 error-status into SNMPv1 error-status
  120.  
  121.    With the new SNMPv2 protocol (RFC1905 [1]) we get a set of error-
  122.    status values that return the cause of an error in much more detail.
  123.    But an SNMPv1 manager does not understand such error-status values.
  124.  
  125.    So, when the instrumentation code returns response data and uses an
  126.    SNMPv2 error-status to report on the success or failure of the
  127.    requested operation and if the original SNMP request is an SNMPv1
  128.    request, then we must map such an error-status into an SNMPv1 error-
  129.    status when composing the SNMP response PDU.
  130.  
  131.    The SNMPv2 error status is mapped to an SNMPv1 error-status using
  132.    this table:
  133.  
  134.              SNMPv2 error-status    SNMPv1 error-status
  135.              ===================    ===================
  136.              noError                noError
  137.              tooBig                 tooBig
  138.              noSuchName             noSuchName
  139.              badValue               badValue
  140.              readOnly               readOnly
  141.              genErr                 genErr
  142.              wrongValue             badValue
  143.              wrongEncoding          badValue
  144.              wrongType              badValue
  145.              wrongLength            badValue
  146.              inconsistentValue      badValue
  147.              noAccess               noSuchName
  148.              notWritable            noSuchName
  149.              noCreation             noSuchName
  150.              inconsistentName       noSuchName
  151.              resourceUnavailable    genErr
  152.              commitFailed           genErr
  153.              undoFailed             genErr
  154.              authorizationError     noSuchName
  155.  
  156. 2.2  Mapping SNMPv2 exceptions into SNMPv1
  157.  
  158.    In SNMPv2 we have so called exception values. These will allow an
  159.    SNMPv2 response PDU to return as much management information as
  160.    possible, even if one or more of the requested variables do not
  161.    exist.  SNMPv1 does not support exception values, and thus does not
  162.    return the value of management information when any error occurs.
  163.  
  164.    When multiple variables do not exist, an SNMPv1 agent can return only
  165.    a single error and index of a single variable.  The agent determines
  166.    by its implementation strategy which variable to identify as the
  167.  
  168.  
  169.  
  170. Wijnen & Levi                Informational                      [Page 3]
  171.  
  172. RFC 2089                         V2toV1                     January 1997
  173.  
  174.  
  175.    cause of the error via the value of the error-index field. Thus, an
  176.    SNMPv1 manager may make no assumption on the validity of the other
  177.    variables in the request.
  178.  
  179.    So, when an SNMPv1 request is received, we must check the varBinds
  180.    returned from SNMPv2 compliant instrumentation for exception values,
  181.    and convert these exception values into SNMPv1 error codes.
  182.  
  183.    The type of exception we can get back and the action we must take
  184.    depends on the SNMP operation that is requested.
  185.  
  186.      o   For SNMP GET requests we can get back noSuchObject and
  187.          noSuchInstance.
  188.  
  189.      o   For SNMP GETNEXT requests we can get back endOfMibView.
  190.  
  191.      o   For SNMP SET requests we cannot get back any exceptions.
  192.  
  193.      o   For SNMP GETBULK requests we can get back endOfMibView, but
  194.          such a request should only come in as an SNMPv2 request, so we
  195.          do not have to worry about any mapping onto SNMPv1.  If a
  196.          GETBULK comes in as an SNMPv1 request, it is treated as an
  197.          error and the packet is dropped.
  198.  
  199. 2.3  Mapping noSuchObject and noSuchInstance
  200.  
  201.    A noSuchObject or noSuchInstance exception generated by SNMPv2
  202.    compliant instrumentation indicates that the requested object
  203.    instance can not be returned.  The SNMPv1 error code for this
  204.    condition is noSuchName, and so the error-status field of the
  205.    response PDU should be set to noSuchName.  Also, the error-index
  206.    field is set to the index of the varBind for which an exception
  207.    occurred, and the varBind list from the original request is returned
  208.    with the response PDU.
  209.  
  210.    Note that when the response contains multiple exceptions, that the
  211.    agent may pick any one to be returned.
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Wijnen & Levi                Informational                      [Page 4]
  227.  
  228. RFC 2089                         V2toV1                     January 1997
  229.  
  230.  
  231. 2.4  Mapping endOfMibView
  232.  
  233.    When SNMPv2 compliant instrumentation returns a varBind containing an
  234.    endOfMibView exception in response to a GETNEXT request, it indicates
  235.    that there are no object instances available which lexicographically
  236.    follow the object in the request. In an SNMPv1 agent, this condition
  237.    normally results in a noSuchName error, and so the error-status field
  238.    of the response PDU should be set to noSuchName. Also, the error-
  239.    index field is set to the index of the varBind for which an exception
  240.    occurred, and the varBind list from the original request is returned
  241.    with the response PDU.
  242.  
  243.    Note that when the response contains multiple exceptions, that the
  244.    agent may pick any one to be returned.
  245.  
  246. 2.5  Mapping SNMPv2 SMI into SNMPv1
  247.  
  248.    The SNMPv2 SMI (RFC1902 [2]) defines basically one new syntax that is
  249.    problematic for SNMPv1 managers. That is the syntax Counter64.  All
  250.    the others can be handled by SNMPv1 managers.
  251.  
  252.    The net impact on bi-lingual agents is that they should make sure
  253.    that they never return a varBind with a Counter64 value to an SNMPv1
  254.    manager.
  255.  
  256.    The best accepted practice is to consider such object instances
  257.    implicitly excluded from the view.  So:
  258.  
  259.      o   On an SNMPv1 GET request, we return an error-status of
  260.          noSuchName and the error-index is set to the varBind that
  261.          causes this error.
  262.  
  263.      o   On an SNMPv1 GETNEXT request, we skip the object instance and
  264.          fetch the next object instance that follows the one with a
  265.          syntax of Counter64.
  266.  
  267.      o   Any SET request that has a varBind with a Counter64 value must
  268.          have come from a SNMPv2 manager, and so it should not cause a
  269.          problem.  If we do receive a Counter64 value in an SNMPv1 SET
  270.          packet, it should result in an ASN.1 parse error since
  271.          Counter64 is not valid in the SNMPv1 protocol. When an ASN.1
  272.          parse error occurs, the counter snmpInASNParseErrs is
  273.          incremented and no response is returned.
  274.  
  275.      o   The GETBULK is an SNMPv2 operation, so it should never come
  276.          from an SNMPv1 manager.  If we do receive a GETBULK PDU from in
  277.          an SNMPv1 packet, then we consider it an invalid PDU-type and
  278.          we drop the packet.
  279.  
  280.  
  281.  
  282. Wijnen & Levi                Informational                      [Page 5]
  283.  
  284. RFC 2089                         V2toV1                     January 1997
  285.  
  286.  
  287. 3.0  Processing SNMPv1 requests
  288.  
  289.    This sections contains a step by step description of how to handle
  290.    SNMPv1 requests in an agent where the underlying instrumentation code
  291.    is SNMPv2 compliant.
  292.  
  293. 3.1  Processing an SNMPv1 GET request
  294.  
  295.    First, the request is converted into a call to the underlying
  296.    instrumentation. This is implementation specific.
  297.  
  298.    When such instrumentation returns response data using SNMPv2 syntax
  299.    and error-status values, then:
  300.  
  301.    1.  If the error-status is anything other than noError,
  302.  
  303.          a.  The error status is translated to an SNMPv1 error-status
  304.              using the table from 2.1, "Mapping SNMPv2 error-status into
  305.              SNMPv1 error-status" on page 2
  306.  
  307.          b.  The error-index is set to the position (in the original
  308.              request) of the varBind that caused the error-status.
  309.  
  310.          c.  The varBindList of the response PDU is made exactly the
  311.              same as the varBindList that was received in the original
  312.              request.
  313.  
  314.     2.  If the error-status is noError, then find any varBind that
  315.         contains an SNMPv2 exception (noSuchObject or noSuchInstance)
  316.         or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64).
  317.         (Note that if there are more than one, the agent may choose any
  318.         such varBind.)  If there are any such varBinds, then for the
  319.         one chosen:
  320.  
  321.          a.  Set the error-status to noSuchName
  322.  
  323.          b.  Set the error-index to the position (in the varBindList of
  324.              the original request) of the varBind that returned such an
  325.              SNMPv2 exception or syntax.
  326.  
  327.          c.  Make the varBindList of the response PDU exactly the same
  328.              as the varBindList that was received in the original
  329.              request.
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Wijnen & Levi                Informational                      [Page 6]
  339.  
  340. RFC 2089                         V2toV1                     January 1997
  341.  
  342.  
  343.      3.  If there are no such varBinds, then:
  344.  
  345.          a.  Set the error-status to noError
  346.  
  347.          b.  Set the error-index to zero
  348.  
  349.          c.  Compose the varBindList of the response, using the data as
  350.              it is returned by the instrumentation code.
  351.  
  352. 3.2  Processing an SNMPv1 GETNEXT request
  353.  
  354.    First, the request is converted into a call to the underlying
  355.    instrumentation. This is implementation specific.  There may be
  356.    repetitive calls to (possibly different pieces of) instrumentation
  357.    code to try to find the first object which lexicographically follows
  358.    each of the objects in the request.  Again, this is implementation
  359.    specific.
  360.  
  361.    When the instrumentation finally returns response data using SNMPv2
  362.    syntax and error-status values, then:
  363.  
  364.      1.  If the error-status is anything other than noError,
  365.  
  366.          a.  The error status is translated to an SNMPv1 error-status
  367.              using the table from 2.1, "Mapping SNMPv2 error-status into
  368.              SNMPv1 error-status" on page 2
  369.  
  370.          b.  The error-index is set to the position (in the original
  371.              request) of the varBind that caused the error-status.
  372.  
  373.          c.  The varBindList of the response PDU is made exactly the
  374.              same as the varBindList that was received in the original
  375.              request.
  376.  
  377.      2.  If the error-status is noError, then:
  378.  
  379.          a.  If there are any varBinds containing an SNMPv2 syntax of
  380.              Counter64, then consider these varBinds to be not in view
  381.              and repeat the call to the instrumentation code as often as
  382.              needed till a value other than Counter64 is returned.
  383.  
  384.          b.  Find any varBind that contains an SNMPv2 exception
  385.              endOfMibView.  (Note that if there are more than one, the
  386.              agent may choose any such varBind.)  If there are any such
  387.              varBinds, then for the one chosen:
  388.  
  389.              1)  Set the error-status to noSuchName
  390.  
  391.  
  392.  
  393.  
  394. Wijnen & Levi                Informational                      [Page 7]
  395.  
  396. RFC 2089                         V2toV1                     January 1997
  397.  
  398.  
  399.              2)  Set the error-index to the position (in the varBindList
  400.                  of the original request) of the varBind that returned
  401.                  such an SNMPv2 exception.
  402.  
  403.              3)  Make the varBindList of the response PDU exactly the
  404.                  same as the varBindList that was received in the
  405.                  original request.
  406.  
  407.          c.  If there are no such varBinds, then:
  408.  
  409.              1)  Set the error-status to noError
  410.  
  411.              2)  Set the error-index to zero
  412.  
  413.              3)  Compose the varBindList of the response, using the data
  414.                  as it is returned by the instrumentation code.
  415.  
  416. 3.3  Processing an outgoing SNMPv2 TRAP
  417.  
  418.    If SNMPv2 compliant instrumentation presents an SNMPv2 trap to the
  419.    SNMP engine and such a trap passes all regular checking and then is
  420.    to be sent to an SNMPv1 destination, then the following steps must be
  421.    followed to convert such a trap to an SNMPv1 trap.  This is basically
  422.    the reverse of the SNMPv1 to SNMPv2 mapping as described in RFC1908
  423.    [3].
  424.  
  425.      1.  If any of the varBinds in the varBindList has an SNMPv2 syntax
  426.          of Counter64, then such varBinds are implicitly considered to
  427.          be not in view, and so they are removed from the varBindList to
  428.          be sent with the SNMPv1 trap.
  429.  
  430.      2.  The 3 special varBinds in the varBindList of an SNMPv2 trap
  431.          (sysUpTime.0 (TimeTicks), snmpTrapOID.0 (OBJECT IDENTIFIER) and
  432.          optionally snmpTrapEnterprise.0 (OBJECT IDENTIFIER)) are
  433.          removed from the varBindList to be sent with the SNMPv1 trap.
  434.          These 2 (or 3) varBinds are used to decide how to set other
  435.          fields in the SNMPv1 trap PDU as follows:
  436.  
  437.          a.  The value of sysUpTime.0 is copied into the timestamp field
  438.              of the SNMPv1 trap.
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Wijnen & Levi                Informational                      [Page 8]
  451.  
  452. RFC 2089                         V2toV1                     January 1997
  453.  
  454.  
  455.          b.  If the snmpTrapOID.0 value is one of the standard traps the
  456.              specific-trap field is set to zero and the generic trap
  457.              field is set according to this mapping:
  458.  
  459.                 value of snmpTrapOID.0                generic-trap
  460.                 ===============================       ============
  461.                 1.3.6.1.6.3.1.1.5.1 (coldStart)                  0
  462.                 1.3.6.1.6.3.1.1.5.2 (warmStart)                  1
  463.                 1.3.6.1.6.3.1.1.5.3 (linkDown)                   2
  464.                 1.3.6.1.6.3.1.1.5.4 (linkUp)                     3
  465.                 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)      4
  466.                 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)            5
  467.  
  468.              The enterprise field is set to the value of
  469.              snmpTrapEnterprise.0 if this varBind is present, otherwise
  470.              it is set to the value snmpTraps as defined in RFC1907 [4].
  471.  
  472.          c.  If the snmpTrapOID.0 value is not one of the standard
  473.              traps, then the generic-trap field is set to 6 and the
  474.              specific-trap field is set to the last subid of the
  475.              snmpTrapOID.0 value.
  476.  
  477.              o   If the next to last subid of snmpTrapOID.0 is zero,
  478.                  then the enterprise field is set to snmpTrapOID.0 value
  479.                  and the last 2 subids are truncated from that value.
  480.              o   If the next to last subid of snmpTrapOID.0 is not zero,
  481.                  then the enterprise field is set to snmpTrapOID.0 value
  482.                  and the last 1 subid is truncated from that value.
  483.  
  484.              In any event, the snmpTrapEnterprise.0 varBind (if present)
  485.              is ignored in this case.
  486.  
  487.      3.  The agent-addr field is set with the appropriate address of the
  488.          the sending SNMP entity, which is the IP address of the sending
  489.          entity of the trap goes out over UDP; otherwise the agent-addr
  490.          field is set to address 0.0.0.0.
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Wijnen & Levi                Informational                      [Page 9]
  507.  
  508. RFC 2089                         V2toV1                     January 1997
  509.  
  510.  
  511. 4.0  Acknowledgements
  512.  
  513.    The authors wish to thank the contributions of the SNMPv2 Working
  514.    Group in general.  Special thanks for their detailed review and
  515.    comments goes to these individuals:
  516.  
  517.        Mike Daniele (DEC)
  518.        Dave Harrington (Cabletron)
  519.        Brian O'Keefe (Hewlett Packard)
  520.        Keith McCloghrie (Cisco Systems)
  521.        Dave Perkins (independent)
  522.        Shawn Routhier (Epilogue)
  523.        Juergen Schoenwaelder (University of Twente)
  524.  
  525. 5.0  References
  526.  
  527.      [1]  Jeffrey  D. Case, Mark Fedor, Martin Lee Schoffstall and James
  528.           R. Davin, Simple  Network  Management  Protocol  (SNMP),  SNMP
  529.           Research,  Performance  Systems  International, MIT Laboratory
  530.           for Computer Science, RFC 1157, May 1990.
  531.  
  532.      [2]  Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
  533.           Waldbusser, Structure of Managment Information for  Version  2
  534.           of  the  Simple  Network  Management  Protocol  (SNMPv2), SNMP
  535.           Research Inc, Cisco Systems Inc, Dover Beach  Consulting  Inc,
  536.           International Network Services, RFC1902, January 1996.
  537.  
  538.      [3]  Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
  539.           Waldbusser, Coexistence between Version 1 and Version 2 of the
  540.           Internet-standard  Network Management Framework, SNMP Research
  541.           Inc,  Cisco  Systems  Inc,   Dover   Beach   Consulting   Inc,
  542.           International Network Services, RFC1908, January 1996.
  543.  
  544.      [4]  Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
  545.           Waldbusser,  Management  Information Base for Version 2 of the
  546.           Simple Network Management  Protocol  (SNMPv2),  SNMP  Research
  547.           Inc,   Cisco   Systems   Inc,   Dover  Beach  Consulting  Inc,
  548.           International Network Services, RFC1907, January 1996.
  549.  
  550. 6.0  Security Considerations
  551.  
  552.    Security considerations are not discussed in this memo.
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Wijnen & Levi                Informational                     [Page 10]
  563.  
  564. RFC 2089                         V2toV1                     January 1997
  565.  
  566.  
  567. 7.0  Authors' Addresses
  568.  
  569.           Bert Wijnen
  570.           IBM International Operations
  571.           Watsonweg 2
  572.           1423 ND Uithoorn
  573.           The Netherlands
  574.  
  575.           Phone: +31-079-322-8316
  576.           E-mail: wijnen@vnet.ibm.com
  577.  
  578.  
  579.           David Levi
  580.           SNMP Research, Inc
  581.           3001 Kimberlin Heights Rd.
  582.           Knoxville, TN 37920-9716
  583.           USA
  584.  
  585.           Phone: +1-615-573-1434
  586.           E-mail: levi@snmp.com
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Wijnen & Levi                Informational                     [Page 11]
  619.  
  620. RFC 2089                         V2toV1                     January 1997
  621.  
  622.  
  623. APPENDIX A.  Background Information
  624.  
  625.    Here follows some reasoning as to why some choices were made.
  626.  
  627.    A.1  Mapping of error-status values
  628.  
  629.    The mapping of SNMPv2 error-status values to SNMPv1 error-status
  630.    values is based on the common interpretation of how an SNMPv1 entity
  631.    should create an error-status value based on the elements of
  632.    procedure defined in RFC1157 [1].
  633.  
  634.    There was a suggestion to map wrongEncoding into genErr, because it
  635.    could be caused by an ASN.1 parsing error.  Such maybe true, but in
  636.    most cases when we detect the ASN.1 parsing error, we do not yet know
  637.    about the PDU data yet.  Most people who responded to our queries
  638.    have implemented the mapping to a badValue. So we "agreed" on the
  639.    mapping to badValue.
  640.  
  641.  
  642.    A.2  SNMPv1 Traps without Counter64 varBinds.
  643.  
  644.    RFC1448 says that if one of the objects in the varBindList is not
  645.    included in the view, then the trap is NOT sent.  Current SNMPv2u and
  646.    SNMPv2* documents make the same statement.  However, the "rough
  647.    consensus" is that it is better to send partial information than no
  648.    information at all. Besides:
  649.  
  650.      o   RFC1448 does not allow for a TRAP to be sent with the varBinds
  651.          that are not included in the view removed, so it is an all or
  652.          nothing decision.
  653.  
  654.      o   We do NOT include the Counter64 varBinds... so the "not in
  655.          view" varBinds are not sent to the trap destination.
  656.  
  657.      o   The Counter64 objects are "implicit" not in view.  If any
  658.          objects are explicit not in view, then this is checked before
  659.          we do the conversion from an SNMPv2 trap to an SNMPv1 trap, and
  660.          so the trap is not sent at all.
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Wijnen & Levi                Informational                     [Page 12]
  675.  
  676.