Subject: PMP> Traps - new info

From: "Chris Wellens" <[email-masked]>
Date: Thu, 17 Apr 1997 16:07:24 -0700

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 implementers describing his/her experience
and/or issue with traps by the end of next week (April 25, 1997). 

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.

Traps were discussed at the  SNMPv3 Working Group in Memphis.   (Minutes
included below.) My interpretation of this discussion is that there is
likely to be some agreement on standardizing the trap mechanism in agents
in the near future within the IETF.  

I was also asked how other MIBs handle traps.  The UPS MIB specifies traps
and these are handled in a very similar way to the Printer MIB.  The UPS
MIB working group has not done any interoperability testing, thus far.

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.

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.

----------
> From: Jeffrey T. Johnson <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Minutes of the SNMPv3 Working Group, IETF 38, Memphis
> Date: Thursday, April 17, 1997 11:35 AM
> 
> Minutes of the IETF 38 SNMPv3 Working Group
> Reported by Jeff Johnson, cisco Systems
> 
> 09Apr97 Evening Session
> 
> Working Group Chair Russ Mundy opened the session by introducing the O&M
> Area Directors John Curren and Mike O'Dell, as well as outgoing Area
> Director Scott Bradner.  Since Mike has primary ownership of the Working
> Group, he gave a brief presentation.
> 
> Mike's point of view is that there are nearly a half billion dollars
> worth of network elements that are managed via SNMP.  There needs to be
> a mechanism to secure them.  And since his company deploys such
> elements, he is a customer of our work.
> 
> Mike then commented on the name of the Working Group, SNMPv3.  He
> pointed out that it could have been simply called SNMP "Yet Again."  But
> by applying a number to it, SNMPv3, we're putting a stamp on it.
> This is it.  The Working Group is being given one last chance to
> succeed, and we need to answer the following question:  are we closer to
> the end, or further from the beginning?  We need to get security
> resolved, and we must succeed; the community needs for us to succeed.
> 
> John Curren then briefly added that although he's been active in the
> IETF for over five years, it's always been outside of Network
> Management.  However, he's had a chance to look in lately, and he's
> available as a resource for the Working Group.  He stressed that we need
> to fix the state of network management.  We need to have realistic
> expectations and produce something useful.  We need something that is
> deployable, it doesn't have to be perfect.  And we need it quickly, and
> it must be functional.
> 
> Scott Bradner then gave his very succint analysis of the job of the
> Working Group.  We have one mission, only one mission.  We must make
> SNMP secure in a way that is useful for the people operating networks. 
> We cannot deviate from that single narrow focus.  Our only aim is
> security.
> 
> Russ then reviewed the agenda and the charter.  He stressed that we are
> starting with the recommendation of the advisory team; we are not
> starting new work.  He pointed out that the recommendation provides for
> both security models and security protocols that are replaceable.  We
> want to leverage as much of the USEC and V2* work as is practical.  We
> are planning on producing five specifications while avoiding changes to
> RFCs 1902-1907.
> 
> This last point caused a bit of discussion.  Dave Perkins is concerned
> that other problems won't be addressed, and Andy Bierman specificly
> pointed out the need for Integer64 and Unsigned64 data types in the
> RMON2 Working Group.  Mike O'Dell told the Working Group that if we have
> working group last call by the Munich IETF, then we'll tackle the other
> issues.
> 
> David Harrington then began an overview of the architecture proposed by
> the advisory team.  The Trap Table in the Local Processing module was
> the immediate subject of discussion.  Randy Presuhn pointed out that the
> DisMan Working Group is also looking at a trap destination table.  He
> was concerned that there might be a duplication of effort, and further
> concerned that the final design contain the right stuff for both working
> groups.  There was some discussion as to whether sending traps is a part
> of the Local Processing, or really part of applications.  Steve
> Waldbusser noted that all SNMP transactions are initiated by
> applications except for one exception: agents sending traps. The model
> for notifications should be like every other transaction - it is
> generated by the application, outside of the protocol engine and traps
> should be dealt with as an exception in which the agent needs a
> mechanism for listing trap destinations, a statement with which several
> members of the working group concurred.
> 
> The question was then raised as to how informs fit into the model. 
> Keith McCloghrie felt that traps and informs should be handled
> similiarly.  He asserted that it is agents that have the information, so
> it is agents that should be sending both traps and informs.  Fred Baker
> asked Keith to confirm that he believes that agents should be capable of
> sending informs, despite language in RFC 1905 which states that informs
> are sent by management applications; Keith confirmed.  It was pointed
> out that we need to be specific about what we mean by an "agent" versus
> a "management application" in the scope of the architecture.
> 
> Bob Stewart had a different spin on traps and informs.  He feels that
> traps and informs are management activities, sent by management
> applications, to which Randy Presuhn observed that regardless of which
> "box" traps fall into, we must recognize that traps are different. 
> Specificially, outgoing traps go thru access control.
> 
> Jeff Case then opinioned that management emissions are at the response
> of management applications, and that application inputs come from many
> places.  There is a need for stable storage to indicate where to send
> notifications, but applications can also have non-stable destinations.
> 
> There was concensus that the Working Group was rat-holing on traps, so
> the question was raised if there were any problems, except for
> notifications, with the modular approach outlined by the advisory team.
> 
> Keith McCloghrie was curious just how tightly coupled the MPC and LP
> are, seeing as how the pdu version number refers to both.  He wanted to
> know if these should be more modular with separate version numbers or
> whether they should be tightly coupled.  Randy Presuhn further pointed
> out that version is even more overloaded because it also refers to SMI
> as well as LP model.  Dave Perkins explained that using the version to
> refer to SMI is one of the problems with the current SNMP that he wants
> to fix but which are out of scope.  Dave Fowler then observed that
> "management applications" are referenced throughout the documents, but
> that all aspects are considered implementation-dependent.  This led to
> lots of discussion about what is an application.  This discussion ate up
> the remaining meeting time.
> 
> 
> 10Apr97 Afternoon Session
> 
> Russ began by summarizing the previous evening's meeting. He then
> informed the working group that the initial schedule on the working
> group charter was not considered agressive enough by the Area
> Directors.  It is their desire to be at workig group last call by
> Munich.
> 
> David Harrington then began by reviewing what is in the boxes.  There
> are three types of modules inside the snmp engine:
>     mpc: coordination
>     sec: message-level security (authentication/privacy)
>     lpm: accesses control, coordinate processing of pdu
> 
> Inside a system, there are some "functional thingies" which "use" the
> engine (the term "functional thingy" was coined in order to avoid some
> of the semantic baggage which is attached to the term "application", in
> particular, we want to be clear that these can be present on either a
> management station or a managed device).
> 
> David then explained that one of the problems with the proposal is
> separating the architecture from the SNMPv3 message format.  In order to
> clarify the architecture, David drew up a slide showing pontentially
> many MPCs, SECs and LPMs in an engine.  Although the working group is 
> specificially concerned with the SNMPv3 MPC, there can be multiple MPCs
> in an engine, such as an SNMPv1 or SNMPv2C MPC.  Randy Presuhn was
> curious where the MPC recoginition takes place.  There is a
> demultiplexing which occurs when a message is received by the transport,
> but the exact location is implementation dependent.  Randy was also
> curious if the MPC defines the binding to the LPM.  The answer is that
> it depends on the LPM.  If an SNMPv3 message is received, the MPC looks
> at the message's security model to see which security function to use,
> but there is only one SNMPv3 MPC and LPM.  If, for example, an SNMPv1
> message is received, the v1 MPC is hardwired to use the community
> security model, and the v1 LPM is used.  But it was clarified that since
> RFC 1157 does not really specify an LPM, the v3 LPM could be used for
> SNMPv1 messages.  In other words, the v3 LPM may be used for v1
> messages, but it is not required to be used for them.
> 
> There was then a discussion about where does the MIB live.  Information
> is held in various places, and there is an interface between the LPM and
> the instrumentation.  A MIB interface provides access control to the
> instrumentation.  However, functional thingys can also access the
> instrumentation via other, non-SNMP mechanisms.  It was further noted
> that the difference between MIBs and instrumentation is an agent issue,
> and not an NMS issue.  MIBs are the mechanism for accessing the
> instrumentation.  It was asked if the working group plans on defining an
> API for accessing the information, and the answer is no, it is just an
> architectural interface; realization of the interface is
> application-specific.
> 
> Keith McCloghrie voiced a concern that the working group is being too
> specific in specifying the interfaces between the modules in the
> architecture, that it is a slippery slope.  Jeff Case concurred with
> this sentiment.  We need to make sure we are specifying a service
> interface and not an application interface.  The problem appears to be
> the term "interface".  Many people equate it with API, but in this case
> it is not.
> 
> Following this discussion, David Harrington gave a quick description of
> the message flows through the architecture:
> 
> o  generate request_msg
> o  receive request_msg
> o  generate response_msg
> o  receive response_msg
> o  generate trap
> 
> All was pretty quiet until we reached the trap flow.  It is different
> from both generating a request and generating a trap in that the PDU
> goes through access control before being sent.  Discussion began once
> again on the trap flow, but since the meeting time was over, it was
> squelched.
> 
> Russ then summarized the meeting.  There are plans for up to 6
> documents:
> o  Architecture
> o  V3 Message Processing & Control
> o  V3 USEC Security Model 
> o  V3 Local Processing
> o  V3 Notifications
> o  V3 Proxy
> 
> The last of these may be combined into a single document.
> 
> Finally, a new schedule was proposed
> May  9 next id
> May 19 week interim meeting
> Jun 13 next id
> Jun 23 week interim meeting
> Jul 14 last call versions
> Aug 11 week munich ietf
> 
> This would allow a Working Group Last Call by Munich.  There were many
> objections to this schedule, but the ADs stressed that we must meet this
> schedule.  This was followed by much discussion on the possibility of
> achieving this goal, which really didn't go anywhere.  Then the meeting
> was ajourned.
> 
>

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Sat, 19 Apr 1997 12:10:15 PDT

