> Since SNMP currently provides no standard mechanism by which trap
> recipients can be registered with agents, I fail to see how the PWG
>
> can claim that interoperability of traps have been demonstrated. If
>
> certain vendors have demonstrated they can send/receive Printer MIB
>
> traps using a proprietary registration mechanism, congratulations,
> you've validated your implementation. And, I think that is enough
> justification for keeping the trap in the MIB spec.
The administrative framework required for registration of traps is
completely orthogonal
to the interoperability of trap generation and reception. What
interoperability with
regards to traps means is that a specific well-defined event has occured
and a
management station has successfully received a trap reflecting the
event. The main
sticking point with regards to interoperability within the printer MIB
is how well
we have defined what events cause traps to be generated and is there any
ambiguity in our definition that would cause implementations to
interpret the
definition differently.
I'm not saying that we don't need a standard for registration, I think
we do.
Its just that from an interoperability standpoint, its irrelevant to the
testing for the printer MIB.
>
>
> Speaking for the Xerox products which have made appearances at
> Printer
> MIB interop testing, they DO NOT emit traps. The reason is simple,
> there is no standard mechanism for registering trap recipients. Any
>
> Xerox proprietary mechanism would be useful only with Xerox
> management
> apps. Current Xerox management apps for these printers rely on
> polling
> rather than traps.
>
> I do not believe that failure of the SNMP community to specify a
> standard mechanism for registering trap recipients should be deemed
> a
> condemnation of the Printer MIB trap spec. I think we should keep
> the
> trap in anticipation of a forthcoming standard registration
> mechanism.
> And, we should check any currently proposed mechanisms to verify
> that
> the current Printer MIB trap specification is compatible with those
>
> proposed registration mechanisms.
>
> Thanks,
> Angelo