Subject: [Netconf] What should a server response be?

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 11 Jul 2016 13:47:58 -0700

The Opendaylight controller is constructing this particular set of <edit-config> requests as part of a single transaction. The response of the server is to reject the configuration that the particular node (evpn container) does not exist. 

However, if the default-operation=none is removed or changed to replace, the server responds with an RPC OK.

Is the server right in its interpretation of what RFC 6241 says? In particular, the way the server is interpreting this request is as follows from Section 7.2 of the RFC:

         none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.

and then this:

      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1 <https://tools.ietf.org/html/rfc6241#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.

1st request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-23">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <error-option>rollback-on-error</error-option>
    <config>
      <evpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>">
        <evpn-tables/>
      </evpn>
    </config>
  </edit-config>
</rpc>
##
 
The container evpn in this case is a non-presence container and does not contain any mandatory leafs or default statements. The server therefore interprets that nothing has to be done here, as it is not required to create a empty container.
 
2nd request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-24">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <error-option>rollback-on-error</error-option>
    <config>
      <evpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>">
        <evpn-tables>
          <evpn-load-balancing xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
            <enable/>
            <evpn-flow-label/>
          </evpn-load-balancing>
        </evpn-tables>
      </evpn>
    </config>
  </edit-config>
</rpc>
##

In the second request, the default-operation=none again seems to imply that nothing needs to be done for creation of the evpn node. Therefore by the time the evpn-load-balancing request rolls around, the request is rejected as the parent container does not exist. As stated earlier, if the default-operation is removed (causing a default of merge) or replaced with a replace, the transaction succeeds.

A second interpretation to this transaction is that the server should have created the evpn node as part of the first request, and that the none operation was implying that the node had already been created.

Which interpretation is correct, and what sections of the RFC can one cite to support the argument?

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Xiang Li <[email-masked]>
Date: Tue, 12 Jul 2016 11:28:57 -0500

On 7/11/2016 3:47 PM, Mahesh Jethanandani wrote:
> The Opendaylight controller is constructing this particular set of 
> <edit-config> requests as part of a single transaction. The response 
> of the server is to reject the configuration that the particular node 
> (evpn container) does not exist.
>
> However, if the default-operation=none is removed or changed to 
> replace, the server responds with an RPC OK.
>
> Is the server right in its interpretation of what RFC 6241 says? In 
> particular, the way the server is interpreting this request is as 
> follows from Section 7.2 of the RFC:
>
>           none:The target datastore is unaffected by the configuration in the 
> <config> parameter, unless and until the incoming configuration data 
> uses the "operation" attribute to request a different operation.   If the configuration in the <config>
>           defined inSection 3.1 <https://tools.ietf.org/html/rfc6241#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.
>
>
> *_1^st  request:_*
>       <evpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
> <evpn-tables/>
>       </evpn>
>     </config>
>   </edit-config>
> </rpc>
> ##
> The container evpn in this case is a non-presence container and does 
> not contain any mandatory leafs or default statements. The server 
> therefore interprets that nothing has to be done here, as it is not 
> required to create a empty container.

I think the container node needs to be created when you are merging to 
create new nodes explicitly.
RFC6020
7.5.  The container Statement
    7.5.8.  NETCONF <edit-config> Operations

     When a NETCONF server processes an <edit-config> request, the
     elements of procedure for the container node are:

       If the operation is "merge" or "replace", the node is created if
       it does not exist.

It makes no sense to me for the server to return ok but actually does 
not create that
container node in this case.

The server may delete an empty container node but only when you deleting 
stuff:

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

> *_2^nd  request:_*
>       <evpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
> <evpn-tables>
> In the second request, the default-operation=none again seems to imply 
> that nothing needs to be done for creation of the evpn node. Therefore 
> by the time the evpn-load-balancing request rolls around, the request 
> is rejected as the parent container does not exist. As stated earlier, 
> if the default-operation is removed (causing a default of merge) or 
> replaced with a replace, the transaction succeeds.
>
> A second interpretation to this transaction is that the server should 
> have created the evpn node as part of the first request, and that the 
> none operation was implying that the node had already been created.
>

If the server returns ok for the first <edit-config>, then it means it 
has successfully created the top two container nodes in the hierarchy:

       <evpn >
         <evpn-tables>

then the second request should have succeeded.

-Xiang Li

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 12 Jul 2016 18:45:36 -0700

> On Jul 12, 2016, at 9:28 AM, Xiang Li <[email-masked]> wrote:
> 
>>       <evpn xmlns=" <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>">
>>         <evpn-tables/>
>>       </evpn>
>>     </config>
>>   </edit-config>
>> </rpc>
>> ##
>>  
> I think the container node needs to be created when you are merging to create new nodes explicitly.
> RFC6020 
> It makes no sense to me for the server to return ok but actually does not create that

And that is the clarification I am seeking. Note, it is an empty non-presence container. Should the server create this empty container, and if so how would it be represented in the config tree? In this particular case, the request is followed by child nodes. What happens if no child nodes are created?

> 
> 
> The server may delete an empty container node but only when you deleting stuff:
> 

For a delete it is clear. But the RFC is silent for a create (and the default operation of merge). If a non-presence empty container can be deleted, why should it be created?

Thanks.

>>       <evpn xmlns=" <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>">
>>         <evpn-tables>
> If the server returns ok for the first <edit-config>, then it means it has successfully created the top two container nodes in the hierarchy:
> 
>       <evpn >
>         <evpn-tables>
> 

Mahesh Jethanandani
[email-masked]

---

From: "Einar Nilsen-Nygaard (einarnn)" <[email-masked]>
Date: Wed, 13 Jul 2016 20:58:00 +0000

I'd like to call out a second example and provide my interpretation. It is also an ODL-based interaction, but with a different request. For reference, the model being used in my example is the same one as Mahesh's, and if people want more context the source may be found here:

https://github.com/einarnn/yang/blob/611-early-access/vendor/cisco/xr/611/Cisco-IOS-XR-l2vpn-cfg.yang

The first request is:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="...">
  <nc:edit-config>
    <nc:target>
      <nc:candidate/>
    </nc:target>
    <nc:default-operation>none</nc:default-operation>
    <config>
      <l2vpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg" nc:operation="merge">
         <database>
           <bridge-domain-groups/>
         </database>
      </l2vpn>
    </config>
  </nc:edit-config>
</nc:rpc>

The request only contains empty non-presence containers, and the salient points here seem to be that the default operation is none, but this is overridden at the l2vpn node with merge. I believe that this means the three levels of container should be considered as "created" in the context of the candidate config we are working on.

The second request is:

<?xml version="1.0" encoding="UTF-8"?>
<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="...">
  <nc:edit-config>
    <nc:target>
      <nc:candidate/>
    </nc:target>
    <nc:default-operation>none</nc:default-operation>
    <config>
      <l2vpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
        <database>
          <bridge-domain-groups>
            <bridge-domain-group nc:operation="replace">
              <name>SERVICE</name>
              <bridge-domains>
                <bridge-domain>
                  <name>ESP-vPE1</name>
                  <bd-attachment-circuits>
                    <bd-attachment-circuit>
                      <name>Bundle-Ether46001.1</name>
                    </bd-attachment-circuit>
                  </bd-attachment-circuits>
                </bridge-domain>
              </bridge-domains>
            </bridge-domain-group>
          </bridge-domain-groups>
        </database>
      </l2vpn>
    </config>
  </nc:edit-config>
</nc:rpc>

Again, the default operation is none, and in this request it is not overridden until the container "bridge-domain-group", with replace. This request builds on the first request, and from reading RFC 6241 it seems to me that a commit after receiving the second request should (with no other problems) succeed.

It may be a slightly odd pattern that ODL is exhibiting here, but I believe it should work with no issues.

Cheers,

Einar

On Jul 13, 2016, at 2:45 AM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 12, 2016, at 9:28 AM, Xiang Li <[email-masked]<mailto:[email-masked]>> wrote:

and then this:

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

1st request:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-23">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <error-option>rollback-on-error</error-option>
    <config>
      <evpn xmlns="<http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
        <evpn-tables/>
      </evpn>
    </config>
  </edit-config>
</rpc>
##

Thanks.

2nd request:

      <evpn xmlns="<http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">

      <evpn >
        <evpn-tables>

-Xiang Li

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

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

---

From: Giles Heron <[email-masked]>
Date: Wed, 13 Jul 2016 14:31:55 -0700

Hi Einar,

> On 13 Jul 2016, at 13:58, Einar Nilsen-Nygaard (einarnn) <[email-masked]> wrote:
> 
> https://github.com/einarnn/yang/blob/611-early-access/vendor/cisco/xr/611/Cisco-IOS-XR-l2vpn-cfg.yang <https://github.com/einarnn/yang/blob/611-early-access/vendor/cisco/xr/611/Cisco-IOS-XR-l2vpn-cfg.yang>
> 
> The first request is:
>       <l2vpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>" nc:operation="merge">
>          <database>
>            <bridge-domain-groups/>
>          </database>
>       </l2vpn>
>     </config>
>   </nc:edit-config>
> </nc:rpc>
>       <l2vpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>">
>         <database>
>           <bridge-domain-groups>

agreed on both counts.

I pinged the ODL netconf-dev mailing list (CCed) a week ago to ask why the change from merge to replace.   I’ve not heard back but maybe someone will respond this time...

Giles

> Cheers,
> 
> Einar
> 
> 
>> On Jul 13, 2016, at 2:45 AM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>> On Jul 12, 2016, at 9:28 AM, Xiang Li <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>> [email-masked] <mailto:[email-masked]>
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: Xiang Li <[email-masked]>
Date: Wed, 13 Jul 2016 16:55:26 -0500

On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:
>>> of the server is to reject the configuration that the particular 
>>> node (evpn container) does not exist.
>>>
>>>           defined inSection 3.1 <https://tools.ietf.org/html/rfc6241#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.
>>>
>>>
>>> *_1^st  request:_*
> And that is the clarification I am seeking. Note, it is an empty 
> non-presence container. Should the server create this empty container, 
> and if so how would it be represented in the config tree? In this 
> particular case, the request is followed by child nodes. What happens 
> if no child nodes are created?
>

My understanding is that it does not matter if it is a presence 
container or not in this case
, nor if there are child nodes included  to be created.

> For a delete it is clear. But the RFC is silent for a create (and the 
> default operation of merge).

I think RFC6020 7.5.8.  "NETCONF <edit-config> Operations" (for 
container node)
covers this :

-    When a NETCONF server processes an <edit-config> request, the
-    elements of procedure for the container node are:
-
-      If the operation is "merge" or "replace", the node is created if
-      it does not exist.
      
-      If the operation is "create", the node is created if it does not
-      exist.  If the node already exists, a "data-exists" error is
-      returned.

> If a non-presence empty container can be deleted, why should it be 
> created?

It is because the client is sending an <edit-config>  to create this 
container explicitly.
If a client wants to create *only* a container node, it can certainly do 
so without
having to specify any child instance nodes. If the server returns "Ok" 
for such
a request then it must mean it has indeed created the container node.

I think it makes little sense for a server to return "Ok" but does not 
create
the container node (thinking nothing needs to be done if there are no 
child nodes
included in the same request). The "Ok" response must mean something, i.e.,
the create/merge/replace operations has actually succeeded in creating the
container node in question.

-Xiang

