Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems
First, I'm not sure who sent the attached note, there is no name attached.
I appreciate the append regarding SNMPv3 ideas with traps (which I will not
propagate, here, due to it's length). I'm always interested in what's up ahead.
I don't think the fact that v3 is focusing on traps has any bearing whatsoever
on the status of the Printer MIB, RFC1759, however.
>The story so far is that we have no clear understanding for the failures on
>the
>trap tests. I can appreciate a certain reluctance to describe bugs in
>specific
>product implementations in a public mailing list. Therefore, I am asking
>for
>private mail from all 1759 implementors describing his/her experience
>and/or issue with traps by the end of next week (April 25, 1997).
I really wish I knew what the author is talking about. Exactly when did we
test traps at the Interoperability test? I could just be forgetful, but, since
every vendor must have a proprietary means of trap host registration (RIGHT?)
any such test would have been preceded by questions and answers regarding how
to accomplish this with each vendor and then some telnet process probably would
have been engaged etc. So, how can we reference a "failure on the trap tests"
at the bakeoff, if we didn't test traps?
I must be forgetting something here, so, if someone could describe the trap
test, how and when it was performed, I'd appreciate it.
>I was hoping to get some email indicating that participants in our
>interoperability testing had set up another application on their PC to be
>the trap receiver, and that's
>why the Test Suite did not receive the trap. If this *is* the case for
>your implementation, please send me private email so we can confirm.
This was not the case for us. I also don't recall setting up for *any*
application to receive traps. Does anyone recall this?
>Also, having polled the SNMP experts, the general consensus is that it
>takes about ten lines of code to generate a trap from an agent. Some of
>you have said that "traps are too hard to do". I assumed that meant too
>hard to code. Obviously that cannot be the case. I need to hear from you
>publicly or privately, why they are hard.
I don't think traps are too hard for the agent. Traps are hard for the
manager, IMHO, in that registration is not standardized and only one application
can listen on standard port 162 at a time.
>Based on all the facts right now, I would have to recommend that all the
>references
>about traps be removed from the RFC, and that the Printer MIB WG decides to
>defer
>specifying traps for printers until a standardized mechanism for traps is
>defined.
I strongly disagree! It's good that v3 is addressing issues with traps and we
can
expect improvements. I don't think this is any reason to remove traps from
RFC1759!
By the way... if we're to take this approach for traps then I would begin to
argue (vehemently) that we need to reconsider the disposition of other groups,
sub-groups and objects shown by the interoperability test to be of less than
optimal value, clarity or acceptance by vendors. We have clearly NOT taken
this approach. Rather, we are taking the approach that interoperability testing
has reveled differences among vendors and we have made some clarifications,
but little change, and implementations are expected to adjust in time - thus
achieving convergence (does anyone argue that this is not the approach we are
taking?). I think every vendor could site an example or two of things they
learned during interop test that they are considering "fixing" in their
agents for release in future versions or products. Based on this, I think
the interop test should be considered a great success.
Harry Lewis.