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

[Kent Watsen <[e-mail]>]

 s/Since been/I’ve been/

K.


> On Jun 29, 2021, at 4:49 PM, Kent Watsen <[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.
>