>>>           <evpn-load-balancing 
>>> xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
>>>             <enable/>
>>>             <evpn-flow-label/>
>>>           </evpn-load-balancing>
>>>         </evpn-tables>
>>>       </evpn>
>>>     </config>
>>>   </edit-config>
>>> </rpc>
>>> ##
>>>
>>> In the second request, the default-operation=none again seems to 
>>> imply that nothing needs to be done for creation of the evpn node. 
>>> Therefore by the time the evpn-load-balancing request rolls around, 
>>> the request is rejected as the parent container does not exist. As 
>>> stated earlier, if the default-operation is removed (causing a 
>>> default of merge) or replaced with a replace, the transaction succeeds.
>>>
>>> A second interpretation to this transaction is that the server 
>>> should have created the evpn node as part of the first request, and 
>>> that the none operation was implying that the node had already been 
>>> created.
>>>
>>
>>
>> If the server returns ok for the first <edit-config>, then it means 
>> it has successfully created the top two container nodes in the hierarchy:
>>
>> <evpn >
>> <evpn-tables>
>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jul 2016 14:58:32 -0700

Hi,

The implementation has bugs.
The RFC is clear wrt/ operation=none vs merge or replace.

Andy

On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li <[email-masked]> wrote:

> On Jul 12, 2016, at 9:28 AM, Xiang Li < <[email-masked]>
> [email-masked]> wrote:
>
> <edit-config> requests as part of a single transaction. The response of the
> server is to reject the configuration that the particular node (evpn
> container) does not exist.
>
> particular, the way the server is interpreting this request is as follows
> from Section 7.2 of the RFC:
>
> *1st request:*
>       <evpn xmlns=" <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>
> http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
>         <evpn-tables/>
>       </evpn>
>     </config>
>   </edit-config>
> </rpc>
> ##
>
> The container evpn in this case is a non-presence container and does not
> contain any mandatory leafs or default statements. The server therefore
> interprets that nothing has to be done here, as it is not required to
> create a empty container.
>
>
>
>
> non-presence container. Should the server create this empty container, and
> if so how would it be represented in the config tree? In this particular
> case, the request is followed by child nodes. What happens if no child
> nodes are created?
>
>
> My understanding is that it does not matter if it is a presence container
> or not in this case
> I think RFC6020 7.5.8.  "NETCONF <edit-config> Operations" (for container
> node)
> covers this :
>
> If a non-presence empty container can be deleted, why should it be created?
>
>
>
> having to specify any child instance nodes. If the server returns "Ok" for
> such
> *2nd request:*
>       <evpn xmlns=" <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>
> http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg">
>         <evpn-tables>
>           <evpn-load-balancing
> that nothing needs to be done for creation of the evpn node. Therefore by
> the time the evpn-load-balancing request rolls around, the request is
> rejected as the parent container does not exist. As stated earlier, if the
> default-operation is removed (causing a default of merge) or replaced with
> a replace, the transaction succeeds.
>
> A second interpretation to this transaction is that the server should have
> created the evpn node as part of the first request, and that the none
> operation was implying that the node had already been created.
>
>
>
> If the server returns ok for the first <edit-config>, then it means it has
> successfully created the top two container nodes in the hierarchy:
>
>       <evpn >
>         <evpn-tables>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jul 2016 09:10:08 -0700

Hi,

Mahesh asked me to be more specific.
If the server is returning <ok/> for edit 1 but the candidate datastore
is still empty after edit 1 then this is a server bug.

Andy

On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman <[email-masked]> wrote:

>> have created the evpn node as part of the first request, and that the none

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jul 2016 09:15:57 -0700

Hi,

I can see the confusion because of the sloppy text in RFC 6241.
NP containers have always been a problem.  The NETMOD WG did a poor job
of defining them in an interoperable way.

IMO the server should not delete NP containers for exactly the cases you
point out.
The server does not know the client's intentions so why is it deleting
nodes?
Also, YANG 1.1 XPath rules treat NP containers as if they are always
present.
(So the text about MAY delete NP containers is even more confusing).

Andy

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Thu, 14 Jul 2016 18:47:40 +0000

IMO those examples from Mahesh and Einar should all succeed.

But after the 1st request I don’t think a <get-config> is required to return any empty NP containers.  So I’m not sure that I’m totally in agreement with Xiang Li.  A create of an NP container can return an OK but then a subsequent <get-config> can filter out empty NP containers.

Returning NP containers (whether they were explicitly created or not) seems like it would product a lot of unnecessary noise in a response.

Regards,
Jason

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, July 14, 2016 12:16
To: Xiang Li
Cc: Netconf
Subject: Re: [Netconf] What should a server response be?

Hi,

IMO the server should not delete NP containers for exactly the cases you point out.
The server does not know the client's intentions so why is it deleting nodes?
Also, YANG 1.1 XPath rules treat NP containers as if they are always present.
(So the text about MAY delete NP containers is even more confusing).

Andy

On Thu, Jul 14, 2016 at 9:10 AM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Andy

On Wed, Jul 13, 2016 at 2:58 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Andy

On Wed, Jul 13, 2016 at 2:55 PM, Xiang Li <[email-masked]<mailto:[email-masked]>> wrote:
On 7/12/2016 8:45 PM, Mahesh Jethanandani wrote:

            to be deleted.

and then this:

1st request:

      it does not exist.

My understanding is that it does not matter if it is a presence container or not in this case
, nor if there are child nodes included  to be created.

For a delete it is clear. But the RFC is silent for a create (and the default operation of merge).

I think RFC6020 7.5.8.  "NETCONF <edit-config> Operations" (for container node)
covers this :

-

-      it does not exist.

-      returned.

It is because the client is sending an <edit-config>  to create this container explicitly.
If a client wants to create *only* a container node, it can certainly do so without
having to specify any child instance nodes. If the server returns "Ok" for such
a request then it must mean it has indeed created the container node.

I think it makes little sense for a server to return "Ok" but does not create
the container node (thinking nothing needs to be done if there are no child nodes
included in the same request). The "Ok" response must mean something, i.e.,
the create/merge/replace operations has actually succeeded in creating the
container node in question.

-Xiang

Thanks.

2nd request:

-Xiang Li

Mahesh Jethanandani

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jul 2016 12:00:53 -0700

Hi,

The problem is this horrible text in the YANG RFC:

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.5.8

This is a good example of why is a bad idea to define NETCONF protocol
details
in the YANG spec.

NETCONF itself never says it is OK for the server to delete edits from the
client.
(This is especially dumb in the candidate config because its sole purpose is
to be a scratchpad for incremental edits)

So I have to say to server is allowed to delete the empty NP containers,
and the manager needs to guard against server implementations that delete
empty NP containers.

This sort of variability without purpose harms interoperability.

Andy

On Thu, Jul 14, 2016 at 11:47 AM, Sterne, Jason (Nokia - CA) <
[email-masked]> wrote:

> But after the 1st request I don’t think a <get-config> is required to
> return any empty NP containers.  So I’m not sure that I’m totally in
> agreement with Xiang Li.  A create of an NP container can return an OK but
> then a subsequent <get-config> can filter out empty NP containers.
>
>
>
> Returning NP containers (whether they were explicitly created or not)
> seems like it would product a lot of unnecessary noise in a response.
>
>
>
> Regards,
>
> Jason
>
>
>
> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, July 14, 2016 12:16
> *To:* Xiang Li
> *Cc:* Netconf
> *Subject:* Re: [Netconf] What should a server response be?
>
>
>
> Hi,
>
>
>

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Thu, 14 Jul 2016 19:08:05 +0000

I guess I don’t really see NP-containers as “config”.  They are just structure and filtered out when empty.  I don’t really see this as the server “deleting” those containers.  It just suppresses them in <get-config> output.

The server should not error in the cases Mahesh & Einar show -> the presence/existence of NP-containers shouldn’t really affect behavior (since they aren’t really config).

But I’m not positive what you mean by “manager needs to guard”.  Do you agree that the server should not error in those cases below ?

Jason

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, July 14, 2016 15:01
To: Sterne, Jason (Nokia - CA)
Cc: Xiang Li; Netconf
Subject: Re: [Netconf] What should a server response be?

Hi,

This is a good example of why is a bad idea to define NETCONF protocol details
in the YANG spec.

NETCONF itself never says it is OK for the server to delete edits from the client.
(This is especially dumb in the candidate config because its sole purpose is
to be a scratchpad for incremental edits)

Andy

On Thu, Jul 14, 2016 at 11:47 AM, Sterne, Jason (Nokia - CA) <[email-masked]<mailto:[email-masked]>> wrote:
IMO those examples from Mahesh and Einar should all succeed.

Regards,
Jason

From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Thursday, July 14, 2016 12:16
To: Xiang Li
Cc: Netconf
Subject: Re: [Netconf] What should a server response be?

Hi,

Andy

Andy

Andy

            to be deleted.

and then this:

1st request:

      it does not exist.

-

-      it does not exist.

-      returned.

-Xiang

Thanks.

2nd request:

-Xiang Li

Mahesh Jethanandani

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jul 2016 12:17:47 -0700

On Thu, Jul 14, 2016 at 12:08 PM, Sterne, Jason (Nokia - CA) <
[email-masked]> wrote:

> I guess I don’t really see NP-containers as “config”.  They are just
> structure and filtered out when empty.  I don’t really see this as the
> server “deleting” those containers.  It just suppresses them in
> <get-config> output.
>
>
>

Please show me the RFC text that says the server can filter out NP
containers.
All config=true data nodes are config.
A false must-stmt in an NP-container is still an error.
As Lada has pointed out many times, the text about
NP containers not being part of the data model is just wrong.

> The server should not error in the cases Mahesh & Einar show -> the
> presence/existence of NP-containers shouldn’t really affect behavior (since
> they aren’t really config).
>
>
>
> But I’m not positive what you mean by “manager needs to guard”.  Do you
> agree that the server should not error in those cases below ?
>

The YANG text says a server MAY delete an empty NP container.
Using default-operation=none implies that the client is sure the nodes for
operation=none
actually exist.  Because of this YANG detail, the client cannot be sure so
using
default-operation=none may not work.

Andy

>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Thursday, July 14, 2016 15:01
> *To:* Sterne, Jason (Nokia - CA)
> *Cc:* Xiang Li; Netconf

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 14 Jul 2016 12:59:31 -0700

> On Jul 14, 2016, at 12:17 PM, Andy Bierman <[email-masked]> wrote:
> 
> Using default-operation=none implies that the client is sure the nodes for operation=none
> actually exist.  Because of this YANG detail, the client cannot be sure so using

That to me is where the disconnect lies between the client and server. The client is assuming that the nodes were created as part of the first request, while the server is “deleting" it because it is an empty NP container. Can the text be clarified to make it clearer? Something along the lines that a NP container should be deleted only if no other child nodes exist in the same transaction.

Semantically, it would have made no difference to the operation if the client decided not to set the default-operation=none or even set it to ‘replace' and the server would have to respond with an ok.

Mahesh Jethanandani
[email-masked]

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Thu, 14 Jul 2016 20:06:17 +0000

I don’t think it would help to say “only if no other child nodes exist in the same transaction”.  Those 2 requests should work even if there is a commit after each one.

Maybe we should instead clarify that an edit shouldn’t fail due to an absent NP-container ?  (i.e. absence/presence of an NP-container should be “moot”).

From: Mahesh Jethanandani [mailto:[email-masked]]
Sent: Thursday, July 14, 2016 16:00
To: Andy Bierman
Cc: Sterne, Jason (Nokia - CA); Netconf
Subject: Re: [Netconf] What should a server response be?

On Jul 14, 2016, at 12:17 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Mahesh Jethanandani

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 14 Jul 2016 23:15:01 +0200

> Please show me the RFC text that says the server can filter out NP containers.

In a very technical sense, I suppose the above statement is correct. An NP container is of course config true if it sits in the config true part of the tree. At the same time I agree with Janson's view that NP containers are just structure, so the question of their "existence" is moot.

