Re: [netconf] Éric Vyncke's No Objection on draft-ietf-netconf-http-client-server-17: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Éric,

Thank you for your valuable comments.
Please find responses below.

Kent


> On Feb 12, 2024, at 11:46 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-netconf-http-client-server-17: 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:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-netconf-http-client-server-17
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Mahesh Jethanandani for the shepherd's detailed write-up
> including the WG consensus and the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> # COMMENTS (non-blocking)
> 
> ## What about HTTP3 ?
> 
> Is HTTP/3 (RFC 9114) so different to HTTP1/HTTP2 that it is not included in
> this I-D ?
> 

I don’t know.  Can you help me understand?  
Do you know if there are any QUIC-specific configurations:
	- beyond the basic UDP local/remote/ address/port config?
	- for either the client or the server?
	- I guess it has all the TLS stuff…

If we were to add QUIC, I think that there would need to be a 
new document called  “draft-ietf-netconf-quic-client-server”.
	- I would start it by copy/pasting “draft-ietf-netconf-tls-client-server” 
		- since QUIC needs to be configured like TLS.
	- this sounds like a lot of work...

In the meanwhile, I added the following tex to the linked sections:

	https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-17#name-the-http-client-stack-group
	https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-17#name-the-http-server-stack-group

		NEW: Other protocols (e.g., QUIC) may be added by future work.

	https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-17#name-the-http-client-grouping-gr

		NEW: The "proxy-connect" node defines support for HTTP 1.1 and HTTP 2.0.  Support
		for other protocols versions, e.g., HTTP/3, MAY be added by future work.


Good for now?




> ## Section 2.1.2.1
> 
> 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.

I could add “digest”, but doing much more gets complicated and contentious.  Actually, an older version of this draft defined many authentication schemes.  See the tree diagram here:  https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-00#section-3.1.    But there was concern by reviewers that the draft was defining too much.   As a result, I removed all of the auth schemes except for “basic” - maybe overkill?

From https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-17#name-the-http-client-identity-gr:
The "basic" authentication scheme is the only scheme defined by this module, albeit it must be enabled via the "basic-auth" feature (see Section 2.1.1 <https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-17#client-features>).
Other authentication schemes MAY be augmented in as needed by the application.

Thoughts?



Thanks again!
Kent