Subject: Re: Disman issue Event-05

From: Randy Presuhn <[email-masked]>
Date: Mon, 30 Aug 1999 17:06:06 -0700 (PDT)

Hi -

> Date: Mon, 30 Aug 1999 19:51:21 -0400
> From: Jon Saperia <[email-masked]>
> Reply-To: [email-masked]
> To: [email-masked]
> CC: [email-masked], [email-masked],
>         Jon Saperia <[email-masked]>
> Subject: Re: Disman issue Event-05
> References: <[email-masked]>
...
> I am sorry, my initial comment was not clear.  My point was to make a
> distinction for INFORMS which are confirmed. While a single datagram can
> be lost, a system which generates them can take care of the
> retransmission.  In practice this seems fine.  

Retransmission alone as provided by RFC 2573 is not enough to assure
delivery.   I agree that in practice this is usally enough, but usually
isn't always, and I prefer to avoid the flamethrowers of those who take
"reliable" to mean "operating with the same probability as gravity."
:-)

> I avoided the temptation to tinker too much with the wording here but as
> an aside I would not put in a sentence that said "notifications are to
> be avoided since they may be lost or become burdensome."  If the former
> is a concern, use INFORMS which was my point (though I would love live
> operational data about the loss of a single specific TRAP causing a
> problem).  If the latter, concern about saturation of the net with too
> many TRAPS or INFORMS, then speak to the vendor who provided a system
> without enough smarts and kick them in the pants.  This is bad
> implementation and has little to do with the protocol.  

I agree, and in this spirit would not mind if the text were trimmed down
to something like this:

| Error handling is by notification.  These error notifications should be
| enabled only for the diagnosis of problems indicated by error counters.
| If minimizing the probability of notification loss is a concern they
| should be directed to a log as described in the Notification Log MIB
| [rfcNotificationLogMIB].  Note that this does

Comments?

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------

---

From: Jon Saperia <[email-masked]>
Date: Mon, 30 Aug 1999 20:24:18 -0400

Randy,

I can live with your compromise.  I would prefer the inclusion of
INFORMS since the wording is reduce loss of notification, not guarantee. 

/jon