Here's what RFC 6020, sec 7.5 says on the topic:

   YANG supports two styles of containers, those that exist only for
   organizing the hierarchy of data nodes, and those whose presence in
   the configuration has an explicit meaning.

So NP containers "exist only for organizing the hierarchy" while a P container "has an explicit meaning". I guess this implies NP containers having no meaning. Further down in 7.5.1, re P containers, it is noted that:

   In the second style, the presence of the container itself is
   configuration data, representing a single bit of configuration data.
   The container acts as both a configuration knob and a means of
   organizing related configuration.  These containers are explicitly
   created and deleted.

Based on these fragments, I conclude that NP containers have zero bits of information. This means the existence/absence of an NP container cannot be known/stored/remembered even internally by a conforming system. The existence/absence of an NP container is a moot question. It's a bit like asking for the value of a void function. It's there, it has a name, but no value.

Implementations that receive a <get> or <get-config> request that contains an NP container will have to decide whether to include the NP container in the response or not. Since the existence of the NP container cannot be read from a database/etc (it has zero bits of information), the implementation will have to use some other way to determine whether to include it or not.

In order to make the life easier for implementors, the following MAY was introduced in sec 7.5.7:

   A NETCONF server that replies to a <get> or <get-config> request MAY
   choose not to send a container element if the container node does not
   have the "presence" statement and no child nodes exist.

So the NP container has to be included if it has children, or else the structural function of the container would be lost. If the NP container is empty, it may or may not be sent. Since an NP container has zero bits of information, this decision would not be based on whether it has been previously "created" or "deleted", but on implementation considerations. One possible approach is to always include it, another to actually check if there are any children, and only return it then.

Either way, NP containers alone have no meaning/information, they are only there for structure.

> A false must-stmt in an NP-container is still an error.

Certainly. Must statements on an NP container are always evaluated, even if the container hasn't been "created" or mentioned by a client, and even if it has no child elements.

> NP containers not being part of the data model is just wrong.

I think the length of this discussion implies we should include this topic in the upcoming YANG FAQ.
> The server should not error in the cases Mahesh & Einar show -> the presence/existence of NP-containers shouldn’t really affect behavior (since they aren’t really config).
I agree with the above.
> default-operation=none may not work.

I disagree with this conclusion. Even using default-operation=none the transactions must be guaranteed to work by a conforming implementation. NP containers cannot be created/deleted in a deeper sense of the word since they have zero information content. They can only be referred to. Any must statements within the container must be evaluated regardless of the client ever mentioning the container.

/jan

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jul 2016 14:48:31 -0700

On Thu, Jul 14, 2016 at 2:15 PM, Jan Lindblad <[email-masked]> wrote:

> In a very technical sense, I suppose the above statement is correct. An NP
> container is of course config true if it sits in the config true part of
> the tree. At the same time I agree with Janson's view that NP containers
> are just structure, so the question of their "existence" is moot.
>
> So NP containers "exist only for organizing the hierarchy" while a P
> container "has an explicit meaning". I guess this implies NP containers
> having no meaning. Further down in 7.5.1, re P containers, it is noted that:
>
> Based on these fragments, I conclude that NP containers have zero bits of
> information. This means the existence/absence of an NP container cannot be
> known/stored/remembered even internally by a conforming system. The
> existence/absence of an NP container is a moot question. It's a bit like
> asking for the value of a void function. It's there, it has a name, but no
> value.
>
> Implementations that receive a <get> or <get-config> request that contains
> an NP container will have to decide whether to include the NP container in
> the response or not. Since the existence of the NP container cannot be read
> from a database/etc (it has zero bits of information), the implementation
> will have to use some other way to determine whether to include it or not.
>
> So the NP container has to be included if it has children, or else the
> structural function of the container would be lost. If the NP container is
> empty, it may or may not be sent. Since an NP container has zero bits of
> information, this decision would not be based on whether it has been
> previously "created" or "deleted", but on implementation considerations.
> One possible approach is to always include it, another to actually check if
> there are any children, and only return it then.
>
> Certainly. Must statements on an NP container are always evaluated, even
> if the container hasn't been "created" or mentioned by a client, and even
> if it has no child elements.
>
> I disagree with this conclusion. Even using default-operation=none the
> transactions must be guaranteed to work by a conforming implementation. NP
> containers cannot be created/deleted in a deeper sense of the word since
> they have zero information content. They can only be referred to. Any must
> statements within the container must be evaluated regardless of the client
> ever mentioning the container.
>
>

I do not agree that default-operation=none does not apply to NP containers.

This is why it was such a bad decision to spread little pieces of NETCONF
all over the YANG RFC. RFC 6241 defines the 'default-operation' leaf
and it does not say anything about special treatment for NP containers.

Andy

---

From: Xiang Li <[email-masked]>
Date: Thu, 14 Jul 2016 16:56:40 -0500

Hi
 >...
 > NP containers cannot be created/deleted in a deeper sense of the word 
since they have zero information content.
 > They can only be referred to.

So the operation on a NP container element carries no meaning?
I don't find RFC6020 says the "None" operation on a NP container should be
handled differently than other nodes.

Currently the paragraph does suggest that a  NP container
can be created/deleted explicitly, even there are no child nodes.

https://www.ietf.org/id/draft-ietf-netmod-rfc6020bis-14.txt

    Containers can be created, deleted, replaced, and modified through
    <edit-config>, by using the "operation" attribute (see [RFC6241],
    Section 7.2) in the container's XML element.

       If the operation is "create", the node is created if it does not
       exist.  If the node already exists, a "data-exists" error is
       returned.

       If the operation is "delete", the node is deleted if it exists.
       If the node does not exist, a "data-missing" error is returned.

-Xiang

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 15 Jul 2016 08:46:04 +0200

In order to reach rough consensus on the interpretation of the default-operation=none sequence, I think we need to start with coming to a common understanding of what NP containers are. Can NP containers be "created" and "deleted" just like P containers?

Here's a test to see if there is any difference between the behavior of p and np containers:

list t {
    key a;
    leaf a { type uint32; }
    container np {
        must "../a > 10";
    }
    container p {
        presence "...";
        must "../a > 20";
    }
}

The config is initially empty. Now, would it be possible to

a) create an instance with a = 5 if there is no mention of np and p in the edit-config?
b) create an instance with a = 5 if np (but not p) is "created" in the edit-config?
c) create an instance with a = 15 if there is no mention of np and p in the edit-config?
d) create an instance with a = 15 if p is created in the edit-config?

My own answer is that only operation c is allowed. "creation" of an NP container is irrelevant, while creation of a P container makes a difference. An NP container is simply a structural element, and does not need to be "created" to exist, but empty NP containers MAY not be reported since they are meaningless anyway.

If must statements in np containers are in effect even if the client isn't explicitly "creating" or mentioning the container, then I find it hard to understand the viewpoint that "creation" of NP containers makes any difference.

/jan

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jul 2016 00:24:51 -0700

Hi,

I do not like NP containers at all.
They have so many special rules.
I don't know what problem is being solved by having them at all.
Also RFC 6241 defines NETCONF, not YANG.

Even in the YANG 1.1 spec, it says MAY delete but does not say MAY create
anywhere.
YANG does not say NP containers cannot be created or deleted
by the client.

Andy

On Thu, Jul 14, 2016 at 11:46 PM, Jan Lindblad <[email-masked]> wrote:

> In order to reach rough consensus on the interpretation of the
> default-operation=none sequence, I think we need to start with coming to a
> common understanding of what NP containers are. Can NP containers be
> "created" and "deleted" just like P containers?
>
> My own answer is that only operation c is allowed. "creation" of an NP
> container is irrelevant, while creation of a P container makes a
> difference. An NP container is simply a structural element, and does not
> need to be "created" to exist, but empty NP containers MAY not be reported
> since they are meaningless anyway.
>
> If must statements in np containers are in effect even if the client isn't
> explicitly "creating" or mentioning the container, then I find it hard to
> understand the viewpoint that "creation" of NP containers makes any
> difference.
>
> /jan
>
>> In a very technical sense, I suppose the above statement is correct. An
>> NP container is of course config true if it sits in the config true part of
>> Implementations that receive a <get> or <get-config> request that
>> contains an NP container will have to decide whether to include the NP
>> container in the response or not. Since the existence of the NP container
>> cannot be read from a database/etc (it has zero bits of information), the
>> implementation will have to use some other way to determine whether to
>> include it or not.
>>

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 15 Jul 2016 11:32:10 +0000

When we say “NP containers can be created/deleted” I generally interpret that to mean that it is valid to have an operation=’delete’ (or create or remove or merge) on an NP container node in an <edit-config> request (either directly or inherited).

I don’t think there should be any real meaning to the existence/presence (or not) of NP containers in a datastore.   But it does seem this isn’t very clearly laid out in the RFCs.

They are pretty useful for data model organization (at least for humans looking at data/models).

Jason

From: Andy Bierman [mailto:[email-masked]]
Sent: Friday, July 15, 2016 3:25
To: Jan Lindblad
Cc: Xiang Li; Sterne, Jason (Nokia - CA); Netconf
Subject: Re: [Netconf] What should a server response be?

Hi,

Even in the YANG 1.1 spec, it says MAY delete but does not say MAY create anywhere.
YANG does not say NP containers cannot be created or deleted
by the client.

Andy

On Thu, Jul 14, 2016 at 11:46 PM, Jan Lindblad <[email-masked]<mailto:[email-masked]>> wrote:
In order to reach rough consensus on the interpretation of the default-operation=none sequence, I think we need to start with coming to a common understanding of what NP containers are. Can NP containers be "created" and "deleted" just like P containers?

list t {
    key a;
    leaf a { type uint32; }
    container np {
        must "../a > 10";
    }
    container p {
        presence "...";
        must "../a > 20";
    }
}

/jan

   created and deleted.

            to be deleted.

/jan

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 15 Jul 2016 07:19:55 -0700

On Fri, Jul 15, 2016 at 4:32 AM, Sterne, Jason (Nokia - CA) <
[email-masked]> wrote:

> When we say “NP containers can be created/deleted” I generally interpret
> that to mean that it is valid to have an operation=’delete’ (or create or
> remove or merge) on an NP container node in an <edit-config> request
> (either directly or inherited).
>
>
>
> I don’t think there should be any real meaning to the existence/presence
> (or not) of NP containers in a datastore.   But it does seem this isn’t
> very clearly laid out in the RFCs.
>
>
>

The NETCONF RFC does not make any special conditions for creating or
deleting data.

IMO this is not even a problem because NETCONF has 2 sets of edit
operations.

If the client is 100% aware of the server behavior (defaults, deviations,
features, etc.)
it can use  create and delete, which are picky and will be rejected unless
the operation really is create or delete..

NETCONF also has merge and remove which are not picky.
These operations ALWAYS work even if the server has
deleted nodes, or defaults or whatever. So just use merge and remove
instead of create and delete.

Jason

Andy

> *Sent:* Friday, July 15, 2016 3:25
> *To:* Jan Lindblad
> *Cc:* Xiang Li; Sterne, Jason (Nokia - CA); Netconf

---

From: Xiang Li <[email-masked]>
Date: Fri, 15 Jul 2016 13:11:18 -0500

On 7/15/2016 1:46 AM, Jan Lindblad wrote:
> default-operation=none sequence, I think we need to start with coming 
> to a common understanding of what NP containers are. Can NP containers 
> be "created" and "deleted" just like P containers?
>

Yes I agree

> An NP container is simply a structural element, and does not need to 
> be "created" to exist,

I understand the "does not need to be 'created' to exist" part. The 
confusion arises about what is a compliant
implementation when a client does want to create it explicitly for 
whatever reason. Using your example
(a very good example, by the way)

