It seems there does seem to interest in having specialized verbs for
subscriptions. I think talking about subscriptions as 'operational
state' as appose to 'configuration data' was a great bit of
clarification. I also thought the discussion about moving from low level
programming languages (peek and pokes) to more procedural was also a
good analogy.
I think we need to find a comfortable place between the two extremes of
get/set and having a verb for every possible action on the box. Note
that we already created 'specialized' verbs in the base protocol - we
have get and get-config for example. We have been having to make these
decisions within product and I don't think we have reached a really
prescriptive criteria of when to create new verbs, I think the two big
questions are
- Is it possible to do it in the datamodel without exploiting
side-effects?
- Is the verb management related (reboot-box as appose to
create-atm-interface, for example).
As has been suggested, verbs, if there are not too many of them, make it
much easer for operators and management applications to figure out what
they need to do achieve their goal. It has been suggested that
operations on the datamodel would be easer for the agent-side to
develop. While I imagine that is true for the netconf stack, I think
that is ignoring the rest of the network element. Once the command has
been received by the agent, it them gets passed onto routines that do
the real work. In my experience, these real routines are not doing
peek/poke operations either. The network element must re-assemble the
command from the collection of things that have been provided in the
data model and realize that the user is trying to create a subscription.
Pushing things to the datamodel starts to look like
I'd like to subscribe -> <edit-config> <data/> </edit-config> ->
|
V
-> </edit-config> <data/> </edit-config> -> is this valid edit-config ->
Oh, they would like to subscribe -> is it a valid subscription -> ok,
I'll subscribe them then
And in this case, is it possible for the edit-config to be valid, but
have errors that prevent the subscription from being created?
Sharon Chisholm
Nortel
Ottawa, Ontario
Canada
--
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/>