RE: clarification request: V2->V1 Trap conversion

The value of the last subidentifier in snmpTrapOID is preserved in the
"specific-trap" field of the SNMPv1 Trap PDU.

   (4)  If the SNMPv2 snmpTrapOID parameter is one of the standard traps
        as defined in RFC1907 [12], the SNMPv1 specific-trap parameter
        SHALL be set to zero.  Otherwise, the SNMPv1 specific-trap
        parameter SHALL be set to the last sub-identifier of the SNMPv2
        snmpTrapOID parameter..

On Thu, 21 Nov 2002, Donati Andrew-MGIA0477 wrote:

> Date: Thu, 21 Nov 2002 11:00:34 -0500
> From: Donati Andrew-MGIA0477 <[email protected]>
> To: 'Dave Shield' <[email protected]>,
>      Chris Elliott <[email protected]>
> Cc: [email protected]
> Subject: RE: clarification request: V2->V1 Trap conversion
>
> All,
>
> Relating to these questions, I have a question on how the snmpTrapOID in
> snmpv2 is translated to snmpv1.
> RFC 2576 states;
>
> "If the next-to-last sub-identifier of the snmpTrapOID is
> zero, then the SNMPv1 enterprise SHALL be the SNMPv2
> snmpTrapOID with the last 2 sub-identifiers removed"
>
> This is fine except for the case where the last subidentifier identifies a
> different trap.
> There are cases where multiple non-standard traps are defined using a common
> prefix and are (individually) uniquely identified by the last subidentifer.
> How does the SNMPv1 enterprise varibind uniquely identify the trap in this
> case ?
>
> Thanks,
> Andy
>
>
> How can we
>
> ---Below is a section from RFC 2576:
>
> 3.2.  Translating SNMPv2 Notification Parameters to SNMPv1 Notification
>       Parameters
>         ...
>
>       -  If the SNMPv2 snmpTrapOID parameter is not one of the standard
>          traps as defined in RFC1907 [12], then the SNMPv1 enterprise
>          parameter SHALL be determined from the SNMPv2 snmpTrapOID
>          parameter as follows:
>
>          -  If the next-to-last sub-identifier of the snmpTrapOID is
>             zero, then the SNMPv1 enterprise SHALL be the SNMPv2
>             snmpTrapOID with the last 2 sub-identifiers removed,
>             otherwise
>
>          -  If the next-to-last sub-identifier of the snmpTrapOID is
>             non-zero, then the SNMPv1 enterprise SHALL be the SNMPv2
>             snmpTrapOID with the last sub-identifier removed.
>
> -----Original Message-----
> From: Dave Shield [mailto:[email protected]]
> Sent: Thursday, November 21, 2002 9:52 AM
> To: Chris Elliott
> Cc: [email protected]
> Subject: Re: clarification request: V2->V1 Trap conversion
>
>
>
> > Look at section 3, which states:
> >
> > ...
> >       -  A list of variable-bindings (VarBindList).  This refers to all
> >          but the first two variable-bindings in an SNMPv2-Trap-PDU or
> >          InformRequest-PDU.
> > ...
> >
> > This is the list that 3.2 is refering to. So, from this it is clear that
> > this list does not include sysUpTime or snmpTrapOID.
>
> OK - that seems fair enough.
> It would certainly seem more natural not to include this duplicated
> information in the v1 trap.    And given Mike Daniel's comments about 2089
> and coex-v2-01, it seems that this was the intended behaviour all along.
>    Time for some re-coding, methinks....
>
> Thanks to you and Paul for pointing this out this clause.
>
>
>
> > There is not a snmpTrapEnterprise varbind.
>
> Ummm.... are you sure?
>
> Section 3.2 includes:
>
>   (1)  If the SNMPv2 snmpTrapOID parameter is one of the standard
>          traps as defined in RFC1907 [12], then the SNMPv1 enterprise
>          parameter SHALL be set to the value of the variable-binding in
>          the SNMPv2 variable-bindings whose name is snmpTrapEnterprise.0
>          if that variable-binding exists.....
>
> and the V1->V2 mapping in section 3.1 concludes with:
>
>   (4) The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-
>         bindings.  In addition.....  The name portion of the
>         third additional variable binding SHALL contain
>         snmpTrapEnterprise.0 [12], and the value SHALL be the SNMPv1
>         enterprise parameter.
>
>
> So it's at least *possible* that there could be an snmpTrapEnterprise
> varbind. which either needs to be removed, or will end up duplicating
> the v1 enterprise parameter.
>   RFC 2089 talks about removing this, so I presume coex-v2-01 does too.
> (Or at least, that's probably the intended behaviour).
>
>
>
> But thanks for the clarification anyway.
>
> 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
>
>

--
Michael Kirkham
www.muonics.com