Subject: [Netconf] RESTCONF: PUT with state data

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 May 2017 09:52:16 +0200

Hi,

what is a RESTCONF server supposed to do if message-body of a PUT method
contains config false data?

In practical terms, if a client retrieves a container resource via GET
and the container has both configuration and state data, should the
server accept the same payload sent back with PUT, or is it necessary to
remove all config false items?

This seems to be unspecified in RFC 8040.

Thanks, Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 18 May 2017 16:49:22 +0200 (CEST)

> contains config false data?

I think it should be an error.

> remove all config false items?

I think the client needs to GET /...?content=config.

/martin

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 19 May 2017 10:42:44 +0200

> On 18 May 2017, at 16:49, Martin Bjorklund <[email-masked]> wrote:
> 

I would actually prefer that the server accept it and ignore config false data, which should be pretty easy.

> I think the client needs to GET /...?content=config.

Sometimes this means an extra round trip. Also, since content=all is the default, it IMO makes sense to keep GET and PUT with the same Request-URI symmetric.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 May 2017 12:54:30 -0700

Hi,

I agree with Martin.
The server MUST reject a request that attempts to set config=false data.
I think RFC 7231 supports this view:

   The PUT method requests that the state of the target resource be
   created or replaced with the state defined by the representation
   enclosed in the request message payload.

The server cannot add the config=false nodes to the configuration so
the representation is not valid for editing of configuration data nodes.

Andy

On Fri, May 19, 2017 at 1:42 AM, Ladislav Lhotka <[email-masked]> wrote:

> Sometimes this means an extra round trip. Also, since content=all is the
> default, it IMO makes sense to keep GET and PUT with the same Request-URI
> symmetric.
>
> Lada
>
> >
> >
> > /martin
> >
> >

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 20 May 2017 17:06:18 +0200

> On 19 May 2017, at 21:54, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> I agree with Martin.

By the same token

   The GET method requests transfer of a current selected representation
   for the target resource.

My reading is that that GET and PUT addressing the same resource are intended to be essentially symmetric.

The specification of PUT also says:

   A successful PUT of a given representation would suggest that a
   subsequent GET on that same target resource will result in an
   equivalent representation being sent in a 200 (OK) response.
   However, there is no guarantee that such a state change will be
   observable, since the target resource might be acted upon by other
   user agents in parallel, or might be subject to dynamic processing
   by the origin server, before any subsequent GET is received.

So I think in terms of RFC 7231 it is perfectly defensible that the server ignore config false data received in the message body of PUT.

Lada

---

From: Robert Wilton <[email-masked]>
Date: Tue, 23 May 2017 15:20:34 +0100

> I think it should be an error.
+1.

Trying to writing a non writable node must surely be an error.

> I think the client needs to GET /...?content=config.
Alternatively, an extension to RESTCONF could be defined to add an 
optional parameter to make a config write (i.e. PUT, POST, PATCH?, 
DELETE) best-effort, i.e. ignore any errors.

Rob

> .