Hi Chris,

I find the reference to an 'SNMPv3 Working Group' somewhat disturbing.
The industry is in enough disarray trying to getting interoperability
(traps aside) around the 1996 SNMPv2 standards.  Could you post a 
pointer to the 'SNMPv2 Working Group'.  Overloaded as we are, my
common client team at Xerox would probably want to monitor and/or
participate in any activity updating the 'over-the-wire' SNMPv2
protocol.  Are new base types (like BITS) being added?  Will it
be possible to be cleanly interoperable between SNMPv2 (1996) and
the upcoming SNMPv3?

Cheers,
- Ira McDonald (outside consultant at Xerox)
  High North Inc
  PO Box 221
  Grand Marais, MI  49839

---

From: JK Martin <[email-masked]>
Date: Sat, 19 Apr 1997 15:20:30 -0400 (EDT)

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.

> > 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:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Harry Lewis <[email-masked]>
Date: Mon, 21 Apr 1997 12:23:37 -0400

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

Chris,

** Related thread **
>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.

I suspect interoperability problems are more pervasive than just
Microsoft and Notes. Thus, the plea about 9 months ago to the reflector
for everyone to simply "sign" their e-mail. Works, for now. I'll be
happy to report this situation to the Notes folks.
** End **

>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.

>tray would send a trap that the Test Suite would automatically

