Hi Mike,

First, I owe you and the WG a huge apology for not following up earlier.  To be honest, I never saw (and still cannot find) an email indicating that you posted a DISCUSS position to Datatracker on Mar 19 (the day after we met in the Bangkok hotel lobby).  FWIW, no email is found in the "netconf" mail archive either.  Please accept this email as my first response.

This email combines both of your Mar 19 ballots at https://datatracker.ietf.org/doc/draft-ietf-netconf-http-client-server/ballot.

Note: each edit references a GitHub commit, but all edits can be seen on DataTracker here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-netconf-http-client-server-26&url2=draft-ietf-netconf-http-client-server-28&difftype=--html

Kent // author


> Thanks for the conversation earlier this week. This has helped identify paths forward on at least some of these issues. While the last "HTTP versions" one may take some time to resolve, I think the others are likely straightforward.

Fingers crossed  ;)



> #  Impedance mismatch
> 
> Much of the impedance mismatch on this document stems from its origin versus its position. The document was written "to, ultimately, support the configuration of both the clients and servers of both the NETCONF [RFC6241] and RESTCONF [RFC8040] protocols." (Section 1.1) This has led at least one WG member on the mailing list to assert that "the scope of these documents is to deal with NETCONF Secure Transport layer and not much more."
> 
> However, the document itself is not restricted to Netconf configuration; it defines "a minimal grouping for configuring an HTTP client, and [...] an HTTP server." That means I have reviewed it from the standpoint of YANG primitives that could be used in any higher-level YANG module to describe the location of an HTTP-based service (to a client) or the configuration of such an HTTP-based service (to a server).

YANG has a way of being used outside original conceived context.  For instance, also part of this "suite of drafts" are the truststore, keystore, and tis-client-server modules, all of which are being used by other WGs in ways that have nothing to do with NETCONF or RESTCONF.   It's hard to predict with things like this.

As a possible first example of *this* draft's YANG being used outside the [netconf/restconf]-client-server drafts, the ietf-http-client YANG module is used by https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-15.  In that draft, this draft's YANG is used to configure a plain-old HTTP-client (not a RESTCONF-client).  Admittedly, the https-notif draft is a product of the NETCONF WG and I'm a co-author on it but, still, it's a data point.

To address the referenced member's "not much more" comment, I had interpreted it to being specific to URIs, whereby the path/query/fragment components are never needed to configure a RESTCONF client or server.  Thus syntax was added to remove those unwanted URI leafs, so only the scheme and authority URI components remained.  Here's the diff for that edit:  https://author-tools.ietf.org/iddiff?url1=draft-ietf-netconf-restconf-client-server-39&url2=draft-ietf-netconf-restconf-client-server-41&difftype=--html


> # URI types
> 
> This document does not reuse the uri type from RFC 6991. A solid rationale for this was presented in       https://mailarchive.ietf.org/arch/msg/netconf/3RomX-rjTmDpHWmbsYHJmTUal80/ -- thank you for sharing that reference, and I concur that it justifies defining a new YANG model for using uris. Since you're defining a new alternative that will hopefully be used in the future, I would like to see the updated uri type extracted for other modules to reference. Ideally this would not be embedded in an HTTP-specific module, but acknowledging that 6991bis is already late in the standards process and starting a separate document would introduce further delays, I'll be satisfied with extracting this as a separate type within this module.
> 
> (Although if the WG has already approved the new design, moving it from one WG-approved document in IESG Review to a different WG-approved document in IESG Review might not be as disruptive as it initially seems.)

Agreed.  A dedicated YANG module for the URI grouping would help it to be used more broadly.   To accommodate this, I updated this draft now define a third YANG module called "ietf-url" module, which defined nothing besides a grouping called "uri".

Here's the GitHub diff: https://github.com/netconf-wg/http-client-server/commit/05d38ad0caf610ddb8df7aee70f0fec8b599f657

I'll admit that this module is fairly simple, using unconstrained strings in places, but this is as it was before and can be improved if important.


