Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
Since I'm not sure exactly what the PWG is going to do to resolve the Printer
MIB Trap questions, we've begun to play around with some interoperability
testing, here. We could only figure out how to register as a trap recipient for
2 printers (ours and one other) so far. The first thing we notice is that some
vendors have decided to supply the var bind definitions with the traps and some
have not. This could just point to one printer with a v2 agent and one with v1
or, it could point out another area where RFC1759 needs clarification.
Most SNMP references will inform you to minimize the burden on the agent and
utilize traps mainly as a signal to the NMS that it should poll *now* to find
out what has changed. We received like council from Steve W. during RFC1759
development. I can see where, if the var bind information is typically ignored,
some developers may choose to tighten up and not send it.
Also, the very definitions of printerV1Alert and printerV2Alert are confusing.
If you are an SNMPv1 agent I believe you would be implementing printerV1Alerts
which are described as "The value of the enterprise-specific oid in an SNMPv1
trap sent signaling a critical event in the prtAlertTable" If you are an SNMPv2
agent, printerV2Alert defines a binding of objects from the Alert Table
(although, for some odd reason, prtAlertTrainingLevel was left out). In just
reading the MIB, the v2 definition contains a v1 mapping, with the bindings,
which cold be confused with the prior v1 definition.
Needless to say, I think we should determine what the interoperability status
is, here. To do so, I think we need to find out... of the vendors who
implemented traps, who did v1 vs v2 traps and who carries alert table objects
with their trap vs. who doesn't.
Harry Lewis - IBM Printing Systems