Please elaborate how the "Test Suite" informs the agent of it's IP
address so it can receive traps. The point we're stuck on is that you
say there was 100% trap test failure and I say we didn't test 'cause I
don't recall setting up the "manager" as a trap host. I don't understand
the "automatic" part.

>receipt, that the manner in which the vendors have done it varies.

Why would I be interested in reading RFC2026? Aren't we trying to forward
RFC1759? Are you telling me the IETF is a moving target?

It would help if vendors simply shared whether or not they have
implemented traps. (I think this was done informally at Stardust, but
probably not recorded). Regardless of whether we tested or not, we can
determine the *number* of implementations just by asking. If there are
many, then additional testing is warranted at some point (but I wouldn't
"hold up" the RFC). The lack of v3 standards doesn't mean traps can't be
useful to a printer management application today. If each vendor would
describe their trap host registration procedure, this would facilitate
printer management until v3 gets a standard in place. Trap testing would
not necessarily mandate another on-site "bakeoff". We could probably
find one or two management apps interested enough to assist in collecting
and sharing data. If we can't, this entire topic is mute.

We do implement RFC1759 traps.

>put a sniffer or whatever on wire, and find out what is going on.

'Cause I'm not suggesting we should remove traps from the RFC!

I'm in favor of testing, correcting, sharing implementation experience
and improving interoperability. But, honestly, with respect to moving
the RFC, I don't see parity in scrutinizing traps, given our disposition
on the hrMIB and Interfaces Table.

As I summarized, before, I think the printer MIB is a *useful standard*
which is on a path of continued improvement... sorta' like e-mail,
I guess.

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

