Re: manager subscription model for notifications: usage survey

[Andy Bierman <ietf@andybierman.com>]

Romascanu, Dan (Dan) wrote:
>  
>  
>
> > -----Original Message-----
> > From: owner-netconf@ops.ietf.org 
> > [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> > Sent: Friday, April 28, 2006 10:28 PM
> > To: Sharon Chisholm
> > Cc: Netconf (E-mail)
> > Subject: Re: manager subscription model for notifications: 
> > usage survey
> >
> > Sharon Chisholm wrote:
> > > hi
> > >
> > > I'm not sure which bit is tripping you up. The manager starts to 
> > > manage a network element and then subscribes for the 
> > information that 
> > > is of interest to it. If its interests change, it modifies 
> > the subscription.
> > > If it no longer wishes to manage that network element (moved to 
> > > another manager for example), it cancels the subscription. 
> > If it loses 
> > > connection, it re-establishes and re-subscribes knowing that 
> > > everything got nice and cleaned up when the session went away.
> >
> > Which products work this way today?
>
> I know very few examples in the device management world, but this method
> is rather widely used in web services management. 


I'm trying to understand how the manager subscription model
would fit in with existing network management systems which
use one or more notification listeners, that are configured
(hard-wired or some sort of discovery procedure) on each
notification generator.

It seems to me that the subscription-based complex filtering
is a service that a notification receiver application normally
provides to other NMS applications.  I don't see the dedicated
listener model ever going away, so this manager-subscribe feature
is at best a convenience for NMS applications to move the
notification subscription service from one NMS workstation
to every embedded agent.

IMO, this doesn't make engineering sense, because the
cost of development and deployment is so much higher for
embedded systems than workstations.  (That's probably
why NE vendors don't offer this feature today.)



> Dan


Andy

> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>