> # TLS/HTTPS consistency
> 
> This document says that if the "tls-client-parameters" element is absent, TLS cannot be used. This results in an inconsistent state if the optional node is absent for an HTTPS URI. I would like to see a restriction which makes this node required iff the uri scheme is "https", as we discussed earlier.

Fair point and, I might add, this was my suggestion in a private exchange we had prior to meeting at IETF 122.  I just tweaked the YANG to require the "tls-client-parameters" node to be present when the scheme is "https".

Here's the GitHub diff: https://github.com/netconf-wg/http-client-server/commit/442aa613d45f9e12a62833bc945fc81033a11ef4



> # Local certificate store
> 
> I remain slightly unclear how "tls-client-parameters" references the certificate bag that represents the client's own cert store. It's clear that this supports either inlining certificate identities or a reference to a certificate bag, but if the client possesses a default certificate bag I don't see how that is referenced. I would have thought that would be the default behavior if no other certificate bag was explicitly specified, but that doesn't appear to be the case. Even if for my own education, can you give me an example of how this would be expressed?
> 
> Again, this may be a difference between a Netconf client and a generic HTTP client.

I hope this is an easy one  ;)

Searching for "inline-definition" in https://www.rfc-editor.org/rfc/rfc9645.html#section-3.2, see how locally-defined (i.e., NOT refs to a central keystore or truststore) keys and certs can be configured.   Now imagine the same configuration existing in the "second example" in https://datatracker.ietf.org/doc/html/draft-ietf-netconf-http-client-server-28#section-2.2.

Does this answer the question?


> # Proxy configuration
> 
> The proxy configuration section appears aimed at RFC 9110-style CONNECT usage. Given more recent and ongoing work in this space such as RFC 9298 (CONNECT-UDP) or draft-ietf-httpbis-connect-tcp (CONNECT-TCP), the endpoint would be expressed with a URI rather than with a bare hostname and port. It might make more sense to reuse the new URI type from earlier point, since a legacy CONNECT can still be expressed by omitting the path.

First, note that your next comment (below) may make this comment unnecessary.

That said, please note that RFC 9298 is referenced for CONNECT-UDP.  I didn't know about draft-ietf-httpbis-connect-tcp (CONNECT-TCP) before, but my quick scan of that draft is that, like CONNECT and CONNECT-UDP, whilst a URI is used on the wire, only the host and port components of the URI are used.  This is why I thought that, from a configuration perspective, only these values are needed.  I'm not 100% sure about this though.  Please advise.


> I note that proxies are generally configured for accessing all HTTP origins, not a particular HTTP origin. Embedding this in the configuration of how-to-reach-a-service rather than the general client configuration is... unusual.

I agree that proxy info is typically configured at a global level (not per connection).  But since the data model doesn't attempt to configure global values, and it didn't seem wrong, the proxy info was floated down into the configuration for each connection.  The hope is that, if there are a multiplicity of http-client configurations, a template applied to each connection could be used to factor out the redundant bits, hence eliminating burden from the operator.

FWIW, I'm not convinced that the proxy support if needed at all. The proxy support is there in an effort to be "complete", whatever that means given that the model intends to be minimally sufficient.  

Options:

	1) leave as is (noting that a template can remove redundancies)
	2) extend the model to also define global configuration
	3) remove proxy support from the model


> # HTTP versions
> 
> This draft has iterated in ways to express the HTTP version(s) the client should expect the server to support. -24 and previous had a bitmask to indicate supported versions, which was problematic because it embedded the current list of HTTP mappings into an RFC and wouldn't be forward-compatible to future mappings which may be developed. -25 replaces this with a min/max model which assumes that HTTP versions are necessarily contiguous, using enum values which ultimately have the same issue. (It would be sensible for a deployment to support only HTTP/1.1 and HTTP/3, for example.)

