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

From: Zaheduzzaman Sarker via Datatracker <[email-masked]>
Date: Tue, 14 Dec 2021 05:23:27 -0800

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-netconf-sztp-csr-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/

----------------------------------------------------------------------
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.

  - is this specification defining new media type "application/yang.data+json"?
  and would ask why? It could very well use "application/problem+json" or
  "application/problem+xml" from RFC7807 or even "application/yang-data+json".

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the work on this document.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 15 Dec 2021 00:11:21 +0000

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 <[email-masked]> wrote:
> 

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?

>  "application/problem+xml" from RFC7807 or even "application/yang-data+json".

Aye!  This is a typo.   It should be "application/yang-data+json”, which is defined
In RFC 8040 here: https://datatracker.ietf.org/doc/html/rfc8040#section-11.3.2 <https://datatracker.ietf.org/doc/html/rfc8040#section-11.3.2>.

I have fixed this typo here: https://github.com/netconf-wg/sztp-csr/commit/7d62548f36b2bc325533c6d6a362900badc5301b <https://github.com/netconf-wg/sztp-csr/commit/7d62548f36b2bc325533c6d6a362900badc5301b>

An I-D update is pending a few more IESG-reviews.

Good?

Thank you!

K.

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Thu, 16 Dec 2021 15:45:13 +0000

Hi,

Thanks for the response. 

> On 15 Dec 2021, at 01:11, Kent Watsen <[email-masked]> wrote:
> 
> Hi Zaheduzzaman,
> 
>> On Dec 14, 2021, at 8:23 AM, Zaheduzzaman Sarker via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-25536b0fc4f2f08a&q=1&e=8bdc1b3f-3bb5-4977-b0cc-2ef6b2d2f69c&u=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F>
>> https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/ <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-0d29f8eb2e6170be&q=1&e=8bdc1b3f-3bb5-4977-b0cc-2ef6b2d2f69c&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-netconf-sztp-csr%2F>
>> 
>> 
>> 
>     https://datatracker.ietf.org/doc/html/rfc8040#section-7.1 <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-ba8856b8a30df5a9&q=1&e=8bdc1b3f-3bb5-4977-b0cc-2ef6b2d2f69c&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8040%23section-7.1>.
> 
Ok I get it. I am now thinking if it is worth mention this fact in the draft. My main point was that RFC7807 is more a generic HTTP way to send details about problem which this specification is using hence might need motivation for why not RFC 7807 is used, specially looking the discussion on this topic in the mailing list. 
> In RFC 8040 here: https://datatracker.ietf.org/doc/html/rfc8040#section-11.3.2 <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-c734ee8eb53f95cf&q=1&e=8bdc1b3f-3bb5-4977-b0cc-2ef6b2d2f69c&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8040%23section-11.3.2>.
> 
> I have fixed this typo here: https://github.com/netconf-wg/sztp-csr/commit/7d62548f36b2bc325533c6d6a362900badc5301b <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-fe22d327-454445555731-23a44a3c4c1031e7&q=1&e=8bdc1b3f-3bb5-4977-b0cc-2ef6b2d2f69c&u=https%3A%2F%2Fgithub.com%2Fnetconf-wg%2Fsztp-csr%2Fcommit%2F7d62548f36b2bc325533c6d6a362900badc5301b>
> 
Very good.

//Zahed

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 20 Dec 2021 19:09:31 -0800

Hi Kent,

> 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

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Dec 2021 23:10:13 +0000

Hi Zahed,

> Ok I get it. I am now thinking if it is worth mention this fact in the draft. My main point was that RFC7807 is more a generic HTTP way to send details about problem which this specification is usi…

As to if it is if it worth mention, I think not.  Again, the encoding used by this draft is solely at the whims of RFC 8040.   It seems that Ben agrees.   I’ll assume this comment is closed, and resulting in no action to update the draft.

Thank you!

> //Zahed

Kent // co-author