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

Re: comments on draft-ietf-netconf-notification-01.txt



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.


agreed; but the parameters used for filtering are
just config data.  There are valid use cases for
wanting to NV-store the filter data on the agent,
and wanting to share that config data amongst multiple sessions.



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.

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.


My proposal uses a <subscribe> verb.
It just does it in a way that maximizes
the reusability of the data and the protocol,
instead of reinventing the protocol.



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