> 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
> interesting.
>
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).
>
> Cheers,
> - Ira McDonald
> High North Inc