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

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 <kent+ietf@watsen.net> wrote:
> 
> 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
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf