There seems to be a misunderstanding about testing here.
When IWL releases tests for a particular MIB, we have to literally
interpret the RFC, and some tests become prerequisites for other tests. In
the case of the trap tests in the Printer MIB, the prerequisite tests first
scan the host resources table to generate a list of printers for the tester
to select, and second, check for valid syntax, status, etc. on various
objects in the Host Resources MIB and cross references them to related
objects that are supposed to be implemented. If we don't require the
prerequisites, the resulting tests can generate false positives. This
becomes an issue of integrity for us.
The product implementor, on the other hand, has complete knowledge of what
was implemented and what was not. Often there are excellent reasons to
avoid implementing something. If there are tests that check for things
that were not implemented, then they are not useful, and can often be quite
confusing to the QA people. So, the best thing to do is to either remove
them or modify them.
The whole reason the tests are written in the Tool Command Language and
shipped as source is so that you can easily modify the tests and by pass
the ones that are not appropriate for your product implementation. This is
very easy to do and is fully documented in the Developer's Guide.
There's a built in conflict between producing tests that literally
interpret the RFC and using tests that are appropriate for your use of the
RFC in a product implementation. We resolve the conflict by supplying the
source.
Please pass this on to the testing organization. We will be glad to help
them out with this.
----------
> From: Bob Pentecost <bpenteco@boi.hp.com>
> To: pmp@pwg.org
> Subject: RE: PMP> Traps - new info
> Date: Tuesday, April 22, 1997 12:59 PM
>
>
> As HP's representative, I agree with the responses from Harry, Ron, Lloyd
> and others about the state of traps in RFC1759 (keep them in the
document).
> The HP printers implement traps and I recall setting up SNMPc to receive
> our traps during interoperability testing; there was no formal testing. I
> didn't run the IWL trap tests because so many of them failed before and
> there were requirements that all previous tests pass before running the
> next one.
>
> HP's JetDirect cards enable traps in a proprietary manner and we have
> tested them.
>
> Bob Pentecost
> HP
>
>
> ----------
> From: Harry Lewis[SMTP:harryl@us.ibm.com]
> Sent: Monday, April 21, 1997 3:31 PM
> To: rbergma@dpc.com
> Cc: pmp@pwg.org
> Subject: Re: PMP> Traps - new info
>
> Classification:
> Prologue:
> Epilogue: Harry Lewis - IBM Printing Systems
>
> Ron, thanks for making this into a simple explanation...
>
>
> >My SNMP trap code will not issue a Trap unless a trap host address has
> >been specifically defined. And since SNMP traps are not broadcast, I
> >would guess that this is true of most other implementations. I do not
> >understand how the test suite could then automatically detect a trap
> >if the printer agent was not setup to deliver the trap to the proper
> >IP address of the test suite.
>
> Precisely what I have been trying to say...
>
> And a simple question...
>
> >I thought that it was agreed that all participants would verify that
> >traps were operational on their systems. Has anyone reported?
>
> Yes - we have verified that traps are operational on IBM printers.
>
> Harry Lewis.