Re: requirement: agent initiated session support

[Andy Bierman <ietf@andybierman.com>]

Juergen Schoenwaelder wrote:
> 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.

A destination is not enough in netconf, but I guess you meant
this is a generic sense


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

I don't think it's a good idea to use a design
which excludes important use cases.

>  
> > > 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".

I'm not writing the data model now.
If you think the parameters in the current draft
are sufficient, then imagine those parameters
in a real data model instead of RPC parameters.


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

You should add a requirement about scaling so it won't
get ignored.  The subscription model has some scaling
problems that don't exist in the traditional notification
generator application model.


> /js

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