Subject: [Netconf] Some questions about the usage of 'operation' attribute in edit-config

From: [email-masked]
Date: Thu, 5 Jun 2014 09:35:41 +0800

Hi all,
   I have some questions about the usage of  'operation' attribute in 
edit-config.
   1. 'replace' attribute can only be used to remove configuration?
      For example, the rpc request listed below is valid?
      <rpc message-id = "101">
           <edit-config>
               <target>
                  <running/>
               </target>
               <config>
                  <interfaces operation= "replace"/>
               </config>
           </edit-config>
      </rpc>

   2.How to process nested operation attribute?
     For example:
           <rpc message-id = "101">
           <edit-config>
               <target>
                  <running/>
               </target>
               <config>
                  <interfaces>
                      <interface operation= "merge">
                           <name>eth0/0/0</name>
                           <mtu operation= "remove">
                           <enabled>true</enalbled>
                      </interface>
                  </interfaces>
               </config>
           </edit-config>
      </rpc>

     The sequence of process is merge interface name 'eth0/0/0' and remove 
mtu and merge enabled to 'true' 
                             or merge interface name 'eth0/0/0' and merge 
enabled to 'true' and remove mtu?
     In other words, NETCONF will process outer layer operation firstly 
and process inner layer operation later, or process operations in 
accordance with XML tree traversal order?
 
3. If other operation attribute nested in operation attribute 
'remove',what should NETCONF server do? Only process remove operation?

  4. Can NETCONF support the nested operation attribute equals to parent 
operation attribute?
 
/frank
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: [email-masked]
Date: Thu, 5 Jun 2014 17:40:10 +0800

Nobody has interest on this question? :)
/frank

"Netconf" <[email-masked]> 写于 2014-06-05 09:35:41:

> [email-masked] 
> 发件人:  "Netconf" <[email-masked]>
> 
> 2014-06-05 09:35
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> [email-masked], [email-masked], [email-masked]
> 
> 主题
> 
> WARNING: Message may contain malicious content[Netconf] Some 
> questions about the usage of 'operation' attributein edit-config
> 
> Hi all, 
>    I have some questions about the usage of  'operation' attribute 
> in edit-config. 
>      The sequence of process is merge interface name 'eth0/0/0' and 
> remove mtu and merge enabled to 'true' 
>                              or merge interface name 'eth0/0/0' and 
> merge enabled to 'true' and remove mtu? 
>      In other words, NETCONF will process outer layer operation 
> firstly and process inner layer operation later, or process 
> operations in accordance with XML tree traversal order? 
> 
>   4. Can NETCONF support the nested operation attribute equals to 
> parent operation attribute? 
> 
> /frank 
> 
> ZTE Information Security Notice: The information contained in this 
> mail (and any attachment transmitted herewith) is privileged and 
> confidential and is intended for the exclusive use of the addressee
> (s).  If you are not an intended recipient, any disclosure, 
> reproduction, distribution or other dissemination or use of the 
> information contained is strictly prohibited.  If you have received 
> this mail in error, please delete it and notify us immediately.
> 

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jun 2014 08:46:53 -0700

> accordance with XML tree traversal order?

There is no required processing order.
It is an implementation detail.
Some things to consider:
  1) all operations are against the target datastore at the start of the
operation
  2) the operations are all-or-none, not incremental
  2a) this implies that create within delete, or delete within create, is
always an error
       because 'data-exists' or 'data-missing' must be true

In your example there is no problem because 'remove' works even if the data
is missing.

>   4. Can NETCONF support the nested operation attribute equals to parent

Andy

---

From: [email-masked]
Date: Fri, 6 Jun 2014 14:18:18 +0800

andy,
   Thanks a lot.
   Can you answer the first question? 'replace' can be used as 'remove'?
/frank

Andy Bierman <[email-masked]> 写于 2014-06-05 23:46:53:

> Andy Bierman <[email-masked]> 
> 2014-06-05 23:46
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> Netconf <[email-masked]>, [email-masked], [email-masked], 
> [email-masked]
> 
> 主题
> 
> Re: [Netconf] Some questions about the usage of 'operation' 
> attribute in edit-config
> 
> 

>   1) all operations are against the target datastore at the start of
> the operation
>   2a) this implies that create within delete, or delete within 
> create, is always an error
> In your example there is no problem because 'remove' works even if 
> the data is missing.
> 
>         
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jun 2014 11:43:28 -0700

>    Can you answer the first question? 'replace' can be used as 'remove'?

Read RFC 6241, sec. 7.2 Attributes section.
It explains the difference between the NETCONF <edit-config> operations.

Andy

---

From: [email-masked]
Date: Mon, 9 Jun 2014 09:18:32 +0800

