Subject: [netconf] restconf 'get' on non-presence container

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2019 14:41:57 +0000

Given:

  module foo {
    ...
    container widgets {   <--- NOT a presence container
      list widget {
        ...
      }
    }
  }

Assuming no widgets have been configured, would a GET on "/foo:widgets"
return:

    1) 200 with an empty response (i.e., <widgets xmlns="..."/>
    2) 404 (Not Found)
    3) It's up to the implementation

With NETCONF, or RESTCONF when retrieving an ancestor of an 
NP-container, it's clear that RFC 7950, Section 7.5.7 (XML
Encoding Rules) comes into play:

   If a non-presence container does not have any child nodes, the
   container may or may not be present in the XML encoding.

However, this question regards the GET being on the NP-container itself.
That is, it's not an encoding question so much as a protocol question.
RFC 8040 doesn't discuss this directly, but Section 4.3 (GET) says:

   If a retrieval request for a data resource represents an instance
   that does not exist, then an error response containing a "404 Not
   Found" status-line MUST be returned by the server.

Okay, so it does the NP-container "exist" or not?  RFC 7950, Section 
7.5.1 (Containers with Presence) says:

   ...the [non-presence] container has no meaning of its own, existing
   only to contain child nodes.  In particular, the presence of the
   container node with no child nodes is semantically equivalent to the
   absence of the container node.

Kent

---

From: Kent Watsen <[email-masked]>
Date: Fri, 21 Jun 2019 21:24:40 +0000

Reviewing the very long "What should a server response be?" thread from 2016-07-11, it seems that the answer might be:

    4) depends on client-usage history (i.e., sometimes
        404 and sometimes 200 with an empty response).

Specifically, it seems that servers proactively creating or removing NP-containers is not desirable.

PS: I created https://github.com/netmod-wg/yang-next/issues/88 <https://github.com/netmod-wg/yang-next/issues/88>.

Kent // contributor

> On Jun 21, 2019, at 10:41 AM, Kent Watsen <[email-masked]> wrote:
> 
> Given:
> 
>  module foo {
>    ...
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Sat, 22 Jun 2019 23:18:50 +0000

Applying the same "client-usage history" logic to POST leads to an unfriendly result.  Specifically, a POST should return 404 if the parent NP-container (e.g., "/foo:widgets") doesn't exist, but a friendlier implementation would silently create all the ancestor NP-containers.  

Same applies to DELETE.  404 should be returned if the NP-container ("/foo:widgets") doesn't exist, but a friendlier option would be to always return 204.  This view is further supported by RFC 8040 saying "The resource must exist or the DELETE method will fail."

Kent // contributor

> On Jun 21, 2019, at 5:24 PM, Kent Watsen <[email-masked]> wrote:
> 
>> On Jun 21, 2019, at 10:41 AM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Given:
>> 
>>  module foo {
>>    ...
>> [email-masked] <mailto:[email-masked]>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 24 Jun 2019 10:06:47 +0000

Hi Kent,

I don't think that is the same conclusion that I reached with that thread - I'm not convinced that there was an agreed conclusion, different folks seem to different opinions on this.  I support you opening an issue on the YANG issue tracker to see if we more tightly specify this behaviour for clients.

My interpretation is that the current answer is (3), i.e. it up to the implementation.

I suspect that the answer may depend on how defaults are handled, and it may also depend on which datastore the query is being made against.

Thanks,
Rob

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 21 June 2019 22:25
To: [email-masked]
Subject: Re: [netconf] restconf 'get' on non-presence container

PS: I created https://github.com/netmod-wg/yang-next/issues/88.

Kent // contributor

On Jun 21, 2019, at 10:41 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Given:

 module foo {
   ...

Kent

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