I won't forget. For your information, I'm using Notes 4.5a.

Harry Lewis - IBM Printing Systems.

---

From: Ron Bergman <[email-masked]>
Date: Mon, 21 Apr 1997 10:46:37 -0700 (PDT)

Although Dataproducts was not a participant in the interoperability
 tests, I would like to interject a few comments.

 > wrong here regarding your team's activities.
 
  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.
 
  I thought that it was agreed that all participants would verify that
  traps were operational on their systems.  Has anyone reported?
 
 	Ron Bergman

---

From: [email-masked]
Date: 21 Apr 97 16:03:46 EDT

Jay said...
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.

<<Reply>>
Kyocera's printer at the Interop testing did not support traps, so we 
did not focus much thought on the trap tests.  My recollection and 
general impression from the Interop testing is that traps were just 
not given much attention.  We had much to do just to figure out the 
test suites and clarify and/or clearup bugs in the test suites and 
printer implementations.  I think the trap testing was just glossed 
over.  It is misleading to say it was a total failure.  If there was a 
failure, it was that traps did not get sufficient priority in the 
tests (but then we would probably be complaining about some other area 
that got missed).  

I don't see how the trap tests could have been "automatic", and since 
there was virtually no discussion at the Interop on how to perform the 
trap tests, I disagree that failing the trap portion of the test 
suites indicated non-interoperability (although it certainly doesn't 
indicate interoperability).

I am not in favor of removing traps from the Mib.  Why not have two 
vendors re-run the IWL trap test suites (with explicit instructions 
from IWL).  I think this would easily show interoperability.

Stuart Rowley
Kyocera Electronics

---

From: Lloyd Young <[email-masked]>
Date: 21 Apr 97 16:54:39 EDT

I'm answering this as the Lexmark representative not as the co-chair.
My opinion on why the IWL trap tests failed is actually because of
several reasons:
1. Some vendors did not implement traps
2. The IWL test for traps require that the printer under test be
configured to send traps to the workstation running the tests.
I know that I did not make this clear to the partipicants at the
interop testing. Therefore of the few printers that implement
traps, they were probably not set up to send traps to the 
workstation running the IWL suite.
3. Matt actually configured our printer to send traps to the IWL
test suite and it crashed. We send an enterprise trap before 
sending the Printer MIB trap and we surmise think the IWL trap 
test does not handle this.

I do not think we should remove traps from the Printer MIB.
I think there is work that has already been done that proves
trap interoperability but it is still be checked.
Lloyd Young
Lexmark
----------
To: chrisw%iwl.com @ interlock.lexmark.com @ SMTP
cc: pmp%pwg.org @ interlock.lexmark.com @ SMTP (bcc: Lloyd Young)
From: jkm%underscore.com @ interlock.lexmark.com (JK Martin) @ SMTP
Date: 04/19/97 03:20:30 PM
Subject: Re: PMP> Traps - new info

********************************
*   Other text deleted
********************************

 ...jay

---

From: Harry Lewis <[email-masked]>
Date: Mon, 21 Apr 1997 17:30:59 -0400

Classification:
Prologue:

Ron, thanks for making this into a simple explanation...

  >IP address of the test suite.

Precisely what I have been trying to say...

And a simple question...

  >traps were operational on their systems.  Has anyone reported?

Yes - we have verified that traps are operational on IBM printers.

Harry Lewis.

---

From: [email-masked] (Ira Mcdonald x10962)
Date: Tue, 22 Apr 1997 12:05:44 PDT

Hi Ang,

I thoroughly agree with your words below.  Note that some other
Xerox printers (now shipping) in the DocuCentre family DO emit
SNMP traps, but do registration through the old (sigh!) SNMPv2
Party MIB, so this too will need changing.  The problem of trap
sinks registration independent of any 'security' model of a 
system is a universal hassle in NMS products.

Cheers,
- Ira

>From [email-masked] Tue Apr 22 10:47:34 1997
Date: Tue, 22 Apr 1997 08:14:20 PDT
From: "Caruso,Angelo" <[email-masked]>
Subject: Re: PMP> Traps - new info
To: [email-masked]
Posting-Date: Tue, 22 Apr 1997 10:22:07 -0400
Priority: normal
Hop-Count: 3
Sender: [email-masked]
Status: R