Andy，
    I have looked through this section for many times. In my opinion, I 
think
the element contains attribute 'replace' must have subtree, and this 
subtree 
should be a valid configuration. But my colleagues don't think so, they 
argued
that the empty configuration is also configuration, they want to use 
'replace'
as 'remove', I can't persuade them, :)
    So,I want to get a clarification, thanks.
/frank

Andy Bierman <[email-masked]> 写于 2014-06-07 02:43:28:

> 2014-06-07 02:43
> [email-masked], Netconf <[email-masked]>, 
> [email-masked], [email-masked]
> 
> 主题
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Jun 2014 19:36:16 -0700

>     So,I want to get a clarification, thanks.

you are both right ;-)

the replace attribute does have to appear in a subtree, but a subtree may be
an empty node (if it is schema valid).

start:

  <config>
     <foo>
        <a>42</a>
     </foo>
  </config>

replace foo:

 <config>
     <foo operation="replace" />
  </config>

result:

  <config>
     <foo />
  </config>

The text seems very clear to me.

/frank

Andy

---

From: [email-masked]
Date: Mon, 9 Jun 2014 11:18:10 +0800

Andy,
   thanks,:)
   I understand only presence container or leaf node with empty type can 
be placed 'replace' attribute
and have a empty node subtree. Is it right?
/frank

Andy Bierman <[email-masked]> 写于 2014-06-09 10:36:16:

> 2014-06-09 10:36

think 
subtree 
> should be a valid configuration. But my colleagues don't think so, 
> they argued 
> that the empty configuration is also configuration, they want to 
use'replace' 
> The text seems very clear to me.

In your example, the 'foo' MUST be a presence container?

---

From: Andy Bierman <[email-masked]>
Date: Sun, 8 Jun 2014 20:44:58 -0700

> and have a empty node subtree. Is it right?

no. any container. anyxml. empty leaf. zero-length string leaf.

/frank

---

From: [email-masked]
Date: Mon, 9 Jun 2014 13:40:16 +0800

/frank

Andy Bierman <[email-masked]> 写于 2014-06-09 11:44:58:

> 2014-06-09 11:44

>    I understand only presence container or leaf node with empty type
> can be placed 'replace' attribute 
Really? a NP container can be a valid configuration itself?

> >     I have looked through this section for many times. In my 
> opinion, I think 
> > the element contains attribute 'replace' must have subtree, and 
> this subtree

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Jun 2014 08:05:22 +0200 (CEST)

>      <foo operation="replace" />

This is correct, but the original question was if "replace" could be
used instead of "remove" (if I understand the question correctly), and
the answer is no, it cannot.  With the config above, if you instead
send:

  <config>
 
The result is:
 
   <config>
   </config>

/martin

---

From: [email-masked]
Date: Mon, 9 Jun 2014 14:11:16 +0800

/frank

Martin Bjorklund <[email-masked]> 写于 2014-06-09 14:05:22:

> Martin Bjorklund <[email-masked]> 
> 2014-06-09 14:05
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked]
> 
> 主题
> 
opinion, I
> > > should be a valid configuration. But my colleagues don't think so, 
they
>       <foo operation="replace" />
Yes, this is my question.:)

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jun 2014 07:19:25 -0700

> Really? a NP container can be a valid configuration itself?

Yes -- there is some confusion because it is widely believed that NP
containers
have no semantics -- but this is false.  They are collections.  must-stmt
validation
that fails on an NP-container will cause the edit/commit to fail just like
any other node.

They are not as standard as other YANG data nodes because a server MAY
choose
to delete these nodes. Some server implementations even create them,
although the
spec is silent on this point.

As Lada pointed out, the server flexibility for NP-containers is more of a
bug than a feature.

BTW, empty bits is another empty node that is legal (for replace operation).
You can replace a leaf-list with itself (the instance containing the empty
node, if any).

Andy

---

From: [email-masked]
Date: Tue, 10 Jun 2014 08:46:43 +0800

/frank

Andy Bierman <[email-masked]> 写于 2014-06-09 22:19:25:

> 2014-06-09 22:19

> 
> Yes -- there is some confusion because it is widely believed that 
NPcontainers
> have no semantics -- but this is false.  They are collections. 
> must-stmt validation
> that fails on an NP-container will cause the edit/commit to fail 
> just like any other node.
> 

I don't agree. I think NP-container MUST not be a valid configuration if 
it has no children,
even if NP-container has some semantics, in that case, NP-container just 
act as a unit can be 
evaluated or validated.

If a NP-container can be a valid configuration itself, what's the 
difference between NP-container and presence container?

choose
> As Lada pointed out, the server flexibility for NP-containers is 
> more of a bug than a feature.
> 
> You can replace a leaf-list with itself (the instance containing the
> empty node, if any).

