Subject: [Netconf] Long-lasting RESTCONF operations

From: "Uveges, Balint (Nokia - HU/Budapest)" <[email-masked]>
Date: Thu, 24 Sep 2015 09:21:00 +0000

Hi All,

I would like to clarify an issue regarding the following RESTCONF scenario.

Let's assume that certain RESTCONF operations take quite some time on
the server side, for example the evaluation of a received POST method
(in Create Resource Mode), due to internal validations or due to the
processing of large amount of received data. According to the RESTCONF
draft (section 4.4.1):

  "If the POST method succeeds, a "201 Created" status-line is returned
   and there is no response message-body."

If I interpret this right, a RESTCONF client has to wait for 201 Created
(or for 4xx/5xx if something goes wrong) no matter how long it takes for
the server to process and answer the POST method. This behavior has no
significance if a RESTCONF client manages only a few RESTCONF server,
but could lead easily to a bottleneck in the client in case of large
amount of RESTCONF servers, when the client manages them in parallel.

RESTCONF is an HTTP-based protocol and RFC 7231 defines the status code
202 Accepted (section 6.3.3) as:

  "The 202 (Accepted) status code indicates that the request has been
   accepted for processing, but the processing has not been completed.
. . . 
   The representation sent with this
   response ought to describe the request's current status and point to
   (or embed) a status monitor that can provide the user with an
   estimate of when the request will be fulfilled."

With 202 Accepted it would be possible not just to inform the RESTCONF
client, that the method is accepted and is waiting to be processed but
also the HTTP connection could be terminated (if needed). Moreover it
would provide means for the client to poll the status of the request at
the URI provided in the Location header of 202 Accepted.

Side note: The RESTCONF draft lists the HTTP method 202 Accepted as well
in chapter 7, but it does not define any semantics.

Thank you in advance for your comments.

Best regards,
-Balint

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Sep 2015 09:36:51 -0700

> Thank you in advance for your comments.

So you are suggesting that a server can optionally support 202 Accepted,
which means of course it is mandatory to support for the client.

There seems to be some interest in the IETF right now wrt/ clarifying what
it
means when the server returns <ok/> to an edit request.  If it means "your
edit
is part of the intended configuration" then 202 Accepted is not really
needed as
any decent server can do this without delay.  If it means "your edit is now
reflected in actual network behavior" then perhaps it will be useful.

> -Balint
Andy

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