Subject: edit-config operation

From: Vincent Cridlig <[email-masked]>
Date: Wed, 25 Jan 2006 16:15:21 +0100

Hi,

edit-config is not clear to me, in particular the merge operation:

"merge: The configuration data identified by the element
  containing this attribute is merged with the configuration
  at the corresponding level in the configuration datastore
  identified by the target parameter.  This is the default
  behavior."

The draft says that the element must be merged in the config but it does not explain how. Is there a clear definition of merge for XML elements ?
Also the given examples silently assume that the "name" element is a selection key. It should be explicit in the draft.

For example, let's imagine a data model where:
- the root element is "foo"
- foo must have a "name" child
- foo may have zero to two "bar" elements
- "bar" is a simpleType element

Initial config:
<foo>
  <name>bla</name>
  <bar>bar1</bar>
</foo>

Request:
<foo xc:operation='merge'>
  <name>bla</name>
  <bar>bar2</bar>
</foo>

Possible outputs:
<foo>
  <name>bla</name>
  <bar>bar2</bar>
</foo>

<foo>
  <name>bla</name>
  <bar>bar1</bar>
  <bar>bar2</bar>
</foo>

Under merge meaning is implicitely a combination of replace or create operation ?
There is no clear separation between the selecting nodes and nodes that must be updated.
Even with replace operation we have the problem since we don't know which bar must be replaced.

Anybody implementing has the same problems ?

Another thing: we are planning to implement a new edit-config with xpath, as a new capability. It will look like that:

       <edit-config>
         <target>
           <running/>
         </target>
         <config type="xpath" operation="replace" sel="/netconf/security/rbac/users/user[name='Alice']">
           <user>
              <name>Alice</name>
              <login>alicefoo</login>
              <building>a2</building>
              <room>100</room>
           </user>
         </config>
       </edit-config>

If the wg is interested to merge it to the standard xpath capability, just request more details.
We believe that edit-config should be extended with XPath in a similar way than get-config.

Sorry for the long mail.
Thanks for your help.
Vincent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jan 2006 08:38:42 -0800

Vincent Cridlig wrote:

> The draft says that the element must be merged in the config but it 
> does not explain how. Is there a clear definition of merge for XML 
> elements ?

merge is data-model specific.

> Also the given examples silently assume that the "name" element is a 
> selection key. It should be explicit in the draft.
>

There is absolutely no data model naming scheme defined in netconf.
I think these examples state that they are selecting by element called 
'name'.

> Anybody implementing has the same problems ?

It is data model specific.
Do you have suggestions for changing it?

>
> Another thing: we are planning to implement a new edit-config with 
> xpath, as a new capability. It will look like that:
>
>       <edit-config>
>         <target>
>           <running/>
>         </target>
>         <config type="xpath" operation="replace" 
> sel="/netconf/security/rbac/users/user[name='Alice']">
>           <user>
>              <name>Alice</name>
>              <login>alicefoo</login>
>              <building>a2</building>
>              <room>100</room>
>           </user>
>         </config>
>       </edit-config>
>

You are using a nice clean XPath expression.
Unfortunately, this is a small subset of the entire language.
I think there are huge problems with setting or locking data items
based on arbitrary Xpath expressions.

> Vincent

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Cridlig Vincent <[email-masked]>
Date: Wed, 25 Jan 2006 20:35:14 +0100

Andy Bierman wrote:

> Cridlig Vincent wrote:
>> I just need a clarification on how merge is working, which I didn't 
>> find in the draft.
>> I am not sure to understand what you mean by "merge is data-model 
>> specific. ". Is merge behavior up to the implementor, or are there 
>> some general guidelines on what the merge is doing ?
>
>
>
> This follows from the CLI.
> First, it is obviously important to know how multiple
> entries are distinguished and which fields need to be unique
> in a particular naming scope.
>
> A data model for access control lists may merge entries differently
> than a data model for assigning MAC addresses to an IP address.
>
>>
>> It would help a lot to explicitely state what data is to be created, 
>> deleted or replaced. I think one of these three operations must be 
>> explicitely present in each request.
>> Specifying the key elements in the edit-config can help also.
>>
>> I understand "merge" as a way to hide the real operations (create, 
>> replace, delete). But it is ambiguous in some cases, even if you 
>> define a strict data model (see the examples).
>
>
>
> Agreed.  That's why I'm creating my own "internal"
> data modeling language that deals with all these netconf details.
> Merge could be automated with some additional data.
> Standard algorithms like "first, last, natural-order, dont-care, 
> user-defined"
> can help.

What would be great is an edit-config operation that is self-sufficient 
to update the XML config.
Just like XSLT is doing to transform a document to an XML output without 
worrying about keys.

>> The XPath that I used is simple but it can be as complex as you want to.
>> I don't see the problems that it could create. Can you explain more ?
>
>
>
> What if the expression can resolve to more than one node in the data 
> model?
> Do you pick one at random?  Is the purpose of this to save space?
> Using a path expression instead of the XML sub-tree does save space.

If the number of selected nodes is higher than 1, they will be replaced 
all (in case the operation is replace). This can happen also with 
edit-config if the matching nodes match several nodes in the config.
Not only it saves bandwidth, but it addresses a set of nodes 
unambiguously and many people understand XPath.

Vincent

>
> You understand that the instance documents will not likely carry instance
> naming and other semantic meta-data, along with the data itself.
> This has been raised in the WG before.  The schemas for those instance
> documents are needed to implement netconf correctly.  It has never
> been a design goal of the WG for applications to be able to do real work
> with netconf with no understanding of the underlying data models.
>

		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Jan 2006 11:55:32 -0800

Cridlig Vincent wrote:

> What would be great is an edit-config operation that is 
> self-sufficient to update the XML config.
> Just like XSLT is doing to transform a document to an XML output 
> without worrying about keys.

Sounds interesting.
You should work up the details and implement it.

Personally, I don't see NE device configuration as an XML document problem.
I think it is more important to focus on the netconf, not on the XML. We 
want
NE device configuration data models to be static, canonical 
representations of
a conceptual datastore.  But XSD and RelaxNG describe XML instance 
documents,
which to us means the on-the-wire encoding.  This disconnect complicates 
things.

> If the number of selected nodes is higher than 1, they will be 
> replaced all (in case the operation is replace). This can happen also 
> with edit-config if the matching nodes match several nodes in the config.

I think it is worthwhile to explore further use of Xpath in netconf 
operations.
I'll send a separate email explaining more...

Andy

> Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les 
> tarifs exceptionnels pour appeler la France et l'international.

---

From: Vincent Cridlig <[email-masked]>
Date: Thu, 26 Jan 2006 09:59:19 +0100

Hi,

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.

Cheers,
Vincent

Andy Bierman wrote:

>>>> It would help a lot to explicitely state what data is to be 
>>>> created, deleted or replaced. I think one of these three operations 
>>>> must be explicitely present in each request.
> I think it is more important to focus on the netconf, not on the XML. 
> We want
> which to us means the on-the-wire encoding.  This disconnect 
> complicates things.
>
>
>>
>>
>>>
>>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Jan 2006 10:58:35 +0100 (CET)

Hi,

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

> 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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Jan 2006 03:50:55 -0800

>First of all, is it ok to discuss this on the list, or should we keep

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

---

From: Vincent Cridlig <[email-masked]>
Date: Thu, 26 Jan 2006 16:15:49 +0100

> (But you can't cut any wood with the blade-guard in the way.)

There is an obvious solution to not apply the XPath to the whole running 
configuration.
Example:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target>
      <running/>
    </target>
    <config type="xpath" xmlns:rr="my:own:namespace:root:elements" xmlns:uu="my:own:namespace:users" operation="create" sel="/rr:top/uu:users">
      <user xmlns=_*"my:own:namespace:users"*_>
        <name>Alice</name>
        <login>alicefoo</login>
      </user>
    </config>
  </edit-config>
</rpc>

1. Find the namespace of the element that will be created or replaced 
(here "my:own:namespace:users")
2. Query only the elements related to that namespace in order to build a 
sub document (Here it will just build a document containing the users)
3. Apply the XPath on it
4. Check that the user does not exist under the nodes selected
5. Create the user on your system

It scales with the number of namespaces (the number of sub-model of your 
config).
Namespaces are very useful to discriminate between nodes.

Vincent