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