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

> > 	p18:  3.2    bullet (6)
> > This description says to strip out snmpTrapAddress.0, but says
> > nothing about the other two varbind that may potentially have
> > been added - snmpTrapCommunity.0 and snmpTrapEnterprise.0.
> > 
> >   In particular, the snmpTrapEnterprise.0 varbind has already
> > been used to set the SNMPv1 enterprise notification parameter
> > (see 3.2 bullet(1) ).   Retaining it here would seem unnecessary,
> > so it would be sensible to remove this as well.
> 
> Although snmpTrapAddress.0 should ans snmpTrapEnterprise.0 are
> in principle reconstructable, the previous version of the spec
> said to leave them in.  Since this behaviour is harmless, I cannot
> see any reason to change to make that change now.


> >   Should the snmpTrapCommunity.0 varbind be retained or not?  Does
> > it make a difference whether this value is the same as the SNMPv1
> > community notification parameter on the outgoing notification?
> 
> That needs to stay in order to ensure that the original community
> string is available after a trap has passed through a proxy chain
> such as the one illustrated above.

Keeping all three would also have the advantage of being consistent,
I suppose.
  And according to 3.1(4), these snmpTrapAddress.0, snmpTrapCommunity.0 and
snmpTrapEnterprise.0 varbinds should only ever be appended once - correct?

  What happens if the incoming SNMPv1 notification already includes
one (or more) of these varbinds, and the values are inconsistent with
the corresponding SNMPv1 notification parameters?   i.e. the 'agent-addr'
(or 'enterprise') field says one thing, and the snmpTrapAddress.0
(or snmpTrapEnterprise.0) varbind says another.

  Should the proxy:
      a) replace the old varbind with the new value
		(dropping the old value completely)
      b) leave the old varbind as it stands
		(dropping the new value completely)
  or  c) append a second snmpTrap{xxx}.0 varbind
		(thus retaining both values)

According to the specification as it currently stands, the correct
behaviour would appear to be b) - yes?

This scenario is probably relatively unlikely for the snmpTrapAddress.0
or snmpTrapEnterprise.0 varbinds.   But it seems quite plausible for
the snmpTrapCommunity.0 varbind - depending on the appropriate response
to the following:

> >   How to handle snmpTrapCommunity.0 seems less obvious - in
> > particular, should the outgoing SNMPv1 notification use this
> > community name, or that determined from the proxy's own configuration
> > (e.g. the SNMP-COMMUNITY-MIB)?


Dave