RE: requirement: agent initiated session support

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

In addition to the points below, one must have "admin authorization"
to subscribe to receive notifications. Thus, I really believe
that there are two types of notification receivers -
1) those that run all the time and are primarily for storing
   a record of events for later analysis
2) those that are transient and are run when an application
   is changing the config or initiating and action

I believe that there is a need for both, and it seems like
the conflict has been over trying to choose either #1 or #2
instead of understanding the uses cases for each and making
it easy for each to be used where they are appropriate.

Enjoy,
/david t. perkins

On Mon, 3 Apr 2006, Sharon Chisholm wrote:
> <Andy>
> >> 2) get rid of all the parameters in the start-notifications
> >>    or modify-subscription except the profileName (index)
> >>
> >> This way agents and managers can both share the profiles
> >> and the manager won't reenter the same data in the most complex 
> >> manner possible every time.  I can configure the agent to connect to 
> >> notification receiver X using profile Y.  The manager can just 
> >> subscribe using profile Y.
> >>
> >> (An agent may not allow a profile in use to be modified.)
> </Andy>
> 
> As a manager who actually supported Notification subscription in SNMP, I
> hated the pre-configured approach for two reasons:
> 
> 1) It was way too complicated. It was spread out over 100 tables with
> far too many options. Even the case you used 99 times out of 100 was a
> lot of work. You would get it to work for some devices, then find one
> where it didn't work and realize that you forgot to create a row in yet
> another table. I like the idea of command-line options since it acts as
> a deterrent from over-engineering the subscription model
> 
> 2) It was persistent. I had to always check if I was already set up to
> get notifications from the box. This was more annoying then it sounds.
> 
> Plus, in a connection-oriented model, would we have the idea of
> subscriptions that were there, but not active for when the underlying
> session died?
> 
> Sharon
> 
> --
> 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/>