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

[Kent Watsen <[e-mail]>]

Hi Mark,

Thanks again for your response!
Just a few comments below.

Kent


> On Aug 20, 2024, at 7:47 PM, Mark Nottingham <[e-mail]> wrote:
> 
> 
>> On 21 Aug 2024, at 6:11 AM, Kent Watsen <[e-mail]> wrote:
>> 
>>>> 
>>>> 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.
>> 
>> The two cases are covered below:
>> 
>> 1) Regarding configuring allowed HTTP-versions for a *client*
>> 
>> I don’t recall this being discussed before.  I apologize if it is an overbite on my part.  Looking at the document’s history, the version discussed in Brisbane didn’t have any ability to configure a client to specific HTTP-versions, hence why it suspect it wasn’t discussed...
>> 
>> In any case, two comments were received since Brisbane by WG members stating that it should be possible to configure a client to use only specific HTTP-versions, hence why it was added.  Is it wrong or bad to restrict a client to specific versions?  
>> 
>> Note that `curl` has params such as "--http1.1”, "--http2”, "--http3", and "—http3-only”...
>> 
>> Please advise.
> 
> As discussed, HTTP negotiates the version of the protocol in use at runtime; constraining it to a set of versions is counter to best practice (notwithstanding what curl can and cannot do).

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?

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?

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?

In case I'm completely upside down here, can you help me by saying if this "best-practice” is HTTP-specific and, if so, provide a pointer so I can understand it better?



>> 2) Regarding configuring allowed HTTP-versions for a *server*
>> 
>> Firstly note that the diff shows that it is unchanged from before.  But what is it, you ask?  The current version defines a YANG grouping called "http-server-stack-grouping” (seen in Section 3.1.2.2) that intends to support the configuration of:
>> 
>> - http over tcp
>> - http over tls
>> - http over quic
>> 
>> Technically, these are loosely connected to, but do not map exactly to HTTP versions.  If looking closely at it, you will notice “choice transport”, which means that only one of the three above (or any new ones added by other YANG modules in the future) can be defined at a time. 
>> 
>> But, of course, the intent is that a higher-level YANG module (such as the one defined in the restconf-client-server draft) will enable more than more to be configured.  For instance, for a HTTP/3 server, there would might be:
>> 
>> - one "http over tls” (i.e., tcp/443) configuration stack
>> - to present the Alt-Svc record to bounce the client to, e.g., udp/443
>> - one “http over quic” (e.g., udp/443) configuration stack
>> - to serve the HTTP requests
>> 
>> Makes sense?
> 
> Sort of. I am not confident that this will map well to actual HTTP server configurations, but don't oppose this approach from what I can understand of it.

Thanks.  FWIW, when composing my previous response, I realized that some of the text in the draft could be improved.   Once we close on the client-versioning bit, I’ll update the draft to improve this text slightly.



>>>> 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 "protocol-versions” leaf is not a closed list.  The leaf uses the YANG “bits” statement that, according to RFC 7950, section 11:
>> 
>> o  A "bits" type may have new bits added
>> 
>> In configuration, the “bits” type is an array of strings.  For example, following is in an example in the draft:
>> 
>> <protocol-versions>http-11 http-2 http-3</protocol-versions>
> 
> I see. The specification still enumerates only those versions, however -- per above, versioning should be omitted from clients completely.

Happy to accommodate, once I can understand what you mean, per my response above.


> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/



Kent  // as author