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