e) create with a = 15,  and also create np  explicitly

and then follows up with an additional edit-config
f)  merge with a = 15, and create np explicitly again

should a compliant server reject f) or not?

> but empty NP containers MAY not be reported since they are meaningless 
> anyway.
>
I agree

> If must statements in np containers are in effect even if the client 
> isn't explicitly "creating" or mentioning the container, then I find 
> it hard to understand the viewpoint that "creation" of NP containers 
> makes any difference.
>

It doesn't. What I am trying to figure out is  how a compliant server 
implementation
  should handle  the "operation"  on a NP container node in a 
<edit-config>.

-Xiang

> /jan
>
>>>         I guess I don’t really see NP-containers as “config”. They
>>>         are just structure and filtered out when empty.  I don’t
>>>         really see this as the server “deleting” those containers. 
>>>         It just suppresses them in <get-config> output.
>>>
>>     In a very technical sense, I suppose the above statement is
>>     correct. An NP container is of course config true if it sits in
>>     the config true part of the tree. At the same time I agree with
>>     Janson's view that NP containers are just structure, so the
>>     question of their "existence" is moot.
>>
>>     So NP containers "exist only for organizing the hierarchy" while
>>     a P container "has an explicit meaning". I guess this implies NP
>>     containers having no meaning. Further down in 7.5.1, re P
>>     containers, it is noted that:
>>
>>     Based on these fragments, I conclude that NP containers have zero
>>     bits of information. This means the existence/absence of an NP
>>     container cannot be known/stored/remembered even internally by a
>>     conforming system. The existence/absence of an NP container is a
>>     moot question. It's a bit like asking for the value of a void
>>     function. It's there, it has a name, but no value.
>>
>>     contains an NP container will have to decide whether to include
>>     the NP container in the response or not. Since the existence of
>>     the NP container cannot be read from a database/etc (it has zero
>>     bits of information), the implementation will have to use some
>>     other way to determine whether to include it or not.
>>
>>     So the NP container has to be included if it has children, or
>>     else the structural function of the container would be lost. If
>>     the NP container is empty, it may or may not be sent. Since an NP
>>     container has zero bits of information, this decision would not
>>     be based on whether it has been previously "created" or
>>     "deleted", but on implementation considerations. One possible
>>     approach is to always include it, another to actually check if
>>     Certainly. Must statements on an NP container are always
>>     evaluated, even if the container hasn't been "created" or
>>     mentioned by a client, and even if it has no child elements.
>>
>>>         The server should not error in the cases Mahesh & Einar show
>>>         -> the presence/existence of NP-containers shouldn’t really
>>>         affect behavior (since they aren’t really config).
>>>
>>     I agree with the above.
>>>
>>>         But I’m not positive what you mean by “manager needs to
>>>         guard”. Do you agree that the server should not error in
>>>         those cases below ?
>>>
>>     I disagree with this conclusion. Even using
>>     default-operation=none the transactions must be guaranteed to
>>     work by a conforming implementation. NP containers cannot be
>>     created/deleted in a deeper sense of the word since they have
>>     zero information content. They can only be referred to. Any must
>>     statements within the container must be evaluated regardless of
>>     the client ever mentioning the container.
>>
>>
>>

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 15 Jul 2016 18:37:36 +0000

(f) should be accepted without an error IMO.   The presence/existence (or not) of an NP-container should not affect the behavior.   Maybe that isn’t spelled out in the RFCs but I have my doubts many implementations would reject (f).

From: Xiang Li [mailto:[email-masked]]
Sent: Friday, July 15, 2016 14:11
To: Jan Lindblad; Andy Bierman; Sterne, Jason (Nokia - CA)
Cc: Netconf
Subject: Re: [Netconf] What should a server response be?

list t {
    key a;
    leaf a { type uint32; }
    container np {
        must "../a > 10";
    }
    container p {
        presence "...";
        must "../a > 20";
    }
}

My own answer is that only operation c is allowed. "creation" of an NP container is irrelevant, while creation of a P container makes a difference.

Yes I agree

An NP container is simply a structural element, and does not need to be "created" to exist,

I understand the "does not need to be 'created' to exist" part. The confusion arises about what is a compliant
implementation when a client does want to create it explicitly for whatever reason. Using your example
(a very good example, by the way)

but empty NP containers MAY not be reported since they are meaningless anyway.

I agree

It doesn't. What I am trying to figure out is  how a compliant server implementation
 should handle  the "operation"  on a NP container node in a <edit-config>.

-Xiang

/jan

   created and deleted.

            to be deleted.

/jan

Andy

---

From: Xiang Li <[email-masked]>
Date: Fri, 15 Jul 2016 14:19:30 -0500

On 7/15/2016 1:37 PM, Sterne, Jason (Nokia - CA) wrote:
>
> (f) should be accepted without an error IMO.
>

Ok. If f) is accepted then it indicates the server chooses to delete an 
empty container
or it basically ignore the operation to create only a NP container node.

RFC6020 only says "MAY delete",

What if a server faithfully creates the NP structure node in e), then f) 
will be
rejected since the container node has already "existed" and can't
be "created" again.

> The presence/existence (or not) of an NP-container should not affect 
> the behavior.
>

Semantically I believe that is true.

> Maybe that isn’t spelled out in the RFCs but I have my doubts many 
> implementations would reject (f).
>

I think RFC6020bis should clarify the expected behavior when a client 
attempts to
create empty NP container without child nodes for whatever reason 
(unless this
is not allowed).

same thing when a client attempts to delete twice a container node.

I think the lengthy discussion warrants this to be spelled out, one way 
or another.

-Xiang

> *From:*Xiang Li [mailto:[email-masked]]
> *Sent:* Friday, July 15, 2016 14:11
> *To:* Jan Lindblad; Andy Bierman; Sterne, Jason (Nokia - CA)
> *Cc:* Netconf
>     default-operation=none sequence, I think we need to start with
>     coming to a common understanding of what NP containers are. Can NP
>     containers be "created" and "deleted" just like P containers?
>
>     My own answer is that only operation c is allowed. "creation" of
>     an NP container is irrelevant, while creation of a P container
>     makes a difference.
>
>
> Yes I agree
>
>
>
>                 I guess I don’t really see NP-containers as “config”.
>                 They are just structure and filtered out when empty. 
>                 I don’t really see this as the server “deleting” those
>                 containers.  It just suppresses them in <get-config>
>                 output.
>
>         correct. An NP container is of course config true if it sits
>         in the config true part of the tree. At the same time I agree
>         with Janson's view that NP containers are just structure, so
>         the question of their "existence" is moot.
>
>         So NP containers "exist only for organizing the hierarchy"
>         while a P container "has an explicit meaning". I guess this
>         implies NP containers having no meaning. Further down in
>         7.5.1, re P containers, it is noted that:
>
>         Based on these fragments, I conclude that NP containers have
>         zero bits of information. This means the existence/absence of
>         an NP container cannot be known/stored/remembered even
>         internally by a conforming system. The existence/absence of an
>         NP container is a moot question. It's a bit like asking for
>         the value of a void function. It's there, it has a name, but
>         no value.
>
>         Implementations that receive a <get> or <get-config> request
>         that contains an NP container will have to decide whether to
>         include the NP container in the response or not. Since the
>         existence of the NP container cannot be read from a
>         database/etc (it has zero bits of information), the
>         implementation will have to use some other way to determine
>         whether to include it or not.
>
>         In order to make the life easier for implementors, the
>         following MAY was introduced in sec 7.5.7:
>
>         else the structural function of the container would be lost.
>         If the NP container is empty, it may or may not be sent. Since
>         an NP container has zero bits of information, this decision
>         would not be based on whether it has been previously "created"
>         or "deleted", but on implementation considerations. One
>         possible approach is to always include it, another to actually
>         check if there are any children, and only return it then.
>
>         I think the length of this discussion implies we should
>         include this topic in the upcoming YANG FAQ.
>
>                 The server should not error in the cases Mahesh &
>                 Einar show -> the presence/existence of NP-containers
>                 shouldn’t really affect behavior (since they aren’t
>                 really config).
>
>         I agree with the above.
>
>         zero information content. They can only be referred to. Any
>         must statements within the container must be evaluated
>         regardless of the client ever mentioning the container.
>

---

From: Jan Lindblad <[email-masked]>
Date: Sat, 16 Jul 2016 09:31:38 +0200

> Ok. If f) is accepted then it indicates the server chooses to delete an empty container

I agree with this.

I also agree that RFC 6020 could spell this out in a more direct way. Currently the description of NP and P containers does not contain a table with the properties of each, but instead enumerates how P containers differ from NP containers in plain english. In order to build a such a table, I've collected quotes on each type here:

P-container qoutes:
- "presence in the configuration has an explicit meaning"
- "presence of the container itself is configuration data"
- "representing a single bit of configuration data"
- "These containers are explicitly created and deleted"
- "The "presence" statement assigns a meaning to the presence of a container in the data tree"

NP-container qoutes:
- "exist only for organizing the hierarchy of data nodes"
- "container has no meaning of its own, existing only to contain child nodes"
- "the container is used to give some structure to the data, and it carries no meaning by itself"
- "MAY choose not to send a container element if the container node does not have the "presence" statement and no child nodes exist"
- "a client ... must be prepared to handle the case that a container node without a "presence" statement is not present"

Based on the above quotes, I believe this to be a fair description of the P and NP container differences in a tabular form:

                                  | P-container | NP-container |
----------------------------------+-------------+--------------+
Organizing the hierarchy          |      Y      |       Y      |
May have child nodes              |      Y      |       Y      |
Existence has meaning             |      Y      |       N      |
Is configuration data             |      Y      |       N      |
Information content               |    1 bit    |    0 bits    |
Explicitly created and deleted    |      Y      |       N      |
Suppress when empty               |      N      |      MAY     |
----------------------------------+-------------+--------------+

With this background, I consider it clear that "creation" and "deletion" of P-containers has no effect on the configuration. In fact, a conforming implementation cannot even remember/know if a P-container has been created or not since it has zero bits of information. P-containers aren't really configuration data, even if they may be located in the config true part of the world.

If anyone sees anything wrong, unfounded or unclear with the table above, I think it would be of high general interest that this is pointed out asap.

/jan

---

From: Jan Lindblad <[email-masked]>
Date: Sat, 16 Jul 2016 12:03:24 +0200

Typo, corrected below:

> In fact, a conforming implementation cannot even remember/know if a P-container has been created or not since it has zero bits of information.

In fact, a conforming implementation cannot even remember/know if an NP-container has been created or not since it has zero bits of information.

/jan

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 Jul 2016 14:59:15 +0200

+ 1 or more like +++1000  I always fought against them.

The added value NP containers have compared to P containers is
very low.

The added complication is very high. A whole new concept of
existing/disappearing data node is introduced, with many special
rules, some of which are still not clear.

Balazs

On 2016-07-15 09:24, Andy Bierman
wrote:

Hi,

I don't know what problem is being solved by having them at
all.

Even in the YANG 1.1 spec, it says MAY delete but does not
say MAY create anywhere.

YANG does not say NP containers cannot be created or
deleted

by the client.

Andy

On Thu, Jul 14, 2016 at 11:46 PM, Jan
Lindblad <[email-masked]>
wrote:

In order to reach rough
consensus on the interpretation of the
default-operation=none sequence, I think we need to start
with coming to a common understanding of what NP
containers are. Can NP containers be "created" and
"deleted" just like P containers?

Here's a test to see if there is any difference
between the behavior of p and np containers:

