Re: WG last call: Coex draft

Hi-

"Harrington, David" wrote:

> We need more technical review of this document. If you review the document (reasonably thoroughly) and find nothing to object to, please post a comment to the mailing list stating that you have done such a review.

I had posted an observation regarding technical discrepancie with respect to the coex draft on this email list 11/22/2002 (thread="clarification request: V2->V1 Trap conversion")

Perhaps someone could address these concerns during last call?

Regards,

Mark

================ referenced email below =====================

    From:  Mark Ellison <[email protected]>             11/22/2002 9:01 AM
 Subject:  Re: clarification request: V2->V1 Trap conversion
         To: [email protected]

Mike Daniele wrote:

> Juergen Schoenwaelder wrote:
> ...
> > Well, RFC 1215 says in section 2.1.2:
> >
> >    The VARIABLES clause, which need not be present, defines the ordered
> >    sequence of MIB objects which are contained within every instance of
> >    the trap type.  Each variable is placed, in order, inside the
> >    variable-bindings field of the SNMP Trap-PDU.  Note that at the
> >    option of the agent, additional variables may follow in the
> >    variable-bindings field.
> >
> > The text says that optional varbind can be appended - not that they
> > can be prepended. I would not be surprised if there are deployed trap
> > receivers that do expect that for example ifIndex is in the first
> > varbind in a linkDown or linkUp trap. So to be safe, I would recommend
> > (whether that is written down or not) to remove the snmpTrapOID and
> > snmpTrapEnterprise varbinds when sending SNMPv1 PDUs. In fact, this is
> > what I implemented in the scotty package does a notification must be
> > shipped via SNMPv1.
>
> This must be a bug in RFC 2576.
>
> RFC 2089 said
>
>     2.  The 3 special varBinds in the varBindList of an SNMPv2 trap
>         (sysUpTime.0 (TimeTicks), snmpTrapOID.0 (OBJECT IDENTIFIER) and
>         optionally snmpTrapEnterprise.0 (OBJECT IDENTIFIER)) are
>         removed from the varBindList to be sent with the SNMPv1 trap.
>         These 2 (or 3) varBinds are used to decide how to set other
>         fields in the SNMPv1 trap PDU as follows:
>
> (You need to remove sysUpTime.0 as well.)
>
> Mike

There is another significant difference between 2089 and 2576 with
respect to objects with a syntax of Counter64:

Whereas 2089 section 3.3 step (1) says:

        "If any of the varBinds in the varBindList has an SNMPv2 syntax
         of Counter64, then such varBinds are implicitly considered to
         be not in view, and so they are removed from the varBindList to
         be sent with the SNMPv1 trap."

2576 section 3.2 step (6) says:

        "The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
        bindings.  Note, however, that if the SNMPv2 variable-bindings
        contain any objects whose type is Counter64, the translation to
        SNMPv1 notification parameters cannot be performed.  In this
        case, the notification cannot be encoded in an SNMPv1 packet
        (and so the notification cannot be sent using SNMPv1, see
        section 4.1.3 and section 4.2)."

So, an agent following 2089 would omit the Counter64 object from the
varbindlist yet send an SNMPv1 trap, while an agent following 2576 would
not send the SNMPv1 trap at all.

Note that draft-ietf-snmpv3-coex-v2 is consistent with 2576.

Regards,

Mark