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

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