list t {

key a;

leaf a { type uint32; }

container np {

must "../a > 10";

}

container p {

presence "...";

must "../a > 20";

}

}

The config is initially empty. Now, would it be
possible to

a) create an instance with a = 5 if there is no
mention of np and p in the edit-config?

b) create an instance with a = 5 if np (but not p) is
"created" in the edit-config?

c) create an instance with a = 15 if there is no
mention of np and p in the edit-config?

d) create an instance with a = 15 if p is created in
the edit-config?

My own answer is that only operation c is allowed.
"creation" of an NP container is irrelevant, while
creation of a P container makes a difference. An NP
container is simply a structural element, and does not
need to be "created" to exist, but empty NP containers
MAY not be reported since they are meaningless anyway.

If must statements in np containers are in effect
even if the client isn't explicitly "creating" or
mentioning the container, then I find it hard to
understand the viewpoint that "creation" of NP
containers makes any difference.

/jan

I
guess I don’t really
see NP-containers as
“config”.  They are
just structure and
filtered out when
empty.  I don’t really
see this as the server
“deleting” those
containers.  It just
suppresses them in
<get-config>
output.

Please show me the RFC text
that says the server can
filter out NP containers.

All config=true data nodes
are config.

In a very technical sense, I
suppose the above statement is
correct. An NP container is of course
config true if it sits in the config
true part of the tree. At the same
time I agree with Janson's view that
NP containers are just structure, so
the question of their "existence" is
moot.

Here's what RFC 6020, sec 7.5 says
on the topic:

So NP containers "exist only for
organizing the hierarchy" while a P
container "has an explicit meaning". I
guess this implies NP containers
having no meaning. Further down in
7.5.1, re P containers, it is noted
that:

Based on these fragments, I
conclude that NP containers have zero
bits of information. This means the
existence/absence of an NP container
cannot be known/stored/remembered even
internally by a conforming system. The
existence/absence of an NP container
is a moot question. It's a bit like
asking for the value of a void
function. It's there, it has a name,
but no value.

Implementations that receive a
<get> or <get-config>
request that contains an NP container
will have to decide whether to include
the NP container in the response or
not. Since the existence of the NP
container cannot be read from a
database/etc (it has zero bits of
information), the implementation will
have to use some other way to
determine whether to include it or
not.

In order to make the life easier
for implementors, the following MAY
was introduced in sec 7.5.7:

So the NP container has to be
included if it has children, or else
the structural function of the
container would be lost. If the NP
container is empty, it may or may not
be sent. Since an NP container has
zero bits of information, this
decision would not be based on whether
it has been previously "created" or
"deleted", but on implementation
considerations. One possible approach
is to always include it, another to
actually check if there are any
children, and only return it then.

Either way, NP containers alone
have no meaning/information, they are
only there for structure.

A false must-stmt in an
NP-container is still an
error.

Certainly. Must statements on an NP
container are always evaluated, even
if the container hasn't been "created"
or mentioned by a client, and even if
it has no child elements.

As Lada has pointed out
many times, the text about

NP containers not being
part of the data model is just
wrong.

I think the length of this
discussion implies we should include
this topic in the upcoming YANG FAQ.

The
server should not
error in the cases
Mahesh & Einar
show -> the
presence/existence of
NP-containers
shouldn’t really
affect behavior (since
they aren’t really
config).

I agree with the above.

But
I’m not positive what
you mean by “manager
needs to guard”.  Do
you agree that the
server should not
error in those cases
below ?

The YANG text says a server
MAY delete an empty NP
container.

Using
default-operation=none implies
that the client is sure the
nodes for operation=none

actually exist.  Because of
this YANG detail, the client
cannot be sure so using

default-operation=none may
not work.

I disagree with this conclusion.
Even using default-operation=none the
transactions must be guaranteed to
work by a conforming implementation.
NP containers cannot be
created/deleted in a deeper sense of
the word since they have zero
information content. They can only be
referred to. Any must statements
within the container must be evaluated
regardless of the client ever
mentioning the container.

I do not agree that
default-operation=none does not apply to NP
containers.

This is why it was such a bad decision to
spread little pieces of NETCONF

all over the YANG RFC. RFC 6241 defines
the 'default-operation' leaf

and it does not say anything about
special treatment for NP containers.

/jan

Andy

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 Jul 2016 15:12:36 +0200

Hello Jan,

As I don't see a way to kill NP containers (my first wish) I
agree they should be clarified.  Currently the RFC says:

"If a container does not have a "presence" statement and the last

child node is deleted, the NETCONF server MAY delete the
container."

This allows deleting only when the last child node is deleted. It
does not allow deleting an NP container after an explicit create.

Your table does not directly answer some key questions for me:

Q1) Is it allowed to create it explicitly? Yes/No?

Q2) Is it allowed to create it, then create it again? For a P
container this would result in a create-failed. For NP, allowed or
no?

Q3) If it is allowed to create them, will they exist and continue
to exist in the database, or can the server delete them any time?

Q4) Does the NP container modify the behavior of edit-config none?
Should we fail or succeed in the provided examples? Yes/No?

Q5) When are must statements that are direct substatements of an
NP container validated? Following your logic IMHO such must
statements MUST NOT be allowed in YANG at all.  If an NP container
has no meaning why do we connect checks to them?

I propose to write an errata about this immediately after the
YANG 1.1 RFC comes out.

regards Balazs

On 2016-07-16 09:31, Jan Lindblad
wrote:

(f) should be accepted without an error
IMO.

Ok. If f) is accepted then it
indicates the server chooses to delete an empty container

or it basically ignore the operation
to create only a NP container node.

I agree with this.

I also agree that RFC 6020 could spell this out in a more
direct way. Currently the description of NP and P containers
does not contain a table with the properties of each, but
instead enumerates how P containers differ from NP containers
in plain english. In order to build a such a table, I've
collected quotes on each type here:

P-container qoutes:

- "The "presence" statement assigns a meaning to the
presence of a container in the data tree"

NP-container qoutes:

- "container has no meaning of its own, existing
only to contain child nodes"

- "the container is used to give some structure to the
data, and it carries no meaning by itself"

- "MAY choose not to send a container element if the
container node does not have the "presence" statement and no
child nodes exist"

- "a client ... must be prepared to handle the case that a
container node without a "presence" statement is not present"

Based on the above quotes, I believe this to be a fair
description of the P and NP container differences in a tabular
form:

Organizing the hierarchy
|      Y      |       Y      |

May have child nodes
|      Y      |       Y      |

Existence has meaning
|      Y      |       N      |

Is
configuration data             |      Y      |       N
|

Information content
|    1 bit    |    0 bits    |

Explicitly created and
deleted    |      Y      |       N      |

Suppress when empty
|      N      |      MAY     |

With this background, I consider it clear that "creation"
and "deletion" of P-containers has no effect on the
configuration. In fact, a conforming implementation cannot
even remember/know if a P-container has been created or not
since it has zero bits of information. P-containers aren't
really configuration data, even if they may be located in the
config true part of the world.

If anyone sees anything wrong, unfounded or unclear with
the table above, I think it would be of high general interest
that this is pointed out asap.

/jan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jul 2016 15:48:35 +0200

On Tue, Jul 19, 2016 at 03:12:36PM +0200, Balazs Lengyel wrote:
>    Hello Jan,
> 
>    As I don't see a way to kill NP containers (my first wish) I agree they
>    should be clarified.  Currently the RFC says:
> 
>       child node is deleted, the NETCONF server MAY delete the container."
>

Having to track whether a container was created to be empty or whether
it just became empty seems like additional complexity for no real
value. I think the text should likely have said:

   "If a container does not have a "presence" statement and the container
    has no child nodes, the NETCONF server MAY delete the container."

The whole problem can be easily prevented by having clients sending
edit-configs that do not rely on a server maintaining empty containers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Jul 2016 00:36:53 +0200

> edit-configs that do not rely on a server maintaining empty containers.
+1.

But I also agree with Balazs that YANG "must" statements on a np 
container are a bit horrible - intuitively I think that I would prefer 
that they are only bound to schema nodes that can actually contain 
information.  But that ship has already sailed ...

Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jul 2016 16:55:23 -0700

On Tue, Jul 19, 2016 at 3:36 PM, Robert Wilton <[email-masked]> wrote:

> But I also agree with Balazs that YANG "must" statements on a np container
> are a bit horrible - intuitively I think that I would prefer that they are
> only bound to schema nodes that can actually contain information.  But that
> ship has already sailed ...
>
>
I find the new YANG 1.1 additions to NETCONF mostly horrible,
but this is one of the worst. This is not a backward-compatible change
from YANG 1.0 where must-stmt is only run if the container exists.
Our YANG 1.0 compliant code does not run the must-test unless the
context node (NP container) exists.

We also NEVER magically delete anything from the client.
This would be really bad in the candidate designed to support
incremental edits.

I am strongly opposed to this change in NETCONF datastore behavior
defined in the YANG language. It is not intuitive that the must-stmts
in NP containers are always checked (unless of course any
ancestor-or-self nodes contain a false when-stmt or if-feature)

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 20 Jul 2016 05:48:44 +0200

Based on the responses, here is what I can seem to summarize.

1). The current text around NP containers is not helpful. Balasz, do you want to write the errata? I like Juergen’s suggestion

  "If a container does not have a "presence" statement and the container
   has no child nodes, the NETCONF server MAY delete the container.”

2) Add Jan’s table with clarifications that Balazs has requested on the YANG wiki.

3) Add a guidance on the wiki that client should not send requests that rely on a server maintaining empty containers.

> On Jul 20, 2016, at 1:55 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Tue, Jul 19, 2016 at 3:36 PM, Robert Wilton <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> But I also agree with Balazs that YANG "must" statements on a np container are a bit horrible - intuitively I think that I would prefer that they are only bound to schema nodes that can actually contain information.  But that ship has already sailed ...
> 
> 
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
> 
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh Jethanandani
[email-masked]

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 20 Jul 2016 06:09:32 +0200

Balazs,
> The added value NP containers have compared to P containers is very low.
> The added complication is very high. A whole new concept of existing/disappearing data node is introduced, with many special rules, some of which are still not clear.
> 
Aren't you exaggerating a little? NP containers are essential for making YANG models that resemble the existing CLI structures. Look at all the models already in RFC and at all the drafts. I had a look in the IETF DRAFTS folder, and around 20% of the objects defined were NP containers. Far less than 1% were P containers. It seems then that modelers find NP containers more useful than you do.

NP containers are actually really simple, trivial even, but of course it's always complicated to implement something that isn't fully understood.
> As I don't see a way to kill NP containers (my first wish) I agree they should be clarified.  Currently the RFC says:
> This allows deleting only when the last child node is deleted. It does not allow deleting an NP container after an explicit create.
> 
For some reason you're hung up about the "creation" and "deletion" of NP containers. I maintain that NP containers can't really be created and deleted in a deeper sense of the word. They have zero bits of information, so a conforming implementation cannot remember their history, and they have no value. There are no moving parts here.

