Right - the value of the index object(s) is included in the
OID instance qualifiers of all the other (regular, columnar)
trap bindings. Certainly, it's original inclusion in the
OBJECTS clause of the NOTIFICATION-TYPE macro was wrong.
But the darn thing has BEEN there for four years and a lot
of code is fielded that EXPECTS there to be this odd extra
index object in the trap.
It is also clear that new SMIv2 (RFC 2578-2580) and SNMPv3
specs state that 'not-accessible' objects SHALL not be
including in trap bindings. So the object has to change
its access OR the object has to be removed from the
Alert trap (with some breakage and some warnings from
existing client code, no doubt).
'accessible-for-notify' existed. But its use for an
index object is still invalid (in a new MIB - the
old SMIv1 typical usage of
'read-only' for index objects is grandfathered).
What to do? Just to get RFC 1759 to compile and to
avoid deleting a trap binding, we've changed it
to 'read-only' years ago for Xerox client software.
What did other vendors do (for those who didn't
know RFC 1759 has NEVER compiled for about four
different reasons in the original text) about this
trap and this index object access?
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc