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

Re: edit-config operation

Martin Bjorklund wrote:


Hi,

First of all, is it ok to discuss this on the list, or should we keep
it off-line?


I think list traffic is light enough that this is okay.
This is the sort of thing I had in mind when I sent the
email about "netconf experimental".  Actually, that
does not have to be WG-controlled.  It could be
an IANA controlled (first-come, first-serve) registry.
That way, anybody with enough ambition can create
an extension that others may interoperate with.

I knew when we added Xpath the the <get*> operations
that this would happen.  This is good though, to figure out
all the costs, benefits, and pitfalls of this approach.

Why I bet next you will be doing clever things like taking
the output of your <get-config> Xpath expression on <running>
and piping it somehow into a subsequent RPC, like multiple
<edit-config> Xpath expressions on <candidate>.
Or you could add an attribute to <config> (besides sel)
called 'sel-target' so the <edit-config> target can be different
from the Xpath target, and accomplish the same thing in 1 RPC.

Definite power tool with the blade-guard off potential here.
(But you can't cut any wood with the blade-guard in the way.)

Andy




Vincent Cridlig <vincent.cridlig@loria.fr> wrote:
I specified in more details our #edit-config-xpath capability: http://libresource.inria.fr/projects/ensuite/capabilities 
We are open to discussions to improve the syntax.


This looks very good!  I think it makes a lot of sense to separate the
node selection expression from the data modification expressions.  It
makes edit-config less ambiguous and easier to understand.

One added-value of this capability is that you can perform an
operation on a set of nodes.  This makes sense if you want to delete
all instances which match a certain pattern, e.g. all <logEntry> with
<date>2006-01-01</date>.  Another example might be if you want to
disable all atm interfaces.  But in order to do this, your "operation"
attribute would have to support "merge" as well, so you could write:

<config type="xpath" operation="merge" sel="/interfaces/interface[type='atm']">
  <status>disabled</status>
</config>

But why can't the ordinary operation attribute be used?  Then you
would write 
 <nc:config type="xpath" sel="/interfaces/interface[type='atm']">
   <status nc:operation'="replace">disabled</status>
 </nc:config>

(actually in that example the operation could be omitted since the
default 'merge' would do fine).

or

 <nc:config type="xpath" nc:operation="delete"
            sel="/interfaces/interface[type='atm']">
 </nc:config>


One drawback is probably (as Andy pointed out) that the cost of
allowing arbitrary xpath expressions may be high.



/martin


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





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