> Hi Mike,
> Your suggestion for commenting out the (redundant) trap
> binding of 'prtAlertIndex' and putting in the description
> that it MAY be included for RFC 1759 compatibility is
Another alternative is to depricate this NOTIFICATION (i.e. change it's
status to "deprecated". As defined in rfc1904, section 4.2
The values "current", and "obsolete" are self-explanatory. The
"deprecated" value indicates that the definition is obsolete, but
that an implementor may wish to support the group to foster
interoperability with older implementations.
And define a new NOTIFICATION which removes the offending object.
> It would be good if somebody else on this list showed
> they were reading this thread. I'm NOT the editor
> of Printer MIB v2.
> In some of the private MIBs at Xerox, we were forced
> to translate all index objects to 'read-only' when
> doing machine translation to SMIv1, because many
> existing third-party management stations do NOT
> permit the 'not-accessible' MAX-ACCESS for any
> non-Table/non-Entry object. A bug in those
> management stations (well...lack of clarity
> in SMIv1, at least...), but vendors can't
> choose to abandon customers who may be using
> older third-party management stations in their
> networks, in my opinion.
That is correct. See RFC 1908 for conversion rules between V1 & V2.
However, this mib as defined is V2 and needs to abide by SMI V2 syntax
(i.e. RFC 2578 - the replacement for 1902).
This ID is an update to the RFC 1759. Its purpose I presume is to fix
problems based on experience with its implementation by adding new
objects and/or deprecating existing objects.
> Separately, you said recently something about the
> MIB not compiling. What were you referring to>
> Not compiling under SMIv1 or under SMIv2 (and
> which version, RFC 144x, RFC 190x, or RFC 257x).
> - Ira McDonald
> High North Inc