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

On Fri, 10 Jan 2003, Dave Shield wrote:
> according to 3.1(4), these snmpTrapAddress.0, snmpTrapCommunity.0 and
> snmpTrapEnterprise.0 varbinds should only ever be appended once -
> correct?

That's my understanding.

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

That's also my understanding.

> 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)?

The latter:  according to the newly-added Section 5.2.4 the outgoing
community name is always taken from the SNMP-COMMUNITY-MIB.  Maintaining
the original community name in the snmpTrapCommunity varbind preserves the
original context for the entity that ultimately receives the notification.

//cmh