Re: clarification request: V2->V1 Trap conversion

I interpret the 'SNMPv2 variable-bindings' in RFC2576 section 3.2(6) as a
reference to the 'SNMPv2 notification parameter consisting of a list of
variable-bindings' as defined at the beginning of section 3.:

[RFC2576]
3.  Translating Notifications Parameters
...
   SNMPv2 notification parameters consist of:
      ...
      -  A list of variable-bindings (VarBindList).  This refers to all
         but the first two variable-bindings in an SNMPv2-Trap-PDU or
         InformRequest-PDU.
--
$0.02,
Paul

Dave Shield wrote:

> A quick question about an issue that's come up on the Net-SNMP coding list.
>
> When converting an SNMPv2 notification PDU into an SNMPv1 trap, the
> original varbind list will include varbinds for sysUpTime, snmpTrapOID
> and snmpTrapEnterprise.  Section 3.2 RFC 2576 describes how to use these
> to determine the appropriate values for the SNMPv1 trap header fields,
> and then says:
>
>    (6)  The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
>         bindings.   [... mumble mumble Counter64 mumble ....]
>
> This variable-bindings list would appear to still include the sysUpTime,
> snmpTrapOID and snmpTrapEnterprise varbinds.   (Or at least, I can't
> immediately spot anywhere that says these varbinds should be removed).
> The effect is that this information effectively ends up being duplicated.
> Is this correct ?
>
>   The Net-SNMP master agent treats incoming AgentX notifications as if
> they were SNMPv2 notifications, so applies the same mappings when
> sending to SNMPv1 destinations.   This means that subagent-generated
> notifications end up with the same duplication of information.
>    I realise this isn't strictly an SNMPv3-related issue, but does
> this approach strike people as:
>         a) reasonable
>         b) valid
> ?
>
> Dave
> --
> Dave Shield                   [email protected]
> Dept. of Computer Science,
> Liverpool University,        "He who brings [computers] on to his premises
> PO Box 147,                   should be absolutely liable ... for any mischief
> Liverpool, L69 7ZF            that ensues."     Haddock v. Computer 1578/32/W1