Re: [Netconf] Long-lasting RESTCONF operations

["Uveges, Balint (Nokia - HU/Budapest)" <[e-mail]>]

Hi Andy,

>  From: EXT Andy Bierman [mailto:[e-mail]] 
>  Sent: Thursday, September 24, 2015 6:37 PM
>  To: Uveges, Balint (Nokia - HU/Budapest)
>  Cc: [e-mail]
>  Subject: Re: [Netconf] Long-lasting RESTCONF operations
>
>
>
> >  On Thu, Sep 24, 2015 at 2:21 AM, Uveges, Balint (Nokia - HU/Budapest) <[e-mail]> wrote:
> >  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.
>
>
>  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.

The 202 Accepted would mean that the server started to process the edit request.
You're right that a decent server could immediately respond with a 201 Created,
but there are cases where the underlying (and not so decent) system also does
some validation and provisioning work, that could easily delay the whole operation.

The status of the edit request (e.g. is it under processing, applied to the system
or rejected) could be indicated through the status URI that is provided in
the 202 Accepted.


>
>
>   
> >  Best regards,
> >  -Balint
>
>  Andy

Br,
-Balint