Subject: [Netconf] edit-config operation inconsistency

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Mon, 28 Jul 2014 15:11:49 +0000

Hi all,

we are currently debating an issue we found and would like to have some
clarification. Netconf RFC says that the edit-config operation which
contains multiple sub-operations on the same data is undefined. 

so when considering this request:

<edit-config>
<target><candidate/></target>
<config>
 <container operation="delete">
  <leaf operation="create"/>
 </container>
</config>
</edit-config>

the outcome is undefined, since the client wants do delete container
<container>, while simultaneously creating <leaf> which is part of
<container>.

Now, when considering a simple list deletion:

<edit-config>
<target><candidate/></target>
<config>
 <list operation="delete">
  <key-node>key-value</key-node>
 </list>
</config>
</edit-config>

and rigorously reading the RFC regarding operation and
default-operation, the operation attribute for <key-node> is "merge",
thus, technically, this edit-config operation operates on the <key-node>
twice:

1.) deleting the value via deletion of the list entity <list>
2.) merging in a new value via "merge" on the <key-node>

The RFC has <default-operation>none</default-operation> in all deletion
examples, which makes us believe that indeed when processing the
mentioned request, the <key-node>'s operation would be "merge" and thus
the operation undefined.

Is this how it's supposed to be or are we reading it wrong?

Thanks,
Klement

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jul 2014 08:22:38 -0700

On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera - Pantheon

> <container>, while simultaneously creating <leaf> which is part of
It is defined.
Does the node /container exist in the target datastore?
If yes, then the create operation on /container/leaf MUST fail.
If no, then the delete operation on /container MUST fail.

> thus, technically, this edit-config operation operates on the <key-node>

The operation is inherited from its parent if no "nc:operation"
attribute is specified. The keys need to be present to specify the list
node to be deleted.

> Is this how it's supposed to be or are we reading it wrong?
the latter

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

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Mon, 28 Jul 2014 15:31:47 +0000

> If no, then the delete operation on /container MUST fail.

what if /container exists but /container/leaf does not? this way both
sub-operations could be performed

> attribute is specified. The keys need to be present to specify the list

can you point to the paragraph in netconf RFC which says that the
operation is inherited?

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jul 2014 08:43:09 -0700

