[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: requirement: agent initiated session support



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>

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