[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-netconf-notification-01.txt
Balazs Lengyel wrote:
In the current draft even short lived subscriptions (session based) can
be queried (Section 3.2) so to me they seem to be data.
In Ericsson we need persistent receivers. Imagine a management station
that manages 5000 nodes. When the management station restarts it does
not want to go and subscribe 5000 times if this can be avoided.
I agree.
I thought about this problem and punted (in my latest data
model email proposal).
The entire callhome feature needs to be independently specified
in full detail, for all 3 transports (if possible). There are security
considerations, reason-for-connect, redundancy and failover,
capabilities format, and many other details to work out.
I think Eliot Lear is working with someone at Cisco on this problem.
It didn't just fall through the cracks.
On the other hand I don't see any reason not to support session based
subscriptions either.
I agree.
Let's make sure the agent reuses as much code as possible.
Notice I haven't complained about all the filtering the
agent has to do for a subscription? The agent already
needs to have that code for <get-config> and <get>, so
this is total code reuse -- an excellent way to do filtering.
regards Balazs
Andy
Juergen Schoenwaelder wrote:
What I am interested in is to have an easy mechanism to request that
notifications are directed to a given session (by default 'this'
session if we allow mixed content) and to have that request bound to
the lifetime of the session. In other words, I am thinking of a
subscription which establishes operational state rather than a change
of the configuration of the device and hence <edit-config> might not
be the primitive of choice.
You are looking for ways to configure persistent notificiation
receivers and I agree that this is essentially a configuration change
and so <edit-config> seems to be the appropriate primitive to use.
I think the first decision to take is whether the WG wants to support
both, one, or none of the use cases.
--
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/>