Subject: Distributed Application Error Handling

From: Bob Stewart <[email-masked]>
Date: Thu, 12 Nov 1998 16:11:40 -0500

Juergen and I have a disagreement about error handling in the Event MIB.
I'm proposing (by example) a new method, and he's being conservative and
wanting to stick with the old way.  I'd like to get more discussion on the
issue to help decide.

What I'm doing is relegating error codes to notifications that you enable
when you see errors showing up in global counters, that is if you can't
figure the problem out by inspection.

Juergen correctly points out that this is a major departure from past SNMP
convention, where we explicitly discourage the use of Traps because they
are unreliable.

I claim that we're in a newer world and should consider changing some of
our old conventions.

Keeping individual counters and most recent error information for all
triggers and events is a lot of MIB objects, which I'm trying to avoid.

I've never liked "most recent" MIB objects, as they lose information when
you have more than one problem.  Stuffing them in a Trap was the way to get
that information, if the Trap got through.  Being more reliable required a
history table, for significantly more complexity.

But now we have Informs, which are more reliable than Traps, and on some
luck systems you'll have the Notification Log MIB, a general purpose
history table.  I believe these, coupled with events expected to occur at
relatively predictable times, allow us to do something different for errors.

Note that the Notification Log MIB is an added benefit, but not a
requirement.  Traps are likely to work well enough, Informs better, and the
Notification Log MIB is as reliable as you can get.

I don't expect errors to be common, or at least of particular interest,
once initial configuration is in place and debugged.  In other words I
expect the counters to change infrequently, or have a burst when some other
problem is clearly at fault, such as a break in network connectivity.  An
unexplained burst of errors would be a reason to turn on the detailed error
notifications.

Note that if we do it my way and I'm wrong we simply add more MIB objects
later, but if we don't and I'm right we won't be able to tell.

	Bob

---

From: Bob Natale <[email-masked]>
Date: Thu, 12 Nov 1998 16:47:27 -0500

>At 11/12/98 04:11 PM, Bob Stewart wrote:

Hi Bob,

<...>
>I claim that we're in a newer world and should consider changing some of

I agree.

<...>
>relatively predictable times, allow us to do something different for errors.
<...>
>Notification Log MIB is as reliable as you can get.

Right.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------