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

["Charles Eckel (eckelcu)" <[e-mail]>]

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