Re: requirement: agent initiated session support

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Fri, Mar 31, 2006 at 06:10:10AM -0800, Andy Bierman wrote:
> Juergen Schoenwaelder wrote:
> >On Thu, Mar 30, 2006 at 07:18:59AM -0800, Andy Bierman wrote:
> >
> >[...]
> >
> >I just added
> >
> >* solution should support preconfigured notification destinations [AB]
> >
> 
> What about the session and transport aspects, and losing
> all the startup notifications if you use the subscription approach?
> We have users and sessions in netconf, not host endpoints like snmp.

I fail to see how your comment applies to the quoted text. I do not
understand why you wrote the last sentence at all.

> >The subcription model helps to simplify management applications that
> >are not constantly running, such as a configuration tools that you
> >kick off once in a while (or periodically) to check and configure
> >things if the checks do not deliver the expected outcome.
> 
> It doesn't work if the agent initiates the session.

He? Please help me understand what you mean. I fail to match you
comment to the quoted text.
 
> >The preconfigured approach requires that such an app 
> >
> >(a) first finds a suitable notification receiver,
> >(b) authenticates with this notification receiver,
> >(c) subscribes to this notification receiver 
> 
> How is this any different if the client initiates it?
> It's the same amount of code either way.
> 
> I favor a combined approach:
> 
> 1) profile table
>    Each profile contains the configuration data for that
>    named profile
> 
> 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.)

Show me the detailed profile information you have in mind and how this
can be tweaked by an app that comes and goes and I will then tell you
whether I consider a plain subscription "the most complex manner
possible".

> What about the problem of losing all the startup notifications?
> If apps care about that they better configure a notification
> receiver in NVRAM.  What about discovery?  Does it really scale
> for 100000 agents to come up, and 1 or a few managers find all
> of them and check if they support notifications, and then
> start subscriptions on all the appropriate boxes?  It sure
> seems easier to just configure the subset of agents which are
> notification generators to connect to a receiver upon reboot.

To quote myself:

> >I just added
> >
> >* solution should support preconfigured notification destinations [AB]

I do not understand your message.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
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/>