[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-netconf-notification-01.txt
If garbage collection is desirable it is anyway needed for the long term subscriptions.
You need a pointer to the session in the data structure as one target might have multiple
sessions.
Juergen Schoenwaelder wrote:
On Thu, May 04, 2006 at 04:17:10AM -0700, Andy Bierman wrote:
This subscription info is just config data.
If it wasn't, you couldn't represent it in
the read-only data model (as in the document).
For me, a subscription bound to the lifetime of a session just adds
operational state and does not constitute a configuration change of
the device. If I log into a CLI and I request the CLI to show log
messages in my ssh session, I do not really consider this to be a
configuration change activity.
Operational state could be part of the data model. Netconf-prot Section 1.3 title is
Separation of Configuration and State Data. Also we need both dynamic and persistent
subscriptions; we should have a common handling and persistent subscriptions are really data.
Since you can easily represent it as config data,
and since this approach allows both agent initiated
and manager initiated sessions to share the same config,
the standard operations (not special RPCs)
are the most correct choice.
In order to support dynamic subscriptions via <edit-config>, the data
model needs to provide appropriate 'short-cuts' in terms of special
values to point to a session rather than a target (or to a target
implicitely defined by a given existing session) and there must be
ways to distinguish between entries whose lifetime is bound to the
existence of something like a session and other permanent entries
and/or there need to be timers to help with garbage collection of
subscriptions of dead sessions. In other words, you have to add
features and some complexity to the data model to properly support
dynamic subscriptions if you go down the <edit-config> path and
consider a dynamic subscription to actually be a configuration change
of the device.
Agree. This means two extra pieces of data for each subscription:
- related netconf session's sessionId
- garbage collection time or NIL
I simply find a <subscribe/> verb more natural for dynamic
subscriptions than doing a configuration change which has a limited
lifetime bound to some other operational state on the device, namely
the existance of the session.
/js
--
Balazs Lengyel Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320 Fax: +36 1 4377792
Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com
--
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/>