Re: [netconf] Zaheduzzaman Sarker's Discuss on draft-ietf-netconf-sztp-csr-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Kent,

On Wed, Dec 15, 2021 at 12:11:21AM +0000, Kent Watsen wrote:
> Hi Zaheduzzaman,
> 
> Thank you for your review!  Responses to your comments are below.
> 
> Kent // as a co-author
> 
> 
> > On Dec 14, 2021, at 8:23 AM, Zaheduzzaman Sarker via Datatracker <[e-mail]> wrote:
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > I would like to discuss two points -
> > 
> >  - as this specification add more detailed response for HTTP 400 Bad Request
> >  error code. I would like to know if RFC7807 has been considered for such
> >  usage.
> 
> 
> The authors did not know about RFC 7807.  Thank you for bringing it to our attention.
> 
> Looking at RFC 7807, we do not believe that we should use it because:
>   - an SZTP-server (RFC 8572) is a RESTCONF-server (RFC 8040)
>   - RESTCONF defines it’s own mechanism for structure responses
>     https://datatracker.ietf.org/doc/html/rfc8040#section-7.1.
> 
> This comment would have been good when RFC 8040 was being published, but
> now it is water over the bridge, so to speak.  Agreed?

I agree that RFC 8040 would have been the place to use the RFC 7807
structured error responses, and trying to shoehorn it in here is not a
great fit.  However, I also think that using 400 Bad Request as part of the
expected flow of operations is also not a good fit.  That is, what seems to
be happening in this workflow is not so much that the client sent a "bad
request" as that it sent a request for something logically different than
"get-bootstrapping-data": it seems more like a "negotiate CSR parameters"
operation than "get boostrapping data", at least in the flow as described.

In particular this seems rather dicey in the context of Section 4.6 of
draft-ietf-httpbis-bcp56bis.  It feels like this RPC exchange is
essentially redefining the HTTP status code and expecting this specific
application to execute a specific behavior in response to that status code,
specifically, a specific behavior that is not the normal HTTP semantics for
that status code.  BCP56bis goes so far as to state that "Applications
using HTTP MUST NOT re-specify the semantics of HTTP status codes, even if
it is only by copying their definition."

I would like to get a better understanding of why it was deemed necessary
to introduce this behavior into the get-bootstrapping-data RPC, rather than
defining a new RPC for the new functionality.

Thanks,

Ben