Subject: [Netconf] how to check if objects exist (rfc6241)

From: "Wisotzky, Sven (Nokia - DE)" <[email-masked]>
Date: Tue, 8 Nov 2016 11:21:09 +0000

Hi,

There are cases where the NETCONF client need to decide on the <edit-config> operation (create, merge, replace). Typically the client would check first, if the object already exists by running the <get-config> with subtree filter. At least, this is what OpendayLight has implemented today - even ODL is not making really use out of this info.

According to rfc6241 section 6.3 the following behavior is expected:

   The filter output (the set of selected nodes) is initially empty.

   Each subtree filter can contain one or more data model fragments,
   which represent portions of the data model that will be selected
   (with all child nodes) in the filter output.

   Each subtree data fragment is compared by the server to the internal
   data models supported by the server.  If the entire subtree data-
   fragment filter (starting from the root to the innermost element
   specified in the filter) exactly matches a corresponding portion of
   the supported data model, then that node and all its children are
   included in the result data.

This statement is conform to the description given in the ietf-netconf YANG model:

    output {

      anyxml data {

        description

          "Copy of the source datastore subset that matched

           the filter criteria (if any).  An empty data container

           indicates that the request did not produce any results.";

      }

    }

The challenge using an empty <data/> node is, that there might be several reasons why the no results could be produced:

1)      Object does not exist

2)      Part of the objects hierarchy does not exist

3)      NETCONF user has no read-permission for the corresponding subtree

4)      Subtree filter is incorrect (according to the YANG models supported by this node)

For 3) and 4) it would typically be better if a <rpc-error> is generated, providing an error-code to indicate the cause of this issue. Anyhow, the current ODL implementation does expects a regular response including the <data/> node - so in case of an <rpc-error> is send, ODL runs into JAVA exceptions.

In general it would be good if the NETCONF RFC could give some advice, if <get-config> with subtree filter is a reasonable approach to check if a specific object already exists. Other than this, it may be considered to create a new standard RPC to <chk-config> dedicated for this use-case.

Thx
wiso

---

From: Andy Bierman <[email-masked]>
Date: Tue, 8 Nov 2016 10:06:52 -0800

On Tue, Nov 8, 2016 at 3:21 AM, Wisotzky, Sven (Nokia - DE) <
[email-masked]> wrote:

> Hi,
>
>
>
> There are cases where the NETCONF client need to decide on the
> <edit-config> operation (create, merge, replace). Typically the client
> would check first, if the object already exists by running the <get-config>
> with subtree filter. At least, this is what OpendayLight has implemented
> today – even ODL is not making really use out of this info.
>
>
>
> The challenge using an empty <data/> node is, that there might be several
> reasons why the no results could be produced:
>
> 1)      Object does not exist
>

This is determined by parsing all the YANG modules advertised by the
server, parsing
the <hello> or YANG library contents, and applying all features and
deviations required.

> 2)      Part of the objects hierarchy does not exist

Same as (1) above

> 3)      NETCONF user has no read-permission for the corresponding subtree

NACM is silent on purpose on <get-config>.  Returning access-denied errors
is
not a good idea (complicates the client attempting to construct filters
that avoid the restricted data, which would require revealing the NACM
config
to all clients.

4)      Subtree filter is incorrect (according to the YANG models supported
> by this node)
This is never an error.  XPath is even better at returning the correct
answer
to the wrong question.  The server does not guess which questions are
correct.

>
>
> For 3) and 4) it would typically be better if a <rpc-error> is generated,
> providing an error-code to indicate the cause of this issue. Anyhow, the
> current ODL implementation does expects a regular response including the
> <data/> node – so in case of an <rpc-error> is send, ODL runs into JAVA
> exceptions.
>
>
>
> In general it would be good if the NETCONF RFC could give some advice, if
> <get-config> with subtree filter is a reasonable approach to check if a
> specific object already exists. Other than this, it may be considered to
> create a new standard RPC to <chk-config> dedicated for this use-case.
>
>
>

There is also with-defaults=report-all that can be used if the server
supports it.

> wiso

Andy

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

---

From: "Wisotzky, Sven (Nokia - DE)" <[email-masked]>
Date: Tue, 8 Nov 2016 20:28:02 +0000