If it makes it easier, think of NP containers as a prefix to the name of all the objects inside the container.
> Q1) Is it allowed to create it explicitly? Yes/No?
NP containers cannot be created, not in the sense that you can ask about their created/not-created state later, anyway. They are mentioned in edit-config operations, since there is no way to refer to objects inside the containers without mentioning the container name. The NP container itself isn't an object that has an existence property in itself, so asking whether it can be created is moot.
> Q2) Is it allowed to create it, then create it again? For a P container this would result in a create-failed. For NP, allowed or no?
> 
You can include an NP container in an edit-config create call as many times as you like. "Creation" of an NP container can never result in create-failed. NP containers have zero bits of information, so we have no memory of whether it has been previously created or not. It's completely uninteresting.
> Q3) If it is allowed to create them, will they exist and continue to exist in the database, or can the server delete them any time?
> 
They do not exist in the database, other than as path prefixes to the objects inside the container. Whether empty NP containers are returned in a get-config operation is an implementation decision, and has nothing to do with previous "create" or "delete" calls.
> Q4) Does the NP container modify the behavior of edit-config none? Should we fail or succeed in the provided examples? Yes/No?
> 
There were a number of examples provided. Some should fail, some succeed. In the recent examples named by letters a-f, I think it was only example c and f that should succeed. Refer back to that thread for details. If you had some other example in mind, please be specific.
> Q5) When are must statements that are direct substatements of an NP container validated? Following your logic IMHO such must statements MUST NOT be allowed in YANG at all.  If an NP container has no meaning why do we connect checks to them?
> 
The must statement(s) in an NP container must be validated for each parent node that the container exists in, e.g. for each list instance if the NP container sits in a list. The same applies for P containers, once they are created.
> I propose to write an errata about this immediately after the YANG 1.1 RFC comes out.
> 
What do you propose to say in the errata?

/jan

> Mobile: +36-70-330-7909              email: [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jul 2016 23:27:45 -0700

On Tue, Jul 19, 2016 at 8:48 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> 1). The current text around NP containers is not helpful. Balasz, do you
> want to write the errata? I like Juergen’s suggestion
>

I object to expanding the text as specified.
IMO this behavior favors 1 implementation choice over another.

Andy

>
> 3) Add a guidance on the wiki that client should not send requests that
> rely on a server maintaining empty containers.
>
>> container are a bit horrible - intuitively I think that I would prefer that
>> they are only bound to schema nodes that can actually contain information.
>> But that ship has already sailed ...
>>
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Jul 2016 08:30:54 +0200

> IMO this behavior favors 1 implementation choice over another.

Why?

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jul 2016 23:50:36 -0700

> > IMO this behavior favors 1 implementation choice over another.

because implementation is non-trivial regardless what tail-f says.
One can also decide to remove the text about MAY delete
an NP container after the last child is deleted.

The text about default-operation=none is in RFC 6241 not this draft.
That document does not say anything about ignoring the error conditions
for "none".

Also, the text only affects the NETCONF <edit-config> operation.
So you want this change? Fine.  It does not apply to RESTCONF
or NETCONF <copy-config>.

I also strongly object to significant design changes being made
as errata.  Pull the document back into the WG to make these changes.

Andy

---

From: Jan Lindblad <[email-masked]>
Date: Wed, 20 Jul 2016 12:37:50 +0200

Andy,

> context node (NP container) exists.

I'm not referring to anything new at all. All the quotes I collected on how NP and P containers work were actually from RFC6020/YANG 1.0.

> This would be really bad in the candidate designed to support

Magically deleting stuff would indeed increase the complexity on both sides, even if this could be tolerable if well described and had good reasons. I don't think this pertains to NP containers, though. Here we're talking about a rock with no moving parts. Zero bits of information. NP containers cannot be created and deleted in the traditional sense of the word. Whether they are reported does not depend on whether they were part of a previous "create" or "delete".

It would of course be best if you could describe how you interpret proper NP container behavior yourself, perhaps based on a table similar to what I presented? To me it appears that you want NP and P containers to behave the same way. Is that correct? If so, what language is this view founded on? I haven't seen any comments from you on the table I put together. Is it correct, or are there things to debate about it?

> ancestor-or-self nodes contain a false when-stmt or if-feature)

I don't think this is a change, and I find it highly intuitive that must statements in NP containers are checked if the parent node exists.

I think of NP containers as path prefixes of the objects inside, and with that I see a coherent picture.

> an NP container after the last child is deleted.

From an implementation perspective I don't think it's a big deal to go from one to the other. It would be trivial to change the implementation to always report the empty NP containers, but I really don't see the value with this. The server would get a little chattier, what's the point?

Of course it's a little annoying to change the specs in a non-backwards compatible way. We would need strong reasons to do that.

In the end, what matters is not the server implementations. Regardless what you say, they can be changed. The important thing is what makes sense for users, i.e. for modelers and at runtime/on the wire.

> That document does not say anything about ignoring the error conditions

I think it's our differing views of what an NP container "is" that is at the root of this. With the view that NP containers are path prefixes, this becomes a non-issue.

> or NETCONF <copy-config>.

If you could describe how NP and P containers differ, I think everything else would fall out after that.

> as errata.  Pull the document back into the WG to make these changes.

I agree significant design changes shouldn't be made as errata. I don't see any design changes in this case, though. Since we've had this pretty long conversation, clarifying the text one way or another is probably a good idea. I don't oppose opening up the document to do so.

/jan

---

From: "Xiang Li" <[email-masked]>
Date: Wed, 20 Jul 2016 10:17:48 -0500

Hi Jan,

Are you saying that since a NP-container is merely a structure node, not
config in any way, so creating/deleting it explicitly (and repeatedly) is
equivalent to a "no-op" that will always succeed because doing so has no
effect on the server's config in any way? 

If the sever has the following example config:

<mycontainer>

     <child  ... bla..bla.configs>

</mycontainer>

If a client issues an edit-config with:

< mycontainer operation="delete">

The server returns "ok",

If then again  the client attempts:

< mycontainer operation="delete">

The server should still return  "ok"?

If so I think this is confusing. I think it would make more sense in the
latter case if the server returns ""data-missing" error.

I understand we may advise a client not do so, but since  RFC6020bis does
not forbid this, and it is also a perfectly valid <edit-config>, so I am
sure people will try it.

 
-Xiang

 

From: Jan Lindblad [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2016 11:10 PM
To: Balazs Lengyel <[email-masked]>
Cc: Xiang Li <[email-masked]>; Netconf <[email-masked]>
Subject: Re: [Netconf] What should a server response be?

Balazs,

The added value NP containers have compared to P containers is very low. 
The added complication is very high. A whole new concept of
existing/disappearing data node is introduced, with many special rules, some
of which are still not clear.

Aren't you exaggerating a little? NP containers are essential for making
YANG models that resemble the existing CLI structures. Look at all the
models already in RFC and at all the drafts. I had a look in the IETF DRAFTS
folder, and around 20% of the objects defined were NP containers. Far less
than 1% were P containers. It seems then that modelers find NP containers
more useful than you do.

NP containers are actually really simple, trivial even, but of course it's
always complicated to implement something that isn't fully understood.

This allows deleting only when the last child node is deleted. It does not
allow deleting an NP container after an explicit create.

For some reason you're hung up about the "creation" and "deletion" of NP
containers. I maintain that NP containers can't really be created and
deleted in a deeper sense of the word. They have zero bits of information,
so a conforming implementation cannot remember their history, and they have
no value. There are no moving parts here.

If it makes it easier, think of NP containers as a prefix to the name of all
the objects inside the container.

NP containers cannot be created, not in the sense that you can ask about
their created/not-created state later, anyway. They are mentioned in
edit-config operations, since there is no way to refer to objects inside the
containers without mentioning the container name. The NP container itself
isn't an object that has an existence property in itself, so asking whether
it can be created is moot.

Q2) Is it allowed to create it, then create it again? For a P container this
would result in a create-failed. For NP, allowed or no?

You can include an NP container in an edit-config create call as many times
as you like. "Creation" of an NP container can never result in
create-failed. NP containers have zero bits of information, so we have no
memory of whether it has been previously created or not. It's completely
uninteresting.

Q3) If it is allowed to create them, will they exist and continue to exist
in the database, or can the server delete them any time?

They do not exist in the database, other than as path prefixes to the
objects inside the container. Whether empty NP containers are returned in a
get-config operation is an implementation decision, and has nothing to do
with previous "create" or "delete" calls.

Q4) Does the NP container modify the behavior of edit-config none? Should we
fail or succeed in the provided examples? Yes/No?

There were a number of examples provided. Some should fail, some succeed. In
the recent examples named by letters a-f, I think it was only example c and
f that should succeed. Refer back to that thread for details. If you had
some other example in mind, please be specific.

Q5) When are must statements that are direct substatements of an NP
container validated? Following your logic IMHO such must statements MUST NOT
be allowed in YANG at all.  If an NP container has no meaning why do we
connect checks to them?

The must statement(s) in an NP container must be validated for each parent
node that the container exists in, e.g. for each list instance if the NP
container sits in a list. The same applies for P containers, once they are
created.

I propose to write an errata about this immediately after the YANG 1.1 RFC
comes out.

/jan

I agree with this.

I also agree that RFC 6020 could spell this out in a more direct way.
Currently the description of NP and P containers does not contain a table
with the properties of each, but instead enumerates how P containers differ
from NP containers in plain english. In order to build a such a table, I've
collected quotes on each type here:

P-container qoutes:

- "The "presence" statement assigns a meaning to the presence of a container
in the data tree"

NP-container qoutes:

- "container has no meaning of its own, existing only to contain child
nodes"

- "the container is used to give some structure to the data, and it carries
no meaning by itself"

- "MAY choose not to send a container element if the container node does not
have the "presence" statement and no child nodes exist"

- "a client ... must be prepared to handle the case that a container node
without a "presence" statement is not present"

Based on the above quotes, I believe this to be a fair description of the P
and NP container differences in a tabular form:

With this background, I consider it clear that "creation" and "deletion" of
P-containers has no effect on the configuration. In fact, a conforming
implementation cannot even remember/know if a P-container has been created
or not since it has zero bits of information. P-containers aren't really
configuration data, even if they may be located in the config true part of
the world.

If anyone sees anything wrong, unfounded or unclear with the table above, I
think it would be of high general interest that this is pointed out asap.

/jan

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]
<mailto:[email-masked]>

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 21 Jul 2016 09:17:39 +0200

Xiang,

> Are you saying that since a NP-container is merely a structure node, not config in any way, so creating/deleting it explicitly (and repeatedly) is equivalent to a “no-op” that will always succeed because doing so has no effect on the server’s config in any way?

That's correct. "Creating" an object with zero bits of information is a no-op.

>      <child  ... bla..bla…configs>
> </mycontainer>
> 
> 
> The server returns “ok”,
> The server should still return  “ok”?

Yes, that's correct in my opinion. It's a consequence of the NP container nature as defined in the current RFC6020/YANG 1.0 and bis.

> If so I think this is confusing. I think it would make more sense in the latter case if the server returns “"data-missing” error.

This is logical if you think of NP containers as path prefixes, and not as objects with information content. If you accept that an NP container has zero bits of information, how would the server even know whether the container exists or not? Not by looking in a database, for sure.

P containers have a single bit of information, so they can be created, and the creation event/existence remembered by the server. Not so for NP-containers.

> I understand we may advise a client not do so, but since  RFC6020bis does not forbid this, and it is also a perfectly valid <edit-config>, so I am sure people will try it.

Yes. And it works today and is harmless.

It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on the subject, but I believe the interpretation I and others have of NP container behavior in RFC 6020 is consistent, implementable and highly useful.

/jan

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Thu, 21 Jul 2016 13:56:39 +0000

I agree with Jan’s interpretation of the expected behavior (and the usefulness of NP containers).  A delete or create on an NP-container node should always succeed (previous operations and current state of the datastore is irrelevant).

The NP-container isn’t actually deleted or created in the datastore IMO but the edit-config should return <ok>.

Subsequent <get-config> or <get> responses may suppress NP-containers if they are empty (I don’t love the term ‘delete’ in  “MAY delete” in the RFC.  It is more of a suppression IMO).

From: Netconf [mailto:[email-masked]] On Behalf Of Jan Lindblad
Sent: Thursday, July 21, 2016 3:18
To: Xiang Li
Cc: Netconf
Subject: Re: [Netconf] What should a server response be?

Xiang,

The server returns “ok”,

/jan

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jul 2016 12:13:14 +0200

Hello,

We seem to have fundamental differences whether NP-containers
exist/don't exist or if this question is even valid.  I hope we
can agree that as NP-containers are meaningless themselves they
MUST NOT influence
Netconf operations or model validation. (Which is a slight
violation of Netconf-6241, which we should accept.)

So I propose the following errata to rfc6020bis.

As for non-presence containers the presence of the container node
with no child nodes is

semantically equivalent to the absence of the container node,
configuration operations or

model validation should never fail due to the existence or
non-existence of a non-presence containers. Specifically:

- an <edit-config>  create operation for a non-presence
container MUST succeed even if the container already exists.

- an <edit-config>  delete operation for a non-presence
container MUST succeed even if the container does not exist.

- an <edit-config>  operation with default-operation=none
MUST succeed even if one or more  non-presence containers do not
exist.

Separately

- a must statement defined as direct substatement of a
non-presence container SHALL be evaluated as part of model
validation if and only if one or more child data nodes exist in
the instance data or if there is a leaf or leaf-list child with a
default value. As non-presence containers are only used for
organizing the hierarchy they SHOULD NOT have any must
substatements.

IMO the above rules remove ambiguity and follow the current
philosophy of  RFC6020bis.

If we have a basic agreement I can formulate the text correctly.

I don't know whether similar updates are needed for RestConf.

regards Balazs

PS. I still believe introducing NP containers was a mistake, however
they are here to stay.

On 2016-07-21 09:17, Jan Lindblad
wrote:

Xiang,

Are
you saying that since a NP-container is merely a
structure node, not config in any way, so
creating/deleting it explicitly (and repeatedly) is
equivalent to a “no-op” that will always succeed
because doing so has no effect on the server’s
config in any way?

That's correct. "Creating" an object with zero bits of
information is a no-op.

If the
sever has the following example config:

<mycontainer>

</mycontainer>

If a
client issues an edit-config with:

The
server returns “ok”,

If then
again  the client attempts:

The
server should still return  “ok”?

Yes, that's correct in my opinion. It's a consequence of
the NP container nature as defined in the current
RFC6020/YANG 1.0 and bis.

If so I
think this is confusing. I think it would make more
sense in the latter case if the server returns “"data-missing” error.

This is logical if you think of NP containers as path
prefixes, and not as objects with information content. If
you accept that an NP container has zero bits of
information, how would the server even know whether the
container exists or not? Not by looking in a database, for
sure.

P containers have a single bit of information, so they
can be created, and the creation event/existence remembered
by the server. Not so for NP-containers.

I
understand we may advise a client not do so, but since
RFC6020bis does not forbid this, and it is also a
perfectly valid <edit-config>, so I am sure
people will try it.

It's unfortunate that the YANG 1.0 and 1.1 specs aren't
crystal clear on the subject, but I believe the
interpretation I and others have of NP container behavior in
RFC 6020 is consistent, implementable and highly useful.

/jan

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 22 Jul 2016 12:15:44 +0200

Hello,

Basic problem is that Netconf (and many people) consider data
existing or not.  At least the create/delete/none operation does
assign a meeting to the existence (or non-existence) of a data node
even if it does not have a meaning from a configuration point of
view. There is no such thing as not so-much-existing, no place for
ambiguity. NP containers violate this principle.

See my other mail about the proposed solution.

regards Balazs

On 2016-07-20 08:50, Andy Bierman
wrote:

On Tue, Jul 19, 2016 at 11:30 PM,
Juergen Schoenwaelder <[email-masked]>
wrote:

On Tue,

> > 2) Add Jan’s table with clarifications that
Balazs has requested on the

> > YANG wiki.

Why?

because implementation is non-trivial regardless what
tail-f says.

The text about default-operation=none is in RFC 6241
not this draft.

That document does not say anything about ignoring the
error conditions

for "none".

Also, the text only affects the NETCONF
<edit-config> operation.

So you want this change? Fine.  It does not apply to
RESTCONF

I also strongly object to significant design changes
being made

as errata.  Pull the document back into the WG to make
these changes.

/js

Andy

--

Juergen Schoenwaelder           Jacobs University
Bremen gGmbH

Phone: +49 421 200 3587         Campus Ring 1 | 28759
Bremen | Germany

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 22 Jul 2016 16:57:07 +0200

> We seem to have fundamental differences whether NP-containers exist/don't exist or if this question is even valid.  I hope we can agree that as NP-containers are meaningless themselves they MUST NOT influence Netconf operations or model validation.
> 
+1
> (Which is a slight violation of Netconf-6241, which we should accept.)
> 
Balasz, could you be more specific please?
> As for non-presence containers the presence of the container node with no child nodes is
> semantically equivalent to the absence of the container node, configuration operations or
> model validation should never fail due to the existence or non-existence of a non-presence containers. Specifically:
> 
> - an <edit-config>  create operation for a non-presence container MUST succeed even if the container already exists.
> - an <edit-config>  delete operation for a non-presence container MUST succeed even if the container does not exist.
> - an <edit-config>  operation with default-operation=none MUST succeed even if one or more  non-presence containers do not exist.
> 
IMO the above is a possible/reasonable clarification that will make life simpler for implementers and users alike. But I do find the language around 'creation' and 'deletion' a little counter productive, since it cements the basic misunderstanding that is causing folks' headache. If we tried to improve the explanation of what NP containers really are (path prefixes with no moving parts), people might find it easier to understand and accept the defined behavior as a natural consequence rather than a set of exceptional rules. See below for an attempt at clarifying the text.
> Separately
> - a must statement defined as direct substatement of a non-presence container SHALL be evaluated as part of model validation if and only if one or more child data nodes exist in the instance data or if there is a leaf or leaf-list child with a default value. As non-presence containers are only used for organizing the hierarchy they SHOULD NOT have any must substatements.
> 
No, no, it's the other way around. Non-presence containers SHALL always be validated, once for every parent node they live in, exactly like P containers that are in the created state. Our own IETF YANG models depend on this fact already, and there are cases that would get really hairy by adding CLRs that must statements cannot/shouldn't live in NP containers. For example, how would you express the following without a must statement on the NP container? (from ietf-zerotouch-bootstrap-server.yang)

      container ownership-voucher {
        description
          "This container contains the Ownership Voucher that the
           device uses to ascertain the identity of its rightful
           owner, as certified by its Vendor.";

        when "../redirect-information/signature or ../bootstrap-information/*/signature";
        must "../owner-certificate";

        uses ownership-voucher-grouping;
      }

Here's another example:

