Your message is quite disturbing. When you say:
> We will need to come up with a solution in order to advance to
> DRAFT standard. The solution could be a standard method of
> registering traps for printers, or we could delete the
> discussion of traps entirely. Whether traps are mandatory or
> optional, we are still faced with the requirement of having two
> interoperable (consistently implemented) implementations of the
> feature. Right now, we don't have that.
Are you saying that, with regard to traps, interoperability MUST
be publicly proven before the new Printer MIB spec can move to DRAFT
status?
To all vendors who participated in the December interop testing:
Would you please take a few moments and comment on your recollections
about trap testing at the interop testing, and about how your product's
Printer MIB implementation deals with traps? Specifically:
- What did you do (during the testing) to configure your printer
to send traps, and to which host(s) (and port?) were configured
to receive those traps?
- Do you recall the specific tests used at Stardust to test trap
transmission and reception?
- Do you have any real product experience (ie, field experience)
with sending traps from your printer? For example, do you know
of a customer and/or beta site that actively utilizes the trap
features of the printer? If so, are the trap capabilites
satisfactory to the customer?
- Does your printer send (or have the capability to send) to traps
to a port other than the standard SNMP Trap port number?
Chris, you mentioned:
> I suspect that the printers that did support traps were configured
> in such a way so that the trap was not getting sent to the IWL
> Test Suite, but rather another application on the system. At
> least, I hope that was the situation. Harry's earlier email on
> this (included below) seems to confirm this.
Your IWL software was configured to receive traps on the standard
SNMP Trap port, right? Can your software be configured to receive
traps from other port numbers? If so, could your software have been
accidentally misconfigured such that it was looking for traps on the
wrong port?
I take it that your IWL test software used to receive traps was running
as root, right? The standard Trap port number is in the priviledged
range, so if your software was running on Stardust's Solaris SPARC
system (and it was, right?), then the Trap receiver process had to be
running as root. Do you recall that your software was indeed running
as root?
It seems truly unfortunate that so much time has gone by, only to find
that the Printer MIB may be held up by this trap issue. We need to
dig in and resolve this situation as quickly as possible, no?
...jay
----- Begin Included Message -----
Date: Thu, 3 Apr 1997 11:33:48 -0800 (PST)
From: Chris Wellens <chrisw@iwl.com>
To: pmp@pwg.org
Subject: PMP> Traps
Another item for the list of outstanding issues is the traps.
We had 100% failure from all vendors on this at the
interoperability testing in February. (These were part of the
IWL tests.) At first, we thought there was something wrong with
the test, but when we loaded up our agent simulator with RFC
1759 we were able to generate a trap and test it just fine. I
suspect that the printers that did support traps were configured
in such a way so that the trap was not getting sent to the IWL
Test Suite, but rather another application on the system. At
least, I hope that was the situation. Harry's earlier email on
this (included below) seems to confirm this.
We will need to come up with a solution in order to advance to
DRAFT standard. The solution could be a standard method of
registering traps for printers, or we could delete the
discussion of traps entirely. Whether traps are mandatory or
optional, we are still faced with the requirement of having two
interoperable (consistently implemented) implementations of the
feature. Right now, we don't have that.
Suggestions are welcome!
Harry's original mail:
("Harry Lewis) @ SMTP
Date: 02/20/97 09:02:51 AM
Subject: PMP> Registering for Traps
I don't have a specific proposal at this point but I'd like to raise the
idea of a standard method of registering for traps. I think we discovered
at the bake-off that every vendor has a means to register buried in their
private mib somewhere. This means, a management app wanting traps, has to
know each vendors means of registering.
Is anyone following the development of SNMPv3 to know if this will be covered,
or if it's handled in the (defunct) v2?
I wouldn't even care if it was printer MIB specific, although I guess thats
some form of SNMP blaspheme.
Anyone care to share ideas on this? Should we forget it and just look to IPP
for the answer?
Harry Lewis - IBM Printing Systems
----- End Included Message -----