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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 2 Nov 2001 13:43:42 +0100

Sorry for late reaction
Wayne writes:

> 
> >    2) it incorrectly described INFORMs as "reliable". Again
> >       this is just plain incorrect.
> 
> We softened that to indicate the shortcomings, but let's face 
> it, they're > the most reliable current practice in town for
> notifications. 
>
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.

Where as with a TRAP it is just totally unknown as to what happened.
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 2 Nov 2001 19:13:51 +0100

I think I posted a long long time ago an idea that
I first heard from Geoff Carpenter (then at IBM Watson
Research). The idea is:

  - managed device sends a heartbeat every x interval
  - heartbeat includes latest sequence number of notification 
    entries in a log file (basically a MIB accessible file)
  - manager can determine from that 
    - we're still in touch with the managed device
    - if it has all the latest notification information
    - if not, it can go pick up the missing information

I think that is a neat idea... but we are diverging I guess.
This probably belongs more in disman WG

Bert 

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Friday, November 02, 2001 6:40 PM
> To: Randy Presuhn
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: BCP and Notifications (was: snmpconf FW: MIBs for events
> and notification logging)
> 
> 
> 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.
> 
>  
> On Fri, 2 Nov 2001, Randy Presuhn wrote:
> > Hi -
> > > Message-ID: 
> <[email-masked]
> cent.com>
> > > From: "Wijnen, Bert (Bert)" <[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 
> > ...
> > ...
> > 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
> 
> Regards,
> /david t. perkins
>