If leaf-list can be replace with itself, then the list can be replace with 
itself also.
Then all nodes container empty node should be considered to be a valid 
configuration?

I think WG should give a more clear clarification. 

IMO I think only NP-container,empty leaf, anyxml, zero-length string or 
binary, bits can be a valid configuration itself. 
> > > >    Can you answer the first question? 'replace' can be used 
as'remove'?

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jun 2014 18:01:16 -0700

> difference between NP-container and presence container?
A presence container's existence has some data model semantics described in
the text value for that statement.  A non-presence container is a
collection without
additional semantics for the existence of an empty container.

There is no text that supports your claim.

Note this text in sec. 7.5.8:

  If a container does not have a "presence" statement and the last
  child node is deleted, the NETCONF server MAY delete the container.

Note MAY instead of SHOULD or MUST.
You can treat an empty replace operation as a delete of an NP container
in your implementation.  Other servers can keep them in the data model.

> Then all nodes container empty node should be considered to be a valid
But then you would be providing list keys, and the container would not be
empty.
Replacing a list entry with just the keys is the same as deleting all the
non-key child nodes.

> I think WG should give a more clear clarification.

Sec. 7.5.8 could be clearer because it implies that this behavior
only applies to the "delete" operation.  It should be explicit that
"remove" and "replace"
can also cause the last child in an NP container to be deleted.

Andy

---

From: [email-masked]
Date: Tue, 10 Jun 2014 10:20:03 +0800

/frank

Andy Bierman <[email-masked]> 写于 2014-06-10 09:01:16:

> 2014-06-10 09:01

> I don't agree. I think NP-container MUST not be a valid 
> configuration if it has no children, 
> even if NP-container has some semantics, in that case, NP-container 
> just act as a unit can be 
> evaluated or validated. 
> 

> in your implementation.  Other servers can keep them in the data model.

In section 7.5.1:
"In the first style, the container has no meaning of its own, existing
   only to contain child nodes.  This is the default style."

If a NP container exists only to contain child nodes, why itself can be 
accepted 
as a valid configuration?

> 
> > They are not as standard as other YANG data nodes because a serverMAY 
choose
> If leaf-list can be replace with itself, then the list can be 
> replace with itself also. 
> Then all nodes container empty node should be considered to be a 
> valid configuration? 

> 
> But then you would be providing list keys, and the container would 
> not be empty.
> Replacing a list entry with just the keys is the same as deleting 
> all the non-key child nodes.
> 
> 
> IMO I think only NP-container,empty leaf, anyxml, zero-length string
> or binary, bits can be a valid configuration itself. 
> > 
> > > /frank 
> > 
> > Andy 
> 
> Andy
> 
> > 
> > > 

> > > > > > information contained is strictly prohibited.  If you 
havereceived

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Jun 2014 20:12:04 -0700

> as a valid configuration?

I can't find any text in any RFC that says to reject an empty NP container
as invalid config.
I can find text that says you MAY delete them. So do what you want in
your implementation.

Andy

---

From: [email-masked]
Date: Tue, 10 Jun 2014 14:15:08 +0800

/frank

Andy Bierman <[email-masked]> 写于 2014-06-10 11:12:04:

> 2014-06-10 11:12

> If a NP container exists only to contain child nodes, why itself can
> be accepted 

> 
> I can't find any text in any RFC that says to reject an empty NP 
> container as invalid config.

No, if a NP container itself can be accepted as valid configuration, and
sever delete it, client can use 'replace' as remove, 'merge' as remove.

If sever can decide whether support it. what client can do? If client send
a request to replace a NP container with a element contains empty node, 
the 
response is uncertain.

I think it's so bad for interoperability. I suggest NETCONF/NETMOD WGs 
reject
the NP container itself as invalid configuration. It's no any value and 
would 
cause confusion.

> Andy
> 
> 
> > 
> > > They are not as standard as other YANG data nodes because a 
> serverMAY choose

> > > > > > > Netconf <[email-masked]>, [email-masked], 
[email-masked]
> , 
> > > > > > >    I have some questions about the usage of 
'operation'attribute 
havereceived

---

From: Radek Krejčí <[email-masked]>
Date: Fri, 13 Jun 2014 11:31:01 +0200

Hi,

Dne 10.6.2014 08:15, [email-masked] napsal(a):
> a request to replace a NP container with a element contains empty
> node, the
> response is uncertain.
>

but the empty NP container has no information value. It doesn't matter
if the server deletes it or not. If you want to be sure, that the
container will be removed, use 'remove' operation.

> the NP container itself as invalid configuration. It's no any value
> and would
> cause confusion.
>

I don't think this is an issue.

Radek

-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : [email-masked]
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic