Re: requirement: agent initiated session support

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:
> hi
>
> I'm now responding to myself, but anyways ....
>
> <Sharon>
>
> <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>


Good luck with your model in an actual network after a power outage.
In the subscribe model, none of the agents can send any notifications
until a manager connects to them and asks for notifications.  The startup
notifications are critical to have, to check for any
config/image/HW mismatches that occurred during boot-up.

IMO, this approach is complicated -- not the traditional model.
There will probably be 2 or 3 tables, not 100.
I never said "over-engineer it to death" like SNMP did.

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.
> </Sharon
>
> I think part of the problem here is who is the authoritative source of
> 'what the netconf client is interested in'. The netconf server is the
> authoritative source of device configuration. The Netconf client is the
> authoritative source of what synchronous commands it wants response
> from, but suddenly with asynchronous messaging, we are proposing that
> the netconf server is the authoritative source of what the netconf
> client is interested in? This is annoying as a client. It's more work
> and a loss of control.
>
> <Sharon>
> 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>
>
> I
>
> --
> 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/>