Subject: RE: BCP and Notifications (was: snmpconf FW: MIBs for events and notification logging)

From: Randy Presuhn <[email-masked]>
Date: Fri, 2 Nov 2001 07:38:43 -0800 (PST)

Hi -

> Message-ID: <[email-masked]>
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: [email-masked], "David T. Perkins" <[email-masked]>,
>         Jon Saperia <[email-masked]>
> Cc: Sharon Chisholm <[email-masked]>,
>         Randy Presuhn <[email-masked]>
> Subject: RE: BCP and Notifications (was: snmpconf FW: MIBs for events and 
> 	notification logging)
> Date: Fri, 2 Nov 2001 13:43:42 +0100 
...
> I think the possibly more important thing to focus on is that the
> sender of an INFORM mots probably gets a response when the 
> notification has arrived at the destination. If not, then
> it can decide to retry a few times, and finally it can decide
> to save the information for anothe retrt later or for
> a manager to pickup later.
...

This makes it possible to construct what in CMIP-land is
called a disseminator.  Think of it as a log in which
entries persist only until their delivery to their final
destination has been confirmed.  It really DOES give
reliable notification, even across reboots, if one needs
such a thing.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 2 Nov 2001 09:39:30 -0800 (PST)

HI,

Please note that getting a response back from an Inform does not
reliably confirm that a management application has "gotten" the
notification. There can be different implementation strategies
of how a notification receiver is implemented and how it is
connected to management applications and feeds them a stream
of notifications. Many commercial products are designed so
that a notification system is a system service that distributes
notications to clients (which are the management applications
running on the system, or even on another system).

To have "reliability", the generating system MUST log each
notification, and MUST NOT remove the log entry when it gets
back a Response (the confirmation) to an Inform. it MUST also
have the mechanism so that a receiver can determine if it
has has not received notifications, and log entries of those
notifications have been discarded from the log due to
system events such log resource limitations, or system restart
(when the log is not stored in persistent storage), etc.

> reliable notification, even across reboots, if one needs
It's been a few years since I've read this, but if you
are saying that entries are not inserted in the log
when a notification is confirmed, then I'm not sure if
this is reliable. I'd have to look at what CMIP required
before a notification was confirmed. And if implementations
are a notification service that distributes notifications
to clients without itself first logging them, before
sending a confirmation then it is not reliable.

One subtle difference between CMIP and SNMP is that
responses for Informs in SNMP MUST be sent in a very
short time or the notification generator will resend the
Inform. This changes the implementation strategy of
the receiver.

>  Randy Presuhn          BMC Software, Inc.  1-3141

Regards,
/david t. perkins

---

From: Jon Saperia <[email-masked]>
Date: Fri, 02 Nov 2001 13:08:03 -0500

The important point here is not reliability, by verifiability.  Even
when we have logs on the managed device, that does not guarantee that
the message will get through. Networks go down sometimes for a long
periods of time. The idea is: did the message get through in some finite
period of time, and if not what is done? Debating 'reliability' is a red
herring. In the end, with reasonable retry implementations, the message
gets through enough of the time to be helpful when using
INFORMS. Discussion beyond that falls into the realm of how many angels
can dance on the head of a pin.

> >  Randy Presuhn          BMC Software, Inc.  1-3141

Thanks,
/jon
--

Jon Saperia		     [email-masked]
			     Phone: 617-744-1079
			     Fax:   617-249-0874
			     http://www.jdscons.com/

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 2 Nov 2001 10:44:58 -0800 (PST)

Jon,

It looks like you are missing the point, and it certainly doesn't
help your argument to use terms like "red herring" and "angles
on heads of pins". Now you change from "reliability" to
"verifiablity". If you want to say something like
"this approach will work in these situations ..., and not
work in these situations ..., and the first situations
occur x% of the time, and the second situations occur 100-x%
of the time with a variation of %y, or due to z. And the
result of the failure of the mechanism to support the situation
is q." Then great, I'll defend your position (if you show
me how you got to the numbers). However, to make the broad
statements that I know to not be accurate results in me
sounding an alarm. From my reading and personal experience,
when major disasters occur, it is generally not when there
is a single failure, but when one or more failures result
in others that cassade and cause "meltdown".

Regards,
/david t. perkins

---

From: Joel Halpern <[email-masked]>
Date: Fri, 02 Nov 2001 14:26:08 -0500

Dave, you are pushing a particular implementation philosphy.
 From a protocol specification point of view, receiving a response to a 
notify is enough to legitimately relieve the client of archiving 
responsibility.  If a client chooses to archive, that is its right, but it 
is not something we should be mandating as part of making NOTIFY "reliable".
     Yours,
     Joel M. Halpern

At 09:39 AM 11/2/01 -0800, David T. Perkins wrote:
> > > Message-ID: 
> <[email-masked]>

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 2 Nov 2001 11:58:44 -0800 (PST)

Joel,

I believe you have it backwards. What I describes allows the
widest range of implementation strategies by a notification
reciever. I believe what you
describe limits the implementation strategies and actually
doesn't work in many cases with SNMP.

> is not something we should be mandating as part of making NOTIFY "reliable".

Didn't you see this...

Regards,
/david t. perkins