Since SNMP currently provides no standard mechanism by which trap 
 recipients can be registered with agents, I fail to see how the PWG 
 can claim that interoperability of traps have been demonstrated. If 
 certain vendors have demonstrated they can send/receive Printer MIB 
 traps using a proprietary registration mechanism, congratulations, 
 you've validated your implementation. And, I think that is enough 
 justification for keeping the trap in the MIB spec.

Speaking for the Xerox products which have made appearances at Printer 
 MIB interop testing, they DO NOT emit traps. The reason is simple, 
 there is no standard mechanism for registering trap recipients. Any 
 Xerox proprietary mechanism would be useful only with Xerox management 
 apps. Current Xerox management apps for these printers rely on polling 
 rather than traps.

I do not believe that failure of the SNMP community to specify a 
 standard mechanism for registering trap recipients should be deemed a 
 condemnation of the Printer MIB trap spec. I think we should keep the 
 trap in anticipation of a forthcoming standard registration mechanism. 
 And, we should check any currently proposed mechanisms to verify that 
 the current Printer MIB trap specification is compatible with those 
 proposed registration mechanisms.

Thanks,
Angelo

---

From: Bob Pentecost <[email-masked]>
Date: Tue, 22 Apr 1997 13:59:31 -0600

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:[email-masked]]
Sent:  Monday, April 21, 1997 3:31 PM
To:  [email-masked]
Cc:  [email-masked]
Subject:  Re: PMP> Traps - new info

Classification:
Prologue:

And a simple question...

Harry Lewis.

---

From: Harry Lewis <[email-masked]>
Date: Tue, 22 Apr 1997 17:15:57 -0400

Classification:
Prologue:

Angelo, I agree with your general overall position that alerts should remain in
the Printer MIB. Like you, I am pleased that there are IETF w/g's working on
standard registration schemes.

I don't agree, however, that the current lack of standard methods for trap host
registration prevents us from demonstrating RFC1759 trap interoperability. If a
management app can determine how to register as the trap host on multiple
printers, then, from that point, I believe  interoperabilies purpose is to make
sure each vendor's traps work alike.

Yes, registration is cumbersome today. But, once registered, are TRAPS
consistent. I look at this as the main interop question.

I don't see why I wouldn't want to publish my trap registration scheme or make
it readily available to any printer management app or app writer. Maybe some
printer mgt app writer would like to respond and indicate differently...
perhaps it's way too difficult to have to address 7 or 8 different means of
trap host registration in order to
get traps, today?

I guess, where I'm coming from is that we built a MIB in the environment of
poor SNMP trap host registration and included traps in that MIB. The MIB's been
out in the "IETF public" for quite some time and no one ever said... "No! You
shouldn't try to define traps... until someone figures out a standard way to
register...". We're just trying to advance our MIB, not SNMP. It seems most of
us agree traps should remain in the MIB. So, cumbersome registration aside, I
think it's prudent to check and see if those who implemented traps do it
"correctly".

----- Forwarded by Harry Lewis/Boulder/IBM on 04/22/97 02:57 PM ----

        [email-masked]
        04/22/97 02:48 PM

To: [email-masked]@internet
cc:

Thanks,
Angelo

---

From: [email-masked] (Bill Wagner)
Date: Tue, 22 Apr 1997 19:16:14 -0400

Since I have seen no message on this subject from the manufacturer of 
     the printer which I participated in testing, let me indicate that that 
     printer does support the RFC 1759 traps. However, the trap 
     destinations must be entered in the NIC NV RAM (via a private 
     enterprise MIB) before trap activity can be seen on the net.
     
     The PWG avoided attempting to address general questions on trap setup 
     and use since this appeared to be beyond the scope of the charter. The 
     IETF must address this, hopefully in a way applicable to the various 
     applications. As Lloyd indicates, there may also be questions of 
     consistency of implementation that need to be worked out. But I agree 
     that traps are potentially very useful capabilities that should not be 
     elimiated fro the Printer MIB.
     
     Bill Wagner, Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re: PMP> Traps - new info
Author:  Lloyd Young <[email-masked]> at Internet
Date:    4/21/97 4:54 PM

     

     
 ...jay

---

From: "Chris Wellens" <[email-masked]>
Date: Mon, 28 Apr 1997 12:40:13 -0700

Bob,

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 <[email-masked]>
> To: [email-masked]
> Subject: RE: PMP> Traps - new info
> Date: Tuesday, April 22, 1997 12:59 PM
> 
>