Actually SNMPv2 isn't defunct - only the March 1993 SNMPv2 Proposed
standard (RFC 1440 series) is defunct). The January 1996 SNMPv2
Draft standard (more standard that Proposed - don't blame me - I
wouldn't have adopted this terminology) sort of went forward
(eg, added the useful 'accessible-for-notify' choice to MAX-ACCESS)
and backward (eg, lost all semblance of security and the Party MIB)
at the same time. In the RFC 1440 series Party MIB (RFC 1447, if
I remember right), there was a standard method for registering
for traps (pretty commonly supported by routers and bridges already
shipped). In the RFC 1900 series (Jan 1996) of SNMPv2 standards,
there is NO standard method for registering for traps. Xerox,
like every other vendor has had to wrestle with this - for a while,
we used the Party MIB - until recent versions of the Internet
Official Protocols (see RFC 2000, Feb 1997) started labelling
it 'Historic' (ie, NOT recommended for implementation in any
network product) - now we have a new (sigh) proprietary method.
This is the most glaring fault in the revised SNMPv2 standards,
to my mind. Why bother to have standard traps, if there's no
standard way to register for them. Why bother to have the
idea of 'trap-directed polling', if you can't get the traps.
Xerox folks think this seriously hampers the utility of the
Printer MIB. Perhaps it's worth having a (localized) fix
imbedded in the Printer MIB V2.0 - certainly it's impossible
to show interworking in traps, unless two vendors still
support the deprecated Party MIB (RFC 1447) - any volunteers?
Cheers,
- Ira McDonald
(outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839