Subject: [yang-doctors] What should a server response be?

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 11 Jul 2016 12:48:10 -0700

I am posting this question here first, so we can add the final response to the YANG FAQ.

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 even-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 or replaced with a replace or a merge, 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: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jul 2016 21:58:11 +0200

>  response to the YANG FAQ.
 
I do not think this is a YANG doctors question; this is a NETCONF
question.

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

Why would the server do this? I do not see how this falls out of the
text in RFC 6241.

     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.

/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: Mahesh Jethanandani <[email-masked]>
Date: Mon, 11 Jul 2016 13:38:34 -0700

> On Jul 11, 2016, at 12:58 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Fair enough. Will post it to NETCONF mailing list.

Do folks think it would be a good addition to the FAQ? I know that it is not a YANG question, but then we do not have a separate NETCONF FAQ.

Mahesh Jethanandani
[email-masked]