Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
Angelo, I agree with your general overall position that alerts should remain in
the Printer MIB. Like you, I am pleased that there are IETF w/g's working on
standard registration schemes.
I don't agree, however, that the current lack of standard methods for trap host
registration prevents us from demonstrating RFC1759 trap interoperability. If a
management app can determine how to register as the trap host on multiple
printers, then, from that point, I believe interoperabilies purpose is to make
sure each vendor's traps work alike.
Yes, registration is cumbersome today. But, once registered, are TRAPS
consistent. I look at this as the main interop question.
I don't see why I wouldn't want to publish my trap registration scheme or make
it readily available to any printer management app or app writer. Maybe some
printer mgt app writer would like to respond and indicate differently...
perhaps it's way too difficult to have to address 7 or 8 different means of
trap host registration in order to
get traps, today?
I guess, where I'm coming from is that we built a MIB in the environment of
poor SNMP trap host registration and included traps in that MIB. The MIB's been
out in the "IETF public" for quite some time and no one ever said... "No! You
shouldn't try to define traps... until someone figures out a standard way to
register...". We're just trying to advance our MIB, not SNMP. It seems most of
us agree traps should remain in the MIB. So, cumbersome registration aside, I
think it's prudent to check and see if those who implemented traps do it
"correctly".
----- Forwarded by Harry Lewis/Boulder/IBM on 04/22/97 02:57 PM ----
pmp-owner at pwg.org
04/22/97 02:48 PM
To: pmp at pwg.org@internet
cc:
Subject: Re: PMP> Traps - new info
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.
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