Ballot for draft-ietf-netconf-http-client-server
Discuss
Yes
No Objection
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Thank you for the work on this document. Many thanks to Mark Nottingham for his HTTPDIR review: https://mailarchive.ietf.org/arch/msg/netconf/ZB0rAH2qZMF81THzvnDp7WI7eqM/ Mark brings up valid points about clients' HTTP configuration, as well as support for future HTTP versions (for the server) - I'd like to see Mark's concerns addressed before the document move forwards. Review copied for convenience: review-ietf-netconf-http-client-server-23-httpdir-telechat-nottingham-2024-08-19-00 > My recollection of our most recent discussions of this draft were that it > _might_ make sense to allow configuration of what version(s) of HTTP a server > supports, but not a client. Since -17, it appears the opposite has been done: > while server configuration remains the same, client configuration now allows > enumeration of supported versions. > Additionally, support is indicated by using separate, version-specific > indicators. This is a closed list and does not accommodate future versions of > the protocol. Can this be an array of strings instead? That would also allow us > to avoid the awkward phrasing in the introduction, which leads readers to > believe the set of HTTP versions is closed (counter to BCP56).
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.
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.
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.