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

[Francesca Palombini via Datatracker <[e-mail]>]

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:

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

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

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