YANG Groupings for HTTP Clients and HTTP Servers
draft-ietf-netconf-http-client-server-33

The only comment I have (which I will not forward) is the reoccurring issue of Security Considerations in these drafts don't actually address security issues.  But that is merely my inability to look past it.

Thanks for addressing my previous DISCUSS and some COMMENT and nit.

Remaining point

## Section 3.1.1

I can only repeat my comment on the -17: `Having a module only using basic authentication seems *very* restrictive in 2024... I would have expected the WG to specify a YANG module supporting other authentication scheme.`

Having another RFC to augment the two modules of this I-D is probably not optimum, e.g., for TLS mutual authentication.

Thanks for the work you've put in to account for my (and Francesca's) DISCUSS and previous comments. With IANA's agreement, I'm clearing the DISCUSS with the most recent doc updates. My minor remaining comments are not blocking and may be incorporated, ignored, or discussed with the RFC Editor at your discretion.

In Section 3.1.2.1, "such as it may be limited by libraries used" is awkward. Should this be "independent of current configuration"?

In container proxy-connect, the <=H2 / >=H3 distinction may be misleading. It's not that CONNECT/CONNECT-UDP are available with those protocols, but that they're capable of transporting those protocols (since H3 goes over QUIC, which goes over UDP). You can do a CONNECT-UDP over H2 or even H1 and transport H3 inside it. Performance might stink, but it's technically possible.

=== NITS FOLLOW ===
Section 1, "suite a" => "suite of"
In container proxy-connect, "availble" => "available"

I support Francesca's DISCUSS.

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.