Chris,
Regarding your recent response to Harry Lewis:
> > This was not the case for us. I also don't recall setting up for *any*
> > 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.
Any SNMP agent still has to know to which host to send a Trap, right?
What Harry is saying is that no one from the IBM team setup their printers
for such an address. So, your app would not have received anything
when, say, the paper tray was pulled. Harry, please correct me if I'm
wrong here regarding your team's activities.
> > >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!
>> 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.
So sorry to disagree here, but it appears to some of us that we might
have had a procedural problem during the interop testing. It takes two
to tango for Traps, and from the postings on this mailing list thus far,
the mgmt app software looks as potentially faulty as the printer agent
implementations you reference. There are no clear conclusions here that
would allow someone to declare "complete and total failure" in this issue.
If anyone disagrees with this statement (besides Chris, of course :-),
then NOW is the time to speak up as quickly as possible.
> > Rather, we are taking the approach that interoperability testing
> > has revealed 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?).
>> 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.
It's hard for me to imagine your position here, Chris, since you
were not present on the last day of the interop testing, during
which the entire group sat down and reviewed the results and set
a course to resolve the key issues. (Which, I might point out,
resulted in the excellent "Top 25" chart championed by Chuck Adams.)
And, most importantly, the issue of Traps was not mentioned ONCE
during the entire day's discussion of results and the setting of
a plan. Why? Good question. Perhaps it was because no one in
those discussions knew that there was a problem with the tests
themselves?
> 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.
As I recall, the group spent an entire day debugging your company's
software. To think that your software got it right in the end is
somewhat questionable, at best. Therefore, it might be reasonable
to ask you (IWL) to lead the charge in proving or disproving the state
of things here, at least until we hear from other participants of the
interop test event.
I wonder if the relative silence from the other interop participants
indicates agreement to your position (ie, take Traps out of the spec
entirely), or could it be that none of the participants believes we
really have a problem.
It would be nice to hear from more of the other participants! Considering
the gravity of this issue, the PWG (and the IETF) should hear from more
folks than just Chris, Harry and myself.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------