[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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".
     Joel M. Halpern

At 09:39 AM 11/2/01 -0800, David T. Perkins wrote:
>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.
>On Fri, 2 Nov 2001, Randy Presuhn wrote:
> > Hi -
> > > Message-ID: 
> <2413FED0DFE6D111B3F90008C7FA61FB0DDC27FF@nl0006exch002u.nl.lucent.com>
> > > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > > 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.
>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
>/david t. perkins