Thx Andy,

Just to summarize your answer:
Implementations using <get-config> with subtree filter to check whether or not an empty <data/> node is returned are absolutely reasonable – and there is no additional specification for this needed. In these situations <rpc-error> is unlikely to happen, as even for access-control it is expected to return empty <data/> nodes. Therefore the approach within ODL makes certainly sense.

/wiso

From: Andy Bierman [mailto:[email-masked]]
Sent: Dienstag, 8. November 2016 19:07
To: Wisotzky, Sven (Nokia - DE) <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] how to check if objects exist (rfc6241)

On Tue, Nov 8, 2016 at 3:21 AM, Wisotzky, Sven (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

There are cases where the NETCONF client need to decide on the <edit-config> operation (create, merge, replace). Typically the client would check first, if the object already exists by running the <get-config> with subtree filter. At least, this is what OpendayLight has implemented today – even ODL is not making really use out of this info.

    output {

      anyxml data {

        description

      }

    }

1)      Object does not exist

This is determined by parsing all the YANG modules advertised by the server, parsing
the <hello> or YANG library contents, and applying all features and deviations required.

Same as (1) above

NACM is silent on purpose on <get-config>.  Returning access-denied errors is
not a good idea (complicates the client attempting to construct filters
that avoid the restricted data, which would require revealing the NACM config
to all clients.

This is never an error.  XPath is even better at returning the correct answer
to the wrong question.  The server does not guess which questions are correct.

For 3) and 4) it would typically be better if a <rpc-error> is generated, providing an error-code to indicate the cause of this issue. Anyhow, the current ODL implementation does expects a regular response including the <data/> node – so in case of an <rpc-error> is send, ODL runs into JAVA exceptions.

There is also with-defaults=report-all that can be used if the server supports it.

Thx
wiso

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Nov 2016 17:29:23 +0100

But you can only be sure whether an edit is successful by trying an
edit. I do not know why exactly ODL likes to send a get-config first;
it clearly does not tell you in all cases that a subsequent edit is
going to be meaningful. And if it is true that ODL is not making use
of the info, then ODL is just wasting resources.

/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: "Wisotzky, Sven (Nokia - DE)" <[email-masked]>
Date: Thu, 10 Nov 2016 14:18:31 +0000

I've tested the RESTCONF to NETCONF translation in ODL Boron. To be more specific, they are making use of the <get-config> result when doing a HTTP POST request. In this case they check, if the object does exist or not - and if it does exist they will return an error without trying to deploy.

I've raised a ticket about ODL about this behavior:
https://bugs.opendaylight.org/show_bug.cgi?id=7069

My view is, that they should follow the logic described in the following IETF Draft:
https://tools.ietf.org/html/draft-ietf-netconf-restconf

       +----------+-----------------------------------------------+
       | RESTCONF | NETCONF                                       |
       +----------+-----------------------------------------------+
       | OPTIONS  | none                                          |
       | HEAD     | none                                          |
       | GET      | <get-config>, <get>                           |
       | POST     | <edit-config> (nc:operation="create")         |
       | POST     | invoke an RPC operation                       |
       | PUT      | <edit-config> (nc:operation="create/replace") |
       | PATCH    | <edit-config> (nc:operation="merge")          |
       | DELETE   | <edit-config> (nc:operation="delete")         |
       +----------+-----------------------------------------------+

Even worse, I was trying the HTTP PATCH - but not much of a success with this.
Seems ODL has invented their own logic how PATCH is done.
Example as contained in:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MD-SAL:Restconf

<yang-patch xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-patch">
 <patch-id>example-patch</patch-id>
 <comment>This is example patch</comment>
 <edit>
   <edit-id>edit1</edit-id>
   <operation>create</operation>
   <target>/car-entry</target>
   <value>
     <car-entry xmlns="urn:opendaylight:params:xml:ns:yang:controller:config:sal-clustering-it:car">
       <id>0</id>
     </car-entry>
   </value>
 </edit>
 <edit>
   <edit-id>edit2</edit-id>
     <operation>delete</operation>
     <target>/car-entry/0</target>
 </edit>
 </yang-patch>

Thx
/wiso