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

On Thu, 9 Jan 2003, Dave Shield wrote:

[ discussing changes in bullet (6) of Section 3.2 ]

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

Point taken.  However, let me bring to your attention the fact that the
phrase "the SNMPv2 variable-bindings" is also used that way in at least
oe other place:

3.1.  Translating SNMPv1 Notification Parameters to SNMPv2 Notification
Parameters
[ ... ]
(4)  The SNMPv2 variable-bindings SHALL be the SNMPv1 variable-bindings.

Whatever resolution is made, the terminology SHOULD be consistent :)

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

To be completely correct, I should have said "may not exist" instead
of "does not exist" in that statement.  A notification generator may,
at its discretion, include extra varbinds that aren't mentioned in
the VARIABLES or OBJECTS of the trap or notification definition.  In
principle snmpTrapAddress.0, snmpTrapCommunity.0, and
snmpTrapEnterprise.0 could be among them.

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

There is no need to remove snmpTrapAddress.0, snmpTrapCommunity.0, or
snmpTrapEnterprise.0, and in fact it's best NOT to.  There's no need
to remove them is because it's always legal for an agent to tack on
extra varbinds, so the presence of these variables won't confuse a
properly-implemented notification receiver.   Leaving them in place
ensures that you need to add them only at the first proxy translation,
and it's _essential_ to leave snmpTrapCommunity.0 if you want the final
destination to be able to properly reconstruct the original commmunity
string after the trap has gone through a chain of proxies like that
shown below.

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

The draft aleady does this, I think.

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

In a subsequent message Dave Shield wrote:

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

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

            =============================================

In order to find out why the instruction to remove snmpTrapAddress.0
was added to 3.2(6) I searched in the snmpv3 mailing list archives
since January 2000, and all that I found was this:

On Wed, 7 Feb 2001, David Levi wrote:
> - clarify section 3.2 paragraph 6, that the snmpv2 variable-bindings
>   with sysUpTime.0,nmpTrapOID.0. and snmpTrapAddress.0 stripped out,
>   are what is used for the snmpv1 variable-bindings

If all that had been said was "clarify ... that the snmpv2
variable-bindings with sysUpTime.0 and snmpTrapOID.0 stripped out
are what is used for the snmpv1 variable-bindings" then it would be
OK as a clarification because it would not be changing the meaning
of the spec.  But the previous version of the spec did _not_ say to
remove snmpTrapAddress.0, and mentioning it amounts to a _change_ in
the spec not a clarification.  I conjecture that its mention here was
just a mistake that nobody caught at the time.

Bottom line:  I think the instruction in 3.2(6) to remove
snmpTrapAddress.0 is an unwarranted change at this point, and I
recommend that it be taken out.  However, I understand the desire
to clarify the meaning of "the SNMPv2 variable-bindings".  The
same clarification should be applied to 3.1(4) and 3.2(6).  Thus:

How about changing "the SNMPv2 variable-bindings" in 3.1(4) and
"the SNMPv2 variable-bindings, with the variable-bindings containing
sysUpTime.0, snmpTrapOID.0, and snmpTrapAddress.0 removed" in 3.2(6) to
"the SNMPv2 variable-bindings (excluding sysUpTime.0 and snmpTrapOID.0)" ?

//cmh