On Mon, Jul 28, 2014 at 8:31 AM, Klement Sekera -X (ksekera - Pantheon

> sub-operations could be performed

not really. If implemented correctly then if the delete on /container
succeeds,
then all its descendants are also deleted.  The result in the target
datastore cannot
possibly complete both a delete on an ancestor and create of a descendant
in the same edit. Our server returns an error because it cannot honor
both requests.

> can you point to the paragraph in netconf RFC which says that the
the delete operation on the /container node is for the container and all its
descendants.  That is how it is inherited. I should have said "effective"
operation
instead of "inherited".

> > > Is this how it's supposed to be or are we reading it wrong?
Andy

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Tue, 29 Jul 2014 07:44:20 +0000

> in the same edit. Our server returns an error because it cannot honor

I believe that this is the part where 

      If the <edit-config> operation contains multiple sub-operations
      that apply to the same conceptual node in the underlying data
      model, then the result of the operation is undefined (i.e.,
      outside the scope of the NETCONF protocol).

comes into play. Exactly as you say, target datastore cannot complete
both the deletion and creation, since both operate on the same data but
rule each other out.

> descendants.  That is how it is inherited. I should have said "effective"

      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.

         If the "operation" attribute is not specified, the
         configuration is merged into the configuration datastore.

in this case, the "operation" attribute for <key-node> is not specified.
So the provided example request is equivalent to this request:

<list operation="delete">
 <key-node operation="merge">key-value</key-node>
</list>

so basically it's the same as above - there is a request do delete
<list> while creating and/or keeping <key-node> around - both cannot be
done. I cannot find any exception in the RFC for list/key-node combo
case.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2014 05:17:56 -0700

On Tue, Jul 29, 2014 at 12:44 AM, Klement Sekera -X (ksekera - Pantheon

> done. I cannot find any exception in the RFC for list/key-node combo
Perhaps 1 new sentence (After the 1 about no attribute=merge):

  If the operation attribute is not present for a key leaf node, and
  the edit operation for the parent node is "delete" or "remove",
  then the operation for the key leaf node is the same as its parent node.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 29 Jul 2014 16:43:34 +0200

Hello,

I always tought the operation attribute is inherited.  Inherited in
a sense that an XML element actually contains/includes all
sub-elements under it. So creating/deleting/merging the element
means creating/deleting/merging all its contents as well. So unless
you later override this with more specific instructions for one of
the contained elements it should be valid for the complete element
with all its content.

If operation is not inheritable we have some interesting cases:

- your examples

- default operation=none and I want to create a sizeable subtree. I
have to place the merge/create operation on every node. Don't like
it, makes none-unusable except for delete/remove.

Lets say we have the following data model:

routing
+--static-routing
| +--route [routeId]
| +--routeId ipprefix
| +--path-to-destination [nexthop]
| +--nextHop ipAddress
| +--outgoingInterface string
+--bfdActive boolean

I want to create a static route with all its sub-elements but only
if the static-routing presence container exists (static routing is
allowed/enabled).

<default-operation>none</default-operation>

<config>

<static-routing>  --- this will check that static routing
exists.

<route operation="create">  --this will create the
interface

<routeid>1.1.1.1/24</routeid>   -- I don't want
to put operation=create on all further nodes 5 times or more
depending on the number of paths

<path-to-destination>

<nextHop>1.1.1.5</nextHop>

<outgoingInterface>eth0</outgoingInterface>

<bfdActive>true</bfdActive>

</path-to-destination>

</route>

</static-routing>

</config>

This was very nice and logical. I hope it still works.

regards Balazs

On 2014-07-29 14:17, Andy Bierman
wrote:

On Tue, Jul 29, 2014 at 12:44 AM,
Klement Sekera -X (ksekera - Pantheon Technologies SRO at
Cisco) <[email-masked]>
wrote:

On Mon,

> > > > <container>, while
simultaneously creating <leaf> which is part of

If the <edit-config> operation contains
multiple sub-operations

that apply to the same conceptual node in the
underlying data

model, then the result of the operation is undefined
(i.e.,

comes into play. Exactly as you say, target datastore
cannot complete

both the deletion and creation, since both operate on the
same data but

rule each other out.

> > > > thus, technically, this edit-config
operation operates on the

> > <key-node>

> instead of "inherited".

operation:  Elements in the <config> subtree
MAY contain an

"operation" attribute, which belongs to the
NETCONF namespace

defined in Section 3.1.  The attribute identifies
the point in

the configuration to perform the operation and
MAY appear on

multiple elements throughout the <config>
subtree.

If the "operation" attribute is not specified,
the

configuration is merged into the configuration
datastore.

in this case, the "operation" attribute for
<key-node> is not specified.

So the provided example request is equivalent to this
request:

<key-node
operation="merge">key-value</key-node>

</list>

so basically it's the same as above - there is a request
do delete

<list> while creating and/or keeping
<key-node> around - both cannot be

done. I cannot find any exception in the RFC for
list/key-node combo

case.

Perhaps 1 new sentence (After the 1 about no
attribute=merge):

If the operation attribute is not present for a key
leaf node, and

the edit operation for the parent node is "delete" or
"remove",

then the operation for the key leaf node is the same
as its parent node.

Andy

> > > > The RFC has
<default-operation>none</default-operation> in
all deletion

> > > > mentioned request, the
<key-node>'s operation would be "merge" and thus

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
ECN: 831 7320 Tel: +36-1-437-7320
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2014 07:54:59 -0700

On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <[email-masked]

>  Hello,
> I always tought the operation attribute is inherited.
>

This is how everybody implements it, and what we intended (pre-4741).
Otherwise, would a "replace" operation for some arbitrary subtree
require nc:operation="replace" in every replacement descendant node?

Andy

> Inherited in a sense that an XML element actually contains/includes all
> sub-elements under it. So creating/deleting/merging the element means
> creating/deleting/merging all its contents as well. So unless you later
> override this with more specific instructions for one of the contained
> elements it should be valid for the complete element with all its content.
>
> - default operation=none and I want to create a sizeable subtree. I have
> to place the merge/create operation on every node. Don't like it, makes
> none-unusable except for delete/remove.
> I want to create a static route with all its sub-elements but only if the
> static-routing presence container exists (static routing is
> allowed/enabled).
>    <static-routing>  --- this will check that static routing exists.
>       <route operation="create">  --this will create the interface
>          <routeid>1.1.1.1/24</routeid>   -- I don't want to put
> operation=create on all further nodes 5 times or more depending on the
> number of paths
>          <path-to-destination>
> On 2014-07-29 14:17, Andy Bierman wrote:
>
>
>
>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
> --

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Tue, 29 Jul 2014 15:03:00 +0000

> require nc:operation="replace" in every replacement descendant node?

Well if the default-operation is unchanged, then

<container operation="replace">
 <leaf/>
</container>

works perfectly fine if the operation for <leaf> is assumed to be a
"merge". First, the server removes the existing <container>, replaces it
with empty one and then merges the <leaf> in.

From this point of view, "merge" on child is compatible with "create" or
"replace" on parent.

I don't see any sentence in the RFC which says that the operation is
inherited.

---

From: Xiang Li <[email-masked]>
Date: Tue, 29 Jul 2014 10:38:10 -0500

On 7/29/2014 10:03 AM, Klement Sekera -X (ksekera - Pantheon 
> I don't see any sentence in the RFC which says that the operation is

RFC6243

  With-defaults Capability for NETCONF may help clarify wh "effective
  operation" means in an "edit-config":

        4.5.2 <http://tools.ietf.org/html/rfc6243#section-4.5.2>.
        <edit-config> Operation

...

If the 'default' attribute is present, then the effective operation
    for the target data node MUST be 'create', 'merge', or 'replace'.  If
    not, then the server MUST return an <rpc-error> response with an
    'invalid-value' error-tag.  For example, if 'create' is the effective
    operation, then the create request must be valid on its own (e.g.,
    current data node MUST NOT exist).  The procedure for determining the
    effective operation is defined in [RFC6241  <http://tools.ietf.org/html/rfc6241>].  I*t is derived from the
    'default-operation' parameter and/or any operation attributes that
    are present in the data node or any of its ancestor nodes, within the
    <edit-config> request.*

In other words the "operation" attribute has a "scope", that is, it applies
to the nested nodes, until is is redefined. This is logical too.

--Xiang Li

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Tue, 29 Jul 2014 16:01:38 +0000

> to the nested nodes, until is is redefined. This is logical too.

side-note: not every netconf server must support with-defaults
capability

It says that the operation is derived from default-operation and/or any
operation attributes present. Now RFC 6241 says:

      default-operation:  Selects the default operation (as described in
         the "operation" attribute) for this <edit-config> request.  The
         default value for the <default-operation> parameter is "merge".

so whenever a node does not have an operation attribute, this clause
forces the server to operate as if it was "merge", if not set to other
value. I think this is prevents any inheritance logic.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2014 09:11:05 -0700

On Tue, Jul 29, 2014 at 8:03 AM, Klement Sekera -X (ksekera - Pantheon

> I don't see any sentence in the RFC which says that the operation is

You don't see any text that specifies an implementation order for edits
within <edit-config> or <copy-config> operations.  This is intentionally
an implementation detail.

Andy

> have
> > >> > > > attribute is specified. The keys need to be present to specify
> the
> > >> list
> > >> > > > node to be deleted.
> > >> > >

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Tue, 29 Jul 2014 16:16:05 +0000

> an implementation detail.

What I meant to say is that the logic you described:

"Otherwise, would a "replace" operation for some arbitrary subtree
require nc:operation="replace" in every replacement descendant node?"

is not the only possible. It can do with default "merge" if implemented
the way I described.

---

From: Xiang Li <[email-masked]>
Date: Tue, 29 Jul 2014 11:41:36 -0500

On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera - Pantheon 
> side-note: not every netconf server must support with-defaults

The point is not about whether a sever supports " with-defaults 
capability". The paragraph
I quoted simply helps us see the  NETCONF protocol authors' intention.

> operation attributes present.

To be precise, RFC6243 says:

  It is derived from the 'default-operation' parameter and/or any operation attributes that
    are present in the data node or any of its ancestor nodes, within the
    <edit-config> request.

Notice the "ancestor nodes" wording.

**

> Now RFC 6241 says:
> value.

But if there is "operation" attribute specified in itself or any parent 
node then the effective
operation is not "merge" anymore.

>   I think this is prevents any inheritance logic.

I don't see why the sentence above prevents any inheritance.

RFC6241 says:

          defined inSection 3.1  <http://tools.ietf.org/html/rfc6241#section-3.1>.  The attribute identifies the point in

Notice the "point" wording used here. In other words "operation" identifies
a point (a subtree) where the config data should be applied. My understanding
is that it does not make sense if the "point" means the "element" here.

Perhaps it could be clearer if it were written as " the attribute identifies
the point and below in the configuration...".

--Xiang

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2014 19:18:19 -0700

Hi,

I know the intent was that the operation attribute was for the entire
sub-tree until explicitly
changed.

The preceding text on page 37 is incomplete.
Look further down on page 38 (default-operation parameter)

Obviously the text on page 37 is incomplete because the default-operation
overrides "merge".
It is very common to use default-operation="none" to make sure the target
resource already exists
when doing an update.

The text on page 37 needs to be updated somehow (as errata).
I don't think we agree on the text yet, but here is an attempt

RFC 6241, sec 7.2, para 6:

OLD:

NEW:

         If the "operation" attribute is not specified, then
         the operation applied to the parent data node of the configuration
         is used. If no parent data node is available, then the
'default-operation' value is used.

        Andy

On Tue, Jul 29, 2014 at 9:41 AM, Xiang Li <[email-masked]> wrote:

>
> On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera - Pantheon Technologies
> SRO at Cisco) wrote:
>
>         4.5.2 <http://tools.ietf.org/html/rfc6243#section-4.5.2> <http://tools.ietf.org/html/rfc6243#section-4.5.2>.
>         <edit-config> Operation
>
> ...
>
>     effective operation is defined in [RFC6241  <http://tools.ietf.org/html/rfc6241> <http://tools.ietf.org/html/rfc6241>].  I*t is derived from the
>          defined in Section 3.1 <http://tools.ietf.org/html/rfc6241#section-3.1>.  The attribute identifies the point in

--Xiang
  --Xiang Li
> Technologies SRO at Cisco) <[email-masked]> <[email-masked]> wrote:
>
>
> Technologies SRO at Cisco) <[email-masked]> <[email-masked]> wrote:
>
>
>  On Mon, Jul 28, 2014 at 8:11 AM, Klement Sekera -X (ksekera -
>
>   Pantheon
>
>   Technologies SRO at Cisco) <[email-masked]> <[email-masked]> wrote:
>
>
>  Hi all,
>
> we are currently debating an issue we found and would like to
>
>   have some
>
>   clarification. Netconf RFC says that the edit-config operation
>
>   which
>
> the outcome is undefined, since the client wants do delete
>
>   container
>
> possibly complete both a delete on an ancestor and create of a
>
>  descendant
>
> default-operation, the operation attribute for <key-node> is
>
>   "merge",
>
>   thus, technically, this edit-config operation operates on the
>
>  <key-node>
>
>  twice:
>
>
> attribute is specified. The keys need to be present to specify the
>
>   list
>
>   node to be deleted.
>
>  the delete operation on the /container node is for the container and
>
>  all its
>
>  descendants.  That is how it is inherited. I should have said
>
>  "effective"
>
>  operation
> instead of "inherited".
>
> The RFC has <default-operation>none</default-operation> in all
>
>   deletion
>
> mentioned request, the <key-node>'s operation would be "merge"
>
>   and thus
>
>   the operation undefined.
>

---

From: Xiang Li <[email-masked]>
Date: Wed, 30 Jul 2014 02:28:07 -0500

>           is used.If no parent data node is available, then the 'default-operation'value is used.

Adding this as an erratum would help clarify issue but it isn't 
absolutely needed, IMO. My
understanding is that this  is how XML attribute is supposed to work.  
For example,  you
don't need to specify XML namespace attribute on each element. The way 
the "operation"
implicitly inherits from parent is exactly the same as child elements 
inherit  their "namespace"
  attributes their parent nodes.

--Xiang

>          
> Andy
>
>
>
> On Tue, Jul 29, 2014 at 9:41 AM, Xiang Li <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>>>>     On Tue, Jul 29, 2014 at 7:43 AM, Balazs Lengyel <[email-masked]  <mailto:[email-masked]>
>>>>>>     wrote:
>>>>>>        Hello,
>>>              4.5.2<http://tools.ietf.org/html/rfc6243#section-4.5.2>  <http://tools.ietf.org/html/rfc6243#section-4.5.2>.
>>>              <edit-config> Operation
>>>
>>>     ...
>>>
>>>          effective operation is defined in [RFC6241<http://tools.ietf.org/html/rfc6241>  <http://tools.ietf.org/html/rfc6241>].  I*t is derived from the
>     But if there is "operation" attribute specified in itself or any
>     parent node then the effective
>>>>>>                <routeid>1.1.1.1/24  <http://1.1.1.1/24></routeid>   -- I don't want to put
>>>>>>     Technologies SRO at Cisco)<[email-masked]>  <mailto:[email-masked]>  wrote:
>>>>>>
>>>>>>>>     Technologies SRO at Cisco)<[email-masked]>  <mailto:[email-masked]>  wrote:
>>>>>>>>
>>>>>>>>>>     Technologies SRO at Cisco)<[email-masked]>  <mailto:[email-masked]>  wrote:
>>>>>>>>>>
>>>>>>>>>>>     Hi all,
>>>>>>>>>>>
>>>>>>>>>>>     [email-masked]  <mailto:[email-masked]>
>>>>>>     Netconf [email-masked]://www.ietf.org/mailman/listinfo/netconf  <mailto:[email-masked]://www.ietf.org/mailman/listinfo/netconf>
>>>>>>
>>>>>>
>>>>>>     --
>>>>>>     Mobile: +36-70-330-7909              email:[email-masked]  <mailto:[email-masked]>
>>>>>>
>>>>>>
>>>>     [email-masked]  <mailto:[email-masked]>
>>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341

---

From: "Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Wed, 30 Jul 2014 08:59:23 +0000

> >           is used.If no parent data node is available, then the 'default-operation'value is used.

This would clear up any confusion.

>   attributes their parent nodes.

I think that xml namespace is a special case and that xml attributes are
not inheritted by default.

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 30 Jul 2014 16:58:29 +0200

I would vote for errata on RFC 6241 as Andy described.

Even if the inheritance is IMHO the XML way and thus natural, the
effect of the default operation is missing from the paragraph.

Balazs

On 2014-07-30 04:18, Andy Bierman
wrote:

Hi,

I know the intent was that the operation attribute was
for the entire sub-tree until explicitly

changed.

Look further down on page 38 (default-operation
parameter)

Obviously the text on page 37 is incomplete because the
default-operation overrides "merge".

It is very common to use default-operation="none" to make
sure the target resource already exists

when doing an update.

The text on page 37 needs to be updated somehow (as
errata).

I don't think we agree on the text yet, but here is an
attempt

OLD:

NEW:

If the "operation" attribute is not specified, then
the operation applied to the parent data node of the configuration
is used. If no parent data node is available, then the 'default-operation' value is used.

Andy

On Tue, Jul 29, 2014 at 9:41 AM,
Xiang Li <[email-masked]>
wrote:

On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera -
Pantheon Technologies SRO at Cisco) wrote:

wrote:
Hello,

Andy

RFC6243

...

The point is not about whether a sever supports "
with-defaults capability". The paragraph

I quoted simply helps us see the  NETCONF protocol
authors' intention.

Now RFC 6241 says:

But if there is "operation" attribute specified in
itself or any parent node then the effective

I don't see why the sentence above prevents any
inheritance.

RFC6241 says:

--Xiang

--Xiang Li

routing
+--static-routing
| +--route [routeId]
| +--routeId ipprefix

Pantheon

Hi all,

have some

which

<edit-config>

container

It is defined.

descendant

<edit-config>

"merge",

<key-node>

twice:

list

node to be deleted.

all its

"effective"

operation
instead of "inherited".

Andy

deletion

and thus

the operation undefined.

the latter

Thanks,
Klement

Andy

--
--
Xiang Li,
Seguesoft, Champaign, IL
(217) 721-5341

Netconf mailing list

[email-masked]

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 30 Jul 2014 17:01:41 +0200

So Andy, why don't you file a formal erratum with the RFC-Editor,
then we get to automagially process it.

Bert

On 30/07/14 16:58, Balazs Lengyel wrote:
> Even if the inheritance is IMHO the XML way and thus natural, the effect of the default operation is missing from the paragraph.
> Balazs
>
> On 2014-07-30 04:18, Andy Bierman wrote:
>> Hi,
>>
>>
>> I know the intent was that the operation attribute was for the entire sub-tree until explicitly
>> changed.
>>
>> Obviously the text on page 37 is incomplete because the default-operation overrides "merge".
>> It is very common to use default-operation="none" to make sure the target resource already exists
>> when doing an update.
>>
>> On Tue, Jul 29, 2014 at 9:41 AM, Xiang Li <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>     On 7/29/2014 11:01 AM, Klement Sekera -X (ksekera - Pantheon Technologies SRO at Cisco) wrote:
>>     The point is not about whether a sever supports " with-defaults capability". The paragraph
>>     But if there is "operation" attribute specified in itself or any parent node then the effective
> Mobile: +36-70-330-7909              email:[email-masked]
>
>
>