[netconf] Re: Francesca Palombini's Discuss on draft-ietf-netconf-http-client-server-23: (with DISCUSS)

[Kent Watsen <[e-mail]>]

>> Negotiating version at runtime (startup handshake) is common practice.   The way it usually goes is that the client has a list of what it allows, and the server has a list of what it supports, and the latest/newest common version is selected.  This is how it works in HTTP also, yes?
> 
> No. See:
> 
> https://httpwg.org/specs/rfc9112.html#http.version
> https://httpwg.org/specs/rfc9113.html#starting
> https://httpwg.org/specs/rfc9114.html#discovery

Fine, but your point is only made because HTTP keeps changing its transport  ;)

Assuming HTTP/4 stays with QUIC, then RFC 7301, Section 1 says:

   With ALPN, the client sends the list of supported application
   protocols as part of the TLS ClientHello message.  The server
   chooses a protocol and sends the selected protocol as part of
   the TLS ServerHello message.

In such a case, the client’s ALPN list would be [h3, h4], and the server returns one or the other, depending on what it supports, which is effectively what I wrote. 


I also note that RFC 9114 Section 3.1 says:

   A client MAY attempt access to a resource with an "https" URI by
   resolving the host identifier to an IP address, establishing a
   QUIC connection to that address on the indicated port (including
   validation of the server certificate as described above), and
   sending an HTTP/3 request message targeting the URI to the server
   over that secured connection. 

This optimization is possible if the client knows it only wants QUIC-based HTTP.   This is faster than first establishing an HTTP/2 connection and switching after receiving the "alt-svc” header.  This is also faster than the client optimistically switching after receiving a "TCP RST”, assuming the server isn't listening on tcp/443.


>> Let’s say there exists an HTTP-client that requires multiplexing, so it requires at least HTTP/2.  But it connects to a server that only supports HTTP/1.1.  IMO the negotiation should fail, letting the HTTP-client to try another server.  Isn’t this proper?
> 
> A "HTTP-client that requires multiplexing" (i.e., an application using HTTP that wants to multiplex) can use multiple HTTP/1 connections, or HTTP/2, or HTTP/3, or...

It was just an example.  The general point is that each HTTP version comes with a set of features (e.g., scalability, performance, security, etc.) and a client may require a specific feature-set.


>> The configuration -23 regards setting the client’s "list of what it allows".  It can be a list of versions, or the special wildcard value “any”.   It is expected that this “list of versions" will feed into the negotiation.  IDK, maybe you thought that the draft was always setting the client to a single version?
> 
> No; I'm only attempting to make sure that your specification doesn't actively harm the HTTP ecosystem.

Good - and thank you!


> Constraining the available versions is one way that can happen.

Can you provide a scenario where the client being configured to use specific versions harms the HTTP ecosystem?


> I continue to be concerned that you're defining a configuration language for HTTP without a strong understanding of the protocol's core concepts or common implementation patterns.

It could also be that you don’t appreciate that, by nature of this being “configuration”, it is not a "first contact” scenario.  That is, this is much more like a script using `curl` than a user using a browser.


Thanks again!
Kent