Re: coex draft last call -- review of changes since RFC 2576

After reviewing all the substantive changes in the coex draft
draft-ietf-snmpv3-coex-v2-02.txt relative to RFC 2576 I find
that I agree with all but the following one to to bullet (6)
of Section 3.2.  The top part is what it says in RFC 2576, and the
bottom part is what it says in draft-ietf-snmpv3-coex-v2-02.txt:

***************
*** 759,765 ****
     (6)  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).
--- 761,768 ----
     (6)  The SNMPv1 variable-bindings SHALL be the SNMPv2 variable-
!         bindings, with the variable-bindings containing sysUpTime.0,
!         snmpTrapOID.0, and snmpTrapAddress.0 removed.  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).


The difference is that the draft says "the SNMPv2 variable-bindings,
with the variable-bindings containing sysUpTime.0, snmpTrapOID.0,
and snmpTrapAddress.0 removed" where RFC 2576 just says
"the SNMPv2 variable-bindings."

Now, Section 3 of the draft says:

   SNMPv2 notification parameters consist of:

       -  A sysUpTime parameter (TimeTicks).  This appears in the first
          variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.

       -  An snmpTrapOID parameter (OBJECT IDENTIFIER).  This appears in
          the second variable-binding in an SNMPv2-Trap-PDU or
          InformRequest-PDU, and is equal to the value portion of that
          variable-binding (not the name portion, as both the name and
          value are OBJECT IDENTIFIERs).

       -  A list of variable-bindings (VarBindList).  This refers to all
          but the first two variable-bindings in an SNMPv2-Trap-PDU or
          InformRequest-PDU.

RFC 2576 says essentially the same thing, modulo clarifications in the
2nd bullet.

This means that, by definition, "the SNMPv2 variable-bindings" already
excludes the the first two variable-bindings, which are the ones that
contain sysUpTime.0 and snmpTrapOID.0.  The third varbind mentioned,
snmpTrapAddress.0, is one of three that would be added by a proxy
when translating an SNMPv1 trap to an SNMPv2 notification (the other
two are snmpTrapCommunity.0 and snmpTrapEnterprise.0).  It does not
even exist in a natively-generated SNMPv2 notification.

I recommend that the text be changed back to what it said in RFC 2576.

//cmh