grouping ... {
  container cfm {
    container traceroute-cache {
      must "hold-time or cache-size" { ... }

How would you enforce that at least one of hold-time or cache-size exists without a must statement on an NP container?

So here is an attempt at explaining the NP container behavior by adding a few lines after the presence-container has been specified.

7.5.1.1 Non-presence containers

Containers without any presence statement inside, non-presence containers, are logically treated like presence containers that are hardwired to always exist. Any attempt to create a non-presence container has no effect, and is accepted without returning any error. Deleting a non-presence container deletes all the child nodes of the container, but has otherwise no effect on the container itself. No error is returned if it is already empty. Servers MAY choose to suppress empty non-presence containers in get and get-config operations for brevity.

We may want to include some sort of table comparing/contrasting the two as well.

/jan

---

From: Andy Bierman <[email-masked]>
Date: Fri, 22 Jul 2016 08:15:23 -0700

On Fri, Jul 22, 2016 at 7:57 AM, Jan Lindblad <[email-masked]> wrote:

> We seem to have fundamental differences whether NP-containers exist/don't
> exist or if this question is even valid.  I hope we can agree that as
> NP-containers are meaningless themselves they MUST NOT influence Netconf
> operations or model validation.
>
> +1
>
>
too bad the YANG 1.1 doesn't say anything about this at all.
What it actually says is that a server MAY delete an NP container
after the last child node is deleted by an <edit-config> operation.

YANG 1.1 is not backward compatible with YANG 1.1 wrt/ must-stmt.

module foo {

   container top {
      presence "";
   }

}

module bar {

   augment /foo:top {
      container two {
         must "A > 4";
         leaf A { type int32; }
      }
   }
}

YANG 1.0 there was text about an NP container always being in the schema
tree.
For an "old client" that does not know about module bar, a "create /foo:top"
operation worked fine.  But in YANG 1.1 this is completely broken because
this create will fail because the must-stmt in /foo:top/bar:two will
immediately be false.
So much for this nonsense that NP containers are invisible in the protocol.

The same result occurs if /foo:top is created via NETCONF <copy-config> or
RESTCONF

Andy

> model validation should never fail due to the existence or non-existence
> of a non-presence containers. Specifically:
>
> - an <edit-config>  create operation for a non-presence container MUST
> succeed even if the container already exists.
> - an <edit-config>  delete operation for a non-presence container MUST
> succeed even if the container does not exist.
> - an <edit-config>  operation with default-operation=none MUST succeed
> even if one or more  non-presence containers do not exist.
>
> IMO the above is a possible/reasonable clarification that will make life
> simpler for implementers and users alike. But I do find the language around
> 'creation' and 'deletion' a little counter productive, since it cements the
> basic misunderstanding that is causing folks' headache. If we tried to
> improve the explanation of what NP containers really are (path prefixes
> with no moving parts), people might find it easier to understand and accept
> the defined behavior as a natural consequence rather than a set of
> exceptional rules. See below for an attempt at clarifying the text.
>
> Separately
> - a must statement defined as direct substatement of a non-presence
> container SHALL be evaluated as part of model validation if and only if one
> or more child data nodes exist in the instance data or if there is a leaf
> or leaf-list child with a default value. As non-presence containers are
> only used for organizing the hierarchy they SHOULD NOT have any must
> substatements.
>
> No, no, it's the other way around. Non-presence containers SHALL always be
> validated, once for every parent node they live in, exactly like P
> containers that are in the created state. Our own IETF YANG models depend
> on this fact already, and there are cases that would get really hairy by
> adding CLRs that must statements cannot/shouldn't live in NP containers.
> For example, how would you express the following without a must statement
> on the NP container? (from ietf-zerotouch-bootstrap-server.yang)
>
> How would you enforce that at least one of hold-time or cache-size exists
> without a must statement on an NP container?
>
>
> So here is an attempt at explaining the NP container behavior by adding a
> few lines after the presence-container has been specified.
>
> Containers without any presence statement inside, non-presence containers,
> are logically treated like presence containers that are hardwired to always
> exist. Any attempt to create a non-presence container has no effect, and is
> accepted without returning any error. Deleting a non-presence container
> deletes all the child nodes of the container, but has otherwise no effect
> on the container itself. No error is returned if it is already empty.
> Servers MAY choose to suppress empty non-presence containers in get and
> get-config operations for brevity.
>

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 26 Jul 2016 17:47:30 +0200

Hello.

Based on your input here is my second attempt at the errata text.
I tried to go for the minimum of changes. See detailed comments below!

7.5.8.  NETCONF <edit-config> Operations - changes

- If the operation is "create", the node is created if it does
not  exist.  If the node is

a presence container and it already exists, a "data-exists" error
is returned. If the node is

a non-presence container and it already exists, the operation
succeeds but has no effect.

- If the operation is "delete", the node is deleted if it exists.
If the node is

a presence container and it does not exist, a "data-missing" error
is returned. If the node is

a non-presence container and it does not exist, the operation
succeeds but has no effect.

- if the default-operation is "none" the operation MUST NOT fail
because one or more non-presence containers do not exist.

Balazs

On 2016-07-22 16:57, Jan Lindblad
wrote:

As for non-presence containers the presence
of the container node with no child nodes is

semantically equivalent to the absence of the
container node, configuration operations or

model validation should never fail due to the
existence or non-existence of a non-presence
containers. Specifically:

- an <edit-config>  create operation
for a non-presence container MUST succeed even if the
container already exists.

- an <edit-config>  delete operation for a
non-presence container MUST succeed even if the
container does not exist.

- an <edit-config>  operation with
default-operation=none MUST succeed even if one or
more  non-presence containers do not exist.

IMO the above is a possible/reasonable clarification that
will make life simpler for implementers and users alike. But
I do find the language around 'creation' and 'deletion' a
little counter productive, since it cements the basic
misunderstanding that is causing folks' headache. If we
tried to improve the explanation of what NP containers
really are (path prefixes with no moving parts), people
might find it easier to understand and accept the defined
behavior as a natural consequence rather than a set of
exceptional rules. See below for an attempt at clarifying
the text.

BALAZS: The point is we do not agree on
this. According to

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-3
a container is a data node.

"container: An interior data node that exists ..."  That
clearly states that a container _exists_.

We never defined the concept of a "path prefix" or this
not-really-existing-data-node. . IMHO that is a Tailf concept
not a rfc6020 concept.

https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.5.1
states:

"YANG supports two styles of containers, those that exist
only for organizing the hierarchy of data nodes, ..."

So speaking about existence of containers is clearly
in-line with the RFC6020

Separately

- a must statement defined as direct substatement of a
non-presence container SHALL be evaluated as part of
model validation if and only if one or more child data
nodes exist in the instance data or if there is a leaf
or leaf-list child with a default value. As
non-presence containers are only used for organizing
the hierarchy they SHOULD NOT have any must
substatements.

No, no, it's the other way around. Non-presence
containers SHALL always be validated, once for every parent
node they live in, exactly like P containers that are in the
created state. Our own IETF YANG models depend on this fact
already, and there are cases that would get really hairy by
adding CLRs that must statements cannot/shouldn't live in NP
containers. For example, how would you express the following
without a must statement on the NP container?
(from ietf-zerotouch-bootstrap-server.yang)

BALAZS: OK, I see RFC6020bis already states
this, just you have to look up a number of different chapters to
find this.

description

"This container contains the Ownership Voucher
that the

device uses to ascertain the identity of its
rightful

when "../redirect-information/signature or
../bootstrap-information/*/signature";

}

Here's another example:

grouping ... {

container cfm {

How would you enforce that at least one of hold-time or
cache-size exists without a must statement on an NP
container?

So here is an attempt at explaining the NP container
behavior by adding a few lines after the presence-container
has been specified.

Containers without any presence statement inside,
non-presence containers, are logically treated like presence
containers that are hardwired to always exist. Any attempt
to create a non-presence container has no effect, and is
accepted without returning any error. Deleting a
non-presence container deletes all the child nodes of the
container, but has otherwise no effect on the container
itself. No error is returned if it is already empty. Servers
MAY choose to suppress empty non-presence containers in get
and get-config operations for brevity.

BALAZS: The first and second sentence
contradict each other. If the NP-container exists a create
netconf operation should to fail.

We may want to include some sort of table
comparing/contrasting the two as well.

/jan

---

From: Andy Bierman <[email-masked]>
Date: Sat, 30 Jul 2016 11:52:23 -0700

Hi,

I strongly object to changing a vague MAY about deleting an NP container
after the last child has been deleted into several MUST requirements.

I propose this text instead:

OLD:

NEW:

   If a container does not have a "presence" statement and the container
instance
   does not have any child node instances, the NETCONF server MAY delete the
   container. If the server does delete a container instance in this case,
it MUST
   re-create the container instance if a client <edit-config> request
attempts to create
   a child node instance within this container.

Andy

On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <[email-masked]

> operations or model validation. (Which is a slight violation of
> Netconf-6241, which we should accept.)
>
> IMO the above rules remove ambiguity and follow the current philosophy of
> RFC6020bis.
> PS. I still believe introducing NP containers was a mistake, however they
> are here to stay.
>
> On 2016-07-21 09:17, Jan Lindblad wrote:
>
> Xiang,
>
> equivalent to a “no-op” that will always succeed because doing so has no
> effect on the server’s config in any way?
>
>
> Yes, that's correct in my opinion. It's a consequence of the NP container
> nature as defined in the current RFC6020/YANG 1.0 and bis.
>
>
> latter case if the server returns “"data-missing” error.
>
>
> This is logical if you think of NP containers as path prefixes, and not as
> objects with information content. If you accept that an NP container has
> zero bits of information, how would the server even know whether the
> container exists or not? Not by looking in a database, for sure.
>
> P containers have a single bit of information, so they can be created, and
> the creation event/existence remembered by the server. Not so for
> NP-containers.
>
> It's unfortunate that the YANG 1.0 and 1.1 specs aren't crystal clear on
> the subject, but I believe the interpretation I and others have of NP
> container behavior in RFC 6020 is consistent, implementable and highly
> useful.
>
> /jan
>
>
> --

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 30 Jul 2016 17:21:00 -0700

Andy,

The thread started because the RFC does not say anything about a create of a NP container. It only talked about delete. Can we make the (re-)create of the NP container unconditional to whether a delete was performed on it. So a tweak to your proposal would be:

OLD:

NEW:

   If a container does not have a "presence" statement and the container instance
   does not have any child node instances, the NETCONF server MAY delete the
   container. It MUST create the container instance if a client <edit-config> request 
   attempts to create a child node instance within this container.

> On Jul 30, 2016, at 11:52 AM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
>    If a container does not have a "presence" statement and the container instance
>    container. If the server does delete a container instance in this case, it MUST
>    re-create the container instance if a client <edit-config> request attempts to create
> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <[email-masked] <mailto:[email-masked]>> wrote:
> Hello, 
> We seem to have fundamental differences whether NP-containers exist/don't exist or if this question is even valid.  I hope we can agree that as NP-containers are meaningless themselves they MUST NOT influence Netconf operations or model validation. (Which is a slight violation of Netconf-6241, which we should accept.)
> IMO the above rules remove ambiguity and follow the current philosophy of  RFC6020bis. 
> PS. I still believe introducing NP containers was a mistake, however they are here to stay.  
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Sat, 30 Jul 2016 17:31:14 -0700

On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani <
[email-masked]> wrote:

> Andy,
>
> The thread started because the RFC does not say anything about a create of
> a NP container. It only talked about delete. Can we make the (re-)create of
> the NP container unconditional to whether a delete was performed on it. So
> a tweak to your proposal would be:
>
>
The only reason that example did not work is because the server deleted the
NP containers
after the client created them.  If the server does not delete the
containers then
the 2nd RPC will not fail.

This can also be completely avoided by using the default (merge).
Since the client has to explicitly pick default-operation=none,
it better know what it is doing.  This is the same issue as a default leaf
and the create operation.  Nothing special about NP containers.

The <edit-config> for "create" will fail if the leaf already exists
and the "delete" will fail if the value is not there (just a default).
The work-around?  Use merge and remove, not create and delete.
IMO the same logic applies here.

Andy

OLD:
> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <
> [email-masked]> wrote:
>
>> Hello,
>>
>> This is logical if you think of NP containers as path prefixes, and not
>> as objects with information content. If you accept that an NP container has
>> P containers have a single bit of information, so they can be created,
>> and the creation event/existence remembered by the server. Not so for
>> NP-containers.
>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 31 Jul 2016 10:45:49 -0700

> On Jul 30, 2016, at 5:31 PM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
>> On Sat, Jul 30, 2016 at 5:21 PM, Mahesh Jethanandani <[email-masked]> wrote:
>> Andy,
>> 
> The only reason that example did not work is because the server deleted the NP containers
> after the client created them.  If the server does not delete the containers then

I think this argument of whether server should or should not create/delete NP containers is distracting from the main point of when NP containers should exist. In my mind, the NP container existence depends on whether child nodes exist or not. In the end, if child nodes exist, NP containers should exist (created), if they do not exist, the NP container should be removed.

Can we agree on that? 

P.s The errata will be much easier to craft if we can agree on this.

>>>> On Fri, Jul 22, 2016 at 3:13 AM, Balazs Lengyel <[email-masked]> wrote:
>>>> Hello,

---

From: Andy Bierman <[email-masked]>
Date: Sun, 31 Jul 2016 17:23:10 -0700

On Sun, Jul 31, 2016 at 10:45 AM, Mahesh Jethanandani <
[email-masked]> wrote:

>> The thread started because the RFC does not say anything about a create
>> of a NP container. It only talked about delete. Can we make the (re-)create
>> of the NP container unconditional to whether a delete was performed on it.
>> So a tweak to your proposal would be:
>>
>>
> I think this argument of whether server should or should not create/delete
> NP containers is distracting from the main point of when NP containers
> should exist. In my mind, the NP container existence depends on whether
> child nodes exist or not. In the end, if child nodes exist, NP containers
> should exist (created), if they do not exist, the NP container should be
> removed.
>
> Can we agree on that?
>

No.

"should be removed" is an implementation choice.
It started as MAY be removed.  It needs to stay that way.

As I have pointed out 100 times,  the protocol has merge and replace
for the situation where the client is not exactly aware of how ceration and
deletion will be handled on the server.

There is no reason to force implementations to change.
If you magically delete containers, then magically recreate them.
If you don't then the nodes will be as the client expects, so no problem.

Andy

> it better know what it is doing.
>
> This is the same issue as a default leaf
>>> exist/don't exist or if this question is even valid.  I hope we can agree
>>> that as NP-containers are meaningless themselves they MUST NOT influence
>>> Netconf operations or model validation. (Which is a slight violation of
>>> Yes, that's correct in my opinion. It's a consequence of the NP
>>> container nature as defined in the current RFC6020/YANG 1.0 and bis.
>>>
>>>
>>> I understand we may advise a client not do so, but since  RFC6020bis
>>> does not forbid this, and it is also a perfectly valid <edit-config>, so I
>>> am sure people will try it.
>>>
>>>

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 31 Jul 2016 21:13:19 -0400

Mahesh Jethanandani <[email-masked]> writes:
> I think this argument of whether server should or should not
> create/delete NP containers is distracting from the main point of when
> NP containers should exist. In my mind, the NP container existence
> depends on whether child nodes exist or not. In the end, if child
> nodes exist, NP containers should exist (created), if they do not
> exist, the NP container should be removed.
>
> Can we agree on that? 

If the concept of a "non-presence container" makes any sense, then the
existence of an empty container must have exactly the same significance
as the non-extence of the container.

Given that, we have to make sure the protocol is consistent with that
principle.  E.g., if you ask to create an element of a non-existing NP
container, it must succeed, because asking to create an element of an
existing but empty NP container succeeds.

I don't see what all the consequences of this principle are, but if we
can't make the protocol consistent with it, then we can't properly
implement the concept of NP containers.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Sun, 31 Jul 2016 18:49:24 -0700

Hi,

YANG 1.1 has been changed so the XPath is not really backward-compatible
with YANG 1.0.  In YANG 1.1 NP-containers always exist if the non-NP parent
is
instantiated.

NETCONF and RESTCONF do not say anything about the server ignoring
the rules for operation="create", operation="delete" and
default-operation="none".
IMO itr would be a really bad idea to continue spreading little protocol
details
in the YANG RFC.  People might read the protocol spec and (correctly) assume
that the protocol does not trat NP containers special at all.

If anything, the sentence about MAY delete needs to be removed because
it is inconsistent with the XPath (always exists).

Andy