Subject: PMP> Traps - new info

From: Harry Lewis <[email-masked]>
Date: Fri, 18 Apr 1997 15:48:11 -0400

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.

---

From: Chris Wellens <[email-masked]>
Date: Fri, 18 Apr 1997 18:52:02 -0700 (PDT)

> First, I'm not sure who sent the attached note, there is no name attached.

The mail came from me, [email-masked].  The reason you could not
tell is because you and I have discovered an interoperability problem 
between Microsoft Internet Mail reader version 4.70.1155 and whatever
version of Lotus Notes you are using.  If you report it as a bug
to the Lotus Notes team, I will report it to Microsoft.

> Exactly when did we
> test traps at the Interoperability test? 

The series of tests for traps is the 5.10.x group.  If you look
at the report that summarizes the IWL tests results from our
February interoperability testing, you will find the last four
items as the trap test.  The report is on the pwg.org site.

We did not set up conference calls on the results of the IWL
tests, because the majority of failures were either implementation
bugs, or things that we had already decided to change (like Max
access).  That's probably why you don't remember this.  

> have been engaged etc. 

Actually, the Test Suite acts like it is the manager station, so
the idea is that when a trap is manually generated on the agent,
the Test Suite intercepts it.  However, many of the participants
had set up other managers on their laptops.  So, *if* they had
configured these other managers to be the trap receiver, then
that might explain the 100% failure.  

> application to receive traps. Does anyone recall this?

If you did not explicity do anything, then removing the paper
tray would send a trap that the Test Suite would automatically
intercept.

> can listen on standard port 162 at a time.

Right.  That's why I included the information from the SNMPv3
Working Group meeting.  Lack of trap standardization has been 
an outstanding problem, and now there seems to be consensus
on resolving it.

> expect improvements. I don't think this is any reason to remove traps from

If you re-read RFC2026, you will see that agreeing or disagreeing is
not really an option.  Remember that we have to have at least two
interoperable implementations for every object, mandatory or optional.
So, we have to find two printers that have implemented traps, and
demonstrate that this works.  If we cannot do that, then we have to
remove it from RFC 1759.  We could probably take the position that
since there is not a standardized mechanism for trap registration and
receipt, that the manner in which the vendors have done it varies.

> Rather, we are taking the approach that interoperability testing
> has revealed differences among vendors and we have made some clarifications,
> taking?). 

That is a good summary statement of where we are going.  In all
the areas that we've been discussing, we've had some similarity
of results among the implementations.  We were able to reach
agreement, or at least compromise, on how things should be, and
write that down.  With traps, we are nowhere.  

So, why don't you lead the charge here?  Give this email to the
guys in the lab and ask them to re-run the 5.10.x series tests, 
put a sniffer or whatever on wire, and find out what is going on.

P.S.  Don't forget to report the bug to the Lotus Notes guys.

This email coming from pine:-)
-----------------------------------------------------------------------------
--==--==--==-  Chris Wellens             
==--==--==--=  Email: [email-masked]     Web: http://www.iwl.com/
--==--==--==-  InterWorking Labs, Inc.   244 Santa Cruz Ave, Aptos, CA 95003
==--==--==--=  Tel:  +1 408 685 3190     Fax:  +1 408 662 9065
-----------------------------------------------------------------------------