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

[Mark Nottingham <[e-mail]>]

> 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).


> 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.


>>> 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.

Cheers,


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