Regarding forward compatibility, even with bits, new bits can be defined by publishing an updated YANG module.  I agree that a client may only want HTTP/1.1 or HTTP/3 (skipping HTTP/2), which is why the bits approach was used initially.  The min/max approach replaced the bits approach because it was seen as the way to clear Francesca's DISCUSS, and it was better than nothing (specifically, in being able to limit the min version).  That said, and I'm unsure if you're suggesting this, we could go back to the bits approach (or it could be a YANG "list", if bits are somehow unwelcomed).


> Firstly, I suspect this configuration section is largely unnecessary to begin with. HTTP is deliberately defined to support essentially all requests over any HTTP version. Configuration of which HTTP mappings are enabled on a particular endpoint seems outside the scope of a "minimal" HTTP client configuration.

Yes, the HTTP protocol is deliberately defined to support essentially all requests over any HTTP version.  Hiding versions likely works just fine for browsers.   But it's not is simple for apps, especially when it comes to server-pushed data (e.g., SSE vs channels), which entails different app-level code being needed.  

So the ball moves from not just what versions an HTTP-library supports, but also what HTTP-versions the app is implemented to support.  Hence the app's desire to configure the library, before the connection is opened, to set what ALPNs are set on the wire, so that only the versions it knows are supported can be negotiated.


> Note that the server section does not bother to configure which versions of HTTP should be exposed on the server's TCP/TLS endpoints; it assumes that any version on which the client and server agree will be sufficient. Given a URI, a client and server can negotiate at runtime which HTTP mapping is most acceptable to them. Even the flags on certain clients to attempt a particular version (e.g. --http3 in curl still falls back to HTTP/2 if UDP is blocked or the build doesn't support H3; --http2 will upgrade to HTTP/3 if an Alt-Svc header is received) don't guarantee that a particular protocol will be negotiated, only a hint to the client as to preference.

I agree that it is inconsistent that the client-model can limit versions but the server-model can't.  It was an oversight.  Of course it makes sense that it be possible to constrain the server to specific versions also.

Here is a GitHub link: https://github.com/netconf-wg/http-client-server/commit/18434aedf4445046ce1e1582b9e1fd8448621d94.


> Secondly, if this configuration section is truly required, I'm concerned about embedding the set of HTTP versions in this document. It generally should not require a YANG document rev to permit a new version of HTTP to be used when supported by both client and server. We discussed solutions to this and haven't arrived at any option that doesn't involve a separate document, and I'm sympathetic to the delay that would involve.

Please note that, in lieu of ditching the ability to constrain versions entirely, we will never get away from there needing to be an updated YANG module, since the valid versions must be known/specified in YANG to be configured/validated in a YANG data-model.

That said, we can do things to limit the pain.  

The first and most common approach these days is factor out things like code points into separate and more focused YANG modules that are easier to rev.  For instance, there could be a module called "ietf-http-common" or, more focused, "ietf-http-versions".  This approach results in an RFC needing to be published to rev the module, but it being so small, it is not much effort at all.  Presumably said RFC would be published by the NETCONF WG.

The next-level step is to "automate" of updating the YANG module by having IANA maintain it.  Firstly, the module would use the "iana-" prefix instead of the "ietf-" prefix (e.g.,  "iana-http-common" or "iana-http-versions").  Then there would need to be instructions for when and how to make the updates (i.e., a note in an IANA registry).  This approach results in an RFC needing to be published to update the underlying registry when needed.  Whilst the NETCONF WG could publish this RFC, it makes more sense for the WG that are the domain-specific owners of the data to do this as part of their normal work, and hence truly automatic from a NETCONF WG perspective.  To this end, and without requiring the creation of a new registry, the ALPN registry is sufficient for this purpose.


> My preference would be to see the version section removed entirely here, aligning with the server configuration and allowing the existing negotiation logic to do its job. However, I'm open to alternative solutions which address these concerns, if we can find one.

I'm hoping that you can convince us that this is possible.  It would be best to escape this quagmire if possible.  I recall 




Kent // author