Re: [netconf] AD review of draft-ietf-netconf-sztp-csr

[Kent Watsen <[e-mail]>]

Hi Qin, Charles, and Rob, thank you for your responses!

Rob, special thanks for checking with Francesca.   I did also notice that moving to 300 produced a disconnect with regards to RESTCONF’s “errors" RPC-reply message.  As you say, the draft currently returns error-tag as ""missing-attribute”, which aligns with 400 Bad Request.  

Looking at the "409 Conflict / data-missing” combination, I cannot say that it’s better.  FWIW, my understanding is that HTTP status codes ending with “00” (100, 200, 300, etc.) are the generic catch-all value for the class of codes, which have up to the next 99 values.   Thusly, I believe 400 is a more generic value than “409”, which suggests it’s the safest 4XX choice.

I fully agree there is no great choice here.  Specifically, given that the client sent a perfectly valid request, it seems wrong to say that the request was “bad”.   This is why I was thinking to define a custom code.  I understand the push-back but, to Qin’s point, why not?  Surely within the world of HTTP there is a pattern of a server prompting a client to provide more data.  That said, this is not something that I’m interested spending time on, unless Francesca offers immediate support for the proposal...

In sum, unless Francesca says otherwise, I think we should move back to the original "400 Bad Request”.  

Kent // contributor



> On Jul 1, 2021, at 10:01 PM, Qin Wu <[e-mail]> wrote:
> 
> Hi, Rob and Charles, Kent:
> I can understand we should be cautious to introduce new HTTP status code, mapping between error code and HTTP status code seems a right direction.
> Such mapping helps refine HTTP status code semantics. Using 300 multi choice response seems confusing, since we didn’t see location head field is added.
> I also think status codes such as 421 should be considered.
>  
> -Qin
> 发件人: netconf [mailto:[e-mail] <mailto:[e-mail]>] 代表 Charles Eckel (eckelcu)
> 发送时间: 2021年7月2日 0:36
> 收件人: Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>
> 抄送: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 主题: Re: [netconf] AD review of draft-ietf-netconf-sztp-csr
>  
> I agree that defining a new status code is likely not a good way to go.
> A 4xx response seems better to me than a 3xx response. 
>  
> Cheers,
> Charles
>  
> 
> 
> On Jul 1, 2021, at 9:27 AM, Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Charles, Kent,
>  
> Thanks for the suggestion.  The problem with that 401 requires the server to return a WWW-Authenticate header field (as per section 15.5.2, of draft-ietf-httpbis-semantics-16 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-16#page-161>).
>  
> I’ve also asked Francesca (ART AD responsible for HTTP) if she has a view.  She has taken a quick look and suggested that defining a new code is probably not the right way to go, but said that she would take a proper look after today’s telechat, but if we want to get other opinions then we could also ask on the httpbis mailing list.
>  
> However, I also noticed that RFC 8040 maps from NETCONF error-codes to status-codes, and defines:
> +-------------------------+------------------+
> | error-tag               | status code      |
> +-------------------------+------------------+
> | missing-attribute       | 400    (which is what you had originally).
>  
> An alternative could be:
> | data-missing            | 409              |
>  
> Which NETCONF defines as:
>  
>    error-tag:      data-missing
>    error-type:     application
>    error-severity: error
>    error-info:     none
>    Description:    Request could not be completed because the relevant
>                    data model content does not exist.  For example,
>                    a "delete" operation was attempted on
>                    data that does not exist.
>  
> Which would go hand-in-hand with 409:
>  
> 15.5.10 <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-semantics-16#section-15.5.10>.  409 Conflict
>  
>    The _409 (Conflict)_ status code indicates that the request could not
>    be completed due to a conflict with the current state of the target
>    resource.  This code is used in situations where the user might be
>    able to resolve the conflict and resubmit the request.  The server
>    SHOULD generate content that includes enough information for a user
>    to recognize the source of the conflict.
>  
>    Conflicts are most likely to occur in response to a PUT request.  For
>    example, if versioning were being used and the representation being
>    PUT included changes to a resource that conflict with those made by
>    an earlier (third-party) request, the origin server might use a 409
>    response to indicate that it can't complete the request.  In this
>    case, the response representation would likely contain information
>    useful for merging the differences based on the revision history.
>  
> I don’t see any great choice here.  I now think that aligning with RESTCONF seems to be right thing to do (so not using 300).  Perhaps choose “data-missing” & 409 if you think that is slightly better, or otherwise go back to “missing-attribute” & 400.
>  
> Regards,
> Rob
>  
>  
> From: Charles Eckel (eckelcu) <[e-mail] <mailto:[e-mail]>> 
> Sent: 01 July 2021 15:21
> To: Kent Watsen <[e-mail] <mailto:[e-mail]>>
> Cc: Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [netconf] AD review of draft-ietf-netconf-sztp-csr
>  
> Hi Kent,
>  
> I have not been following this draft closely but had a thought on this thread that I thought might be helpful.
>  
> It seems to me a 401 would be more appropriate in this scenario. 
> If the server does not require a CSR, it returns a 2xx response. 
> If it does require one, it returns a 401 indicating which one it requires.
>  
> Cheers,
> Charles
> 
> 
> 
> On Jun 29, 2021, at 1:54 PM, Kent Watsen <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  s/Since been/I’ve been/
>  
> K.
>  
> 
> 
> 
> On Jun 29, 2021, at 4:49 PM, Kent Watsen <[e-mail] <mailto:[e-mail]>> wrote:
>  
> Hi Rob,
>  
> Since been spinning on the below thread since we had it and am wondering if if would be best to ask for an HTTP expert review?   Please advise.
>  
> The reason being is that a close reading of "300 Multiple Choices" suggests that it’s used by an HTTP-server to indicate when there are multiple choices for a resource, whereas in this exchange, the “csr-support” node in the client’s POST effectively indicates that *it* has multiple choices for the server to choose from…
>  
> I’m beginning to wonder to the document might need to define a custom HTTP status code to properly indicate the semantics of the response…
>  
> Kent // contributor
>  
>  
> 
> 
> 
> 2. Section 2.2:
>  Assuming the SZTP-server wishes to prompt the SZTP-client to provide
>  a CSR, then it would respond with an HTTP 400 (Bad Request) error
>  code:
> 
> I wonder whether returning a 400 "Bad Request" error is really the best
> return code, i.e.,
> 
> 
> it wasn't clear to me whether this requesting the capabiltiies is really an
> error.
> 
> 
> Did you consider potentially using other return codes?  Possibly:
> 300 Multiple Choices,
> 403 Fobidden,
> 406 Not Acceptable
> 
> I did before look at all the 4xx codes.  I was initially drawn to 412
> Precondition Failed, but noted that it is specific to HTTP request header
> fields.   As for the others you mention, the semantics of 403 Forbidden is that
> the request should not be repeated, which isn’t out case, and 406 Not
> Acceptable regards the use of the HTTP “Accept” headers, which aren't in
> play here either.  That said, 300 Multiple Choices does appear to be a better
> if not perfect option, so I made that change in my local copy.
> 
> Ack.
>  
>  
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
>  
> _______________________________________________
> netconf mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>