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.

	[snip]

> 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.

Strictly speaking, this may well be correct.

However, it is very easy to take "the SNMPv2 variable-bindings" to
mean the full list of variable bindings from the SNMPv2-Trap-PDU or
InformRequest-PDU - i.e. *including* the sysUpTime.0 and snmpTrapOID.0
bindings.    This may be a mistake, but it's an understandable one.

From an implementer's point of view, stating explicitly that these
two varbinds should be removed is *extremely* useful.   It may not
be strictly necessary, but it's definitely useful.   With the wording
as currently proposed, there's at least one widely-used open source
toolkit that might possibly have avoided this particular implementation
error.
   (Not that I speak from bitter experience here - perish the thought!)


>                                    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.

What happens if the notification is not a "natively-generated" one?
If there *is* a snmpTrapAddress.0 varbind in the variable-bindings
list, what should be done with it?   Similarly for snmpTrapCommunity.0
and snmpTrapEnterprise.0 ?

Ideally, this draft ought to be able to guide the appropriate behaviour
of "proxy chains", where a notification might switch from v1->v2->v1->v2...

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

I request that the text be left as it currently stands.

  (modulo clarification of snmpTrap{Community,Enterprise}.0 handling)

Dave