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

[Mark Nottingham <[e-mail]>]

Kent,

We have explained repeatedly that HTTP semantics are not versioned, and that the runtime protocol version is negotiated, not preset in configuration. Some tools (e.g., Curl) expose it for testing, not operational purposes. Limiting the HTTP version in use by a client in configuration is bad practice because it limits the deployments of new protocol versions unnecessarily. 

Regarding being 'in the rough' - we're determining IETF consensus, not WG consensus here.

Cheers,


> On 18 Sep 2024, at 1:50 pm, Kent Watsen <[e-mail]> wrote:
> 
> Hi Francesca,
> 
> It was the NETCONF WG's idea (not mine) to add the ability to configure what protocol versions a client wishes to use.   The ability to do so is not uncommon, e.g., to support test automation, resulting in a pattern of YANG models constraining versions when versions exist.  This is normal operation and so it’s surprising/alarming that constraining available versions may harm the HTTP ecosystem.  This opinion is inconsistent with experience, and seems to be in the rough.  It is hard to understand/accept when no concrete example is provided.  Adding text regarding possible impact may be important for future maintainers of this work, depending on the nature of the issue.
> 
> Mark’s other suggestion to remove the "Support is provided for HTTP/1.1, HTTP/2, and HTTP/3.” sentence from both the Abstract and the Introduction sections is fine, and can be considered done (will be part of the next update).  Here’s the GitHub diff:  https://github.com/netconf-wg/http-client-server/commit/ee514fcb49406c58bc515432d6c96772b766ae4a.
> 
> Thanks,
> Kent
> 
> 
> 
>> On Sep 16, 2024, at 6:12 AM, Francesca Palombini <[e-mail]> wrote:
>> 
>> 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]> 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]> 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]> 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]
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Mark Nottingham   https://www.mnot.net/
>>  
>> Mahesh Jethanandani
>> [e-mail]
> 
> 

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