PMP Mail Archive: Re[4]: PMP> How to Resolve the Traps Compatibility Issue

PMP Mail Archive: Re[4]: PMP> How to Resolve the Traps Compatibility Issue

Re[4]: PMP> How to Resolve the Traps Compatibility Issue

Bill Wagner (bwagner@digprod.com)
Thu, 1 May 1997 13:22:21 -0400


Harry,

With Jay's comments, it looks like a good outline to me. By the way,
could you suggest an application to check the trap as sent (other than
a network analyzer)?

Bill Wagner

______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: PMP> How to Resolve the Traps Compatibility Issue
Author: Harry Lewis <harryl@us.ibm.com> at Internet
Date: 5/1/97 12:08 PM

Classification:

For a limited time, I am willing to perform the following service to help
resolve the trap issues. I will build a table showing the following information:

1. Vendor (genericized or not - PWG's choice)

2. How to set the trap host (I think this should be documented somewhere
central to PWG to help make traps useful)

3. v2 or v2 traps implemented

4. What is actually sent in the trap PDU including

o Enterprise - which OID is sent
o agent-addr - test IP only
o generic-trap - testing RFC1759 traps only so verify this = 6
o specific-trap - value sent
o time-stamp - verify TimeTicks are included
o variable-bindings - are they included, what is the format sent.

5. Verify at least one operation that results in the printer stopping and
see that it traps.

6. Report what happens on the trailing edge of that event

7. Verify cover open trap.

8. Report what happens when cover is closed.

I can only do this if people send (lend) me a printer and tell me how to
register. If I already have your printer in shop then I'd just need to know how
to register.

I can only offer to do this over the next 2 weeks, so, if we're gonna do it we
need to get going.

Also, it is not necessary for one location to do the test. We could use this
outline as a test plan - modify it slightly if needed - and have every one
report their own results. Either way, it shouldn't matter. I just don't want
the test to get too much more complex. Items 5-8 are somewhat arbitrary, so I
don't mind if they get changed. I just think we need to see a couple traps, see
how they are formatted, see what's happening on both edges of the critical
binary.

Harry Lewis - IBM Printing Systems

----- Forwarded by Harry Lewis/Boulder/IBM on 05/01/97 09:36 AM -----

pmp-owner@pwg.org
05/01/97 09:28 AM

To: bwagner@digprod.com@internet
cc: pmp@pwg.org@internet
Subject: Re: Re[2]: PMP> How to Resolve the Traps Compatibility Issue

Bill,

It appears you missed my original message. Here it is:

Date: Wed, 30 Apr 1997 07:46:45 -0700 (PDT)
From: Ron Bergman <rbergma@dpc.com>
To: pmp@pwg.org
Subject: PMP> How to Resolve the Traps Compatibility Issue

Harry Lewis has made an excellent suggestion on how to resolve the
issues with traps. It is unfortunate though that it is too late to
use this suggestion to "fix" the Printer MIB, if we discover that
changes are required. But I do believe that it will be beneficial to
follow Harry's suggestion, even though we do not intend to change
the MIB.

I do not believe that an interoperability test is needed in this
area. We do not have to prove that traps work or that every vendor
that supports traps has implemented them as they intended. It is
up to each vendor to verify their design.

We do need to verify that the information presented in the trap PDU
fields is consistent and is as defined in the SNMP documents. I
agree with Harry that the SNMP RFCs are not very clear in this area
and would guess that we will find differences in the implementations.
Harry identified the three fields of a v1 trap PDU that must be
examined.

What about v2 traps? Are there any v2 trap implementations?

The three v1 fields Harry highlighted are:

1. ENTERPRISE - I can not find a good definition of what this field
is to contain. To the best of my knowledge this should be
sysObjectId unless it is an "enterprise-specific" trap. For the
latter case this value is as specified by the ENTERPRISE entry
of the trap definition.

2. SPECIFIC-TRAP - My guess is this should be the value of
printerAlert (i.e. 1).

3. VARIABLE-BINDINGS - In this case what should be presented is
clearly defined, especially in light of the recent effort on
the "Top 25 Alert Conditions". Harry's questions need to be
answered. "Is everyone sending VarBinds? Are they mandatory?
Do we all send the same stuff?"

I propose that all participants of the interoperability test plus
anyone else who is implementing the Printer MIB submit a response to
the above. This data can be reviewed in a teleconference or we could
allocate an hour in the San Diego meeting.

Any comments?

Ron Bergman
Dataproducts Corp.

On Thu, 1 May 1997, Bill Wagner wrote:

> Posts their results? Of what? Perhaps I missed it, but unless it is
> clearly stated what is being tested under what conditions, it is
> unclear that 'results' will mean anything consistent.
>
> Bill Wagner
>
>
> ______________________________ Reply Separator
_________________________________ > Subject: Re: PMP> How to Resolve the Traps
Compatibility Issue > Author: JK Martin <jkm@underscore.com> at Internet >
Date: 4/30/97 1:53 PM > > > Ron Bergman has proposed a good plan for
resolving this annoying issue. > > > I propose that all participants of the
interoperability test plus > > anyone else who is implementing the Printer MIB
submit a response to > > the above. This data can be reviewed in a
teleconference or we could > > allocate an hour in the San Diego meeting. > >
Let's try *real hard* to resolve this via the PMP mailing list. If > everyone
posts their results (to the mailing list) by a particular > cut-off date, then
we'll all have access to that data as it arrives. > > Once the data has been
reviewed, perhaps then (and only then) we can > put out a call for a
telecon...but only if folks really think it's > necessary. > > At the very
least, I hope we can do whatever we can *before* San Diego > so that we don't
spend precious time during those meetings on this > issue. This issue should be
resolvable across the wire. > > If for some reason the group decides to spend
precious meeting time in > San Diego on this topic, then would it be possible to
MANDATE that the > issue be fully resolved at that meeting (and not brought up
again some > two months down the road)? > > ...jay >