[netconf] Zaheduzzaman Sarker's No Objection on draft-ietf-netconf-http-client-server-23: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-netconf-http-client-server-23: No Objection

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/about/groups/iesg/statements/handling-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-http-client-server/



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

Thanks for working on this complex group of specifications.

I have following comments/questions and I believe addressing those will improve
the specification

   - May be I am failing to see the whole picture but I understand that
   draft-ietf-netconf-tls-client-server defines tls-common module along with 
   tls-client and tls-server modules, but I don't see the Section 3.1.2.2
   mentions tls-common module which is common to both client and server. is
   this an overlook? if not then, I would expect some description of how
   tls-common module is used here or not used here. ( I was initially thinking
   of this as discuss worthy but as I am not sure I understand how this whole
   thing is used together I am putting it as comment, and here is your chance
   to educate me :-) )

   - Looking at Section 3.1.2.2 the quic-supported tree, I am wondering if this
   how it should be done or not. As TLS 1.3 is ovened into QUIC, QUIC take
   cares of the TLS record layer, the way tls-server-parameters and
   tls-server-grouping is used would it be sufficient? may be it does, but I
   dont understand it as TLS is not used with QUIC as it is used with TCP.

   - proxy-connect feature only refers to CONNECT method of RFC9110, but what
   about the CONNECT-UDP (RFC9298) that http clients can use to connect via
   proxy? Is that considered here but explicitly put out of scope? I can see
   HTTP/2 and HTTP/3 clients can use CONNECT-UDP method which is derived from
   CONNECT method.