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

[Kent Watsen <[e-mail]>]

[moving Mark to the To line]


Hi Francesca,

Thank you for pointing me to Mark’s HTTPDIR review.  I see that his message was sent to the NETCONF alias but, for some reason I didn’t receive it.   In any case, please see below.


> On Aug 20, 2024, at 11:32 AM, Francesca Palombini via Datatracker <[e-mail]> wrote:
> 
> Francesca Palombini has entered the following ballot position for
> draft-ietf-netconf-http-client-server-23: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thank you for the work on this document.
> 
> Many thanks to Mark Nottingham for his HTTPDIR review:
> https://mailarchive.ietf.org/arch/msg/netconf/ZB0rAH2qZMF81THzvnDp7WI7eqM/
> 
> Mark brings up valid points about clients' HTTP configuration, as well as
> support for future HTTP versions (for the server) - I'd like to see Mark's
> concerns addressed before the document move forwards.
> 
> Review copied for convenience:

Thank you for copying Mark’s HTTPDIR review.  I will respond below.


> review-ietf-netconf-http-client-server-23-httpdir-telechat-nottingham-2024-08-19-00
> 

Hi Mark,

Thanks for your review!
Please see below for responses to your comments.

Kent


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


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?


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

All good?


Thanks again!
Kent