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

[Francesca Palombini <[e-mail]>]

Hi Mahesh,

I believe the question here is why this configuration is needed at all. Mark has made a constructive suggestion that will get the doc unstuck, that protocol-versions for the client is removed as well as specific talk about the different versions, rather than additional text be added about the possible impact.

Thanks,
Francesca

From: Mahesh Jethanandani <[e-mail]>
Date: Wednesday, 11 September 2024 at 22:28
To: Mark Nottingham <[e-mail]>
Cc: Francesca Palombini <[e-mail]>, The IESG <[e-mail]>, [e-mail] <[e-mail]>, NETCONF WG Chairs <[e-mail]>, NETCONF WG <[e-mail]>, Kent Watsen <[e-mail]>
Subject: Re: Francesca Palombini's Discuss on draft-ietf-netconf-http-client-server-23: (with DISCUSS)
Hi Mark,

Thanks for the suggestion.


On Aug 28, 2024, at 6:22 PM, Mark Nottingham <[e-mail]<mailto:[e-mail]>> wrote:

It doesn't.

Concretely, I suggest -

* In the Abstract, remove "Support is provided for HTTP/1.1, HTTP/2, and HTTP/3."
* Remove protocol-versions from http-client-common-grouping

Apparently, the question of the impact of client choosing a HTTP version is still not clear.  I am specifically referring to this exchange between you and Kent.

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?

It would help for Kent to document in the draft why choosing a particular version of HTTP in this particular case is a bad idea.

Thanks.



Also, I noticed that the Abstract says:


It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers).

If this is indeed intended to be a configuration mechanism for HTTP-based protocols, that would seem to be more in-scope with the HTTPAPI WG - has any coordination been done with them? In particular, the relationship to OpenAPI <https://swagger.io/specification/> should be considered, as it has considerable adoption and overlaps this use case.

Cheers,




On 27 Aug 2024, at 10:54 AM, Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>> wrote:

Hi Mark,

Francesca’s DISCUSS, which is a proxy for your HTTPDIR review was discussed in the telechat last Thursday. I am following up to find out if Kent’s reply below addresses your concerns or not. If my understanding is correct, the main sticking point is the client trying to specify a HTTP version it wants to use, and its possible impact on the HTTP ecosystem.

Let us know. Thanks.


On Aug 20, 2024, at 10:25 PM, Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:


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



Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>






--
Mark Nottingham   https://www.mnot.net/


Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>