[netconf] Re: HTTPBIS feedback on draft-ietf-netconf-http-client-server-23

[Kent Watsen <[e-mail]>]

Hi Robert,

Thank you for your comments.  While updating the http-client-server draft to address IESG issues, I also took the opportunity to address the issue you raised about the “uri” node being a “leaf” of type “string”.   Now the “uri” is a container with a number of descendent nodes, the most uncommon of which are under an “if-feature” statement called “full-uri-supported"

Please take a look and see if everything looks right: https://www.ietf.org/archive/id/draft-ietf-netconf-http-client-server-24.html.

Kent // author


> On Nov 26, 2024, at 11:45 PM, Robert Varga <[e-mail]> wrote:
> 
> On 09/11/2024 1.14 pm, Francesca Palombini wrote:
>> Hello Netconf wg, authors,
> 
> Hello everyone,
> 
>> I requested wg feedback about your draft-ietf-netconf-http-client-server on which I am holding a DISCUSS (following HTTPDIR review).
>> I know it was unfortunate that HTTPBIS was scheduled against Netconf, but wanted to point you to the recording of the discussion: https:// youtu.be/46JRo7U6DXc?si=whxnGLURhYjAslSZ&t=159 <https:// youtu.be/46JRo7U6DXc?si=whxnGLURhYjAslSZ&t=159> and the minutes: https://notes.ietf.org/notes-ietf-121-httpbis#AD-Requested-Feedback <https://notes.ietf.org/notes-ietf-121-httpbis#AD-Requested-Feedback>
>> The authors also had a productive discussion with HTTPBIS participants after that meeting, and I hope with the additional feedback we are going to be able to get the changes necessary to get it unstuck.
> 
> As a non-author implementer I have the following feedback on the points raised in the HTTPBIS discussion.
> 
> 
> 1. On Donald Miller's concern about explicit selection of HTTP version and reviewing popular client libraries.
> 
> I do agree in general, when we view the problem at a high-level, in particular in Java. Yes, there are Java libraries and frameworks which hide the HTTP particulars and that is one way of implementing RESTCONF.
> 
> I disagree on the point of using high-level libraries. In my implementation, we have used the Java-standard stack of Jetty, Jersey and JAX-RS to implement a RESTCONF server. There are two drivers behind that decision:
> - we are using Netty to implement various other protocols, like NETCONF, BGP, PCEP, OpenFlow and JSON-RPC, i.e. our codebase routinely integrates at a very low level, in order to provide symmetric server and client implementations
> - our RESTCONF implementation is an outlier in this regard, costing us in terms of dependencies and internal code to support them
> 
> While it is true that high-level frameworks do not provide these sorts of configuration options, when we get to low-level frameworks like Netty, these options are very much exposed to developers, to to point of having to explictly deal with object models and HTTP upgrade lifecycle, as evidenced in [0] et al.
> 
> Agreed on the point this being the policy on client side: my code will be implementing this policy. My library requires me to do so and therefore no, it is not that difficult to implement, as I have to write out the HTTP protocol upgrade codepaths anyway.
> 
> If there are libraries which hide these detail, users of those would be integrating at a much higher level and would not be implementing this draft. That is not my case.
> 
> No, it is not solely for the purposes of optimization. It is also for in-field interoperability: if I my software stack is required talk to a RESTCONF server implementation which is known to have busted HTTP/2 or HTTP/3 stack, I have to expose the knobs to use HTTP/1.1 only at admin discretion. This applies to all the various "it's buggy" cases, etc.
> 
> 
> 2. David's (sorry I did not catch the last name) concert on "how HTTP works"
> 
> This is not about all the (excellent) work HTTPBIS has done over the years. This is about how an HTTP library may be configured to handle HTTP session establishment.
> 
> As noted above, choosing the low-level route is a bit painful in that we need to implement quite a few bits one can get for free from a higher-level library. Nevertheless the choice is an implementation one, I do have an implementation which has very good reasons to choose that route, and in the context of my implementation this work fills an obvious gap[1].
> 
> 
> 3. Reflecting the Francesca's (?) comment about requiring this
> 
> Agree, for the most part my implementation will follow seamless upgrades. That having been said, my implementation may not be able to provide HTTP/3 (currently due to dependencies being experimental) or be build-time configured to support HTTP/1.1.
> 
> For that I need this model, or its equivalent, where I can express what the implementation *can offer* and what it *is configured to offer*. The "can offer" part is subject to both what code has been written and to what has been linked into the application image.
> 
> 
> 4. Daniel's point on "server not supporting H3"
> 
> Yes, agreed. This draft solves the "client not supporting H3" counter example in that argument, as is the case with my implementation right now (because I have not written my part of the code and my potential upstream libraries are not as ready as I would like them to be).
> 
> 
> 5. Daniel's point on "connection pooling vs HTTP/2+"
> 
> Yes, this is a valid point, but it is an implementation decision outside of the scope of this draft.
> 
> I know my library won't be implementing connection pools to deal with RFC8650's option to have multiple HTTP "logical connections". At least for the foreseeable future, my implementation's stance on that is going to be: you (user of my library) either use HTTP/2+, in which case I'll handle concurrency for you, or you get any number of pipelined HTTP/1 connections fro me and you deal with connection pools and all the implied complexity.
> 
> Beyond foreseeable future, though: any connection pooling functionality would be working on pure HTTP/1.1, so it is strictly a library add-on, which is how we would go about implementing it.
> 
> I do have a companion issue to go with those threadpools as well: my current NETCONF client implementation assumes :interleave, whereas I should be establishing two separate connections to handle the case when the NETCONF server does not support :interleave.
> 
> I will tackle both as time permits and users require, just like any nascent implementation would :)
> 
> 
> 6. Daniel's point on client developer's being equipped to make
> 
> I am implementing the imaginary "HTTP client library" here. I am very much prepared and equipped to deal with protocol upgrades. *My clients* do not have to deal with them because I provide the functionality *and default configuration* so they get reasonable behavior out of the box.
> 
> 
> 7. Mike's (sorry, did not catch the last name again) point re: usefulness
> 
> As I noted in a separate thread[2], the usefulness is two-fold here:
> - symmetry with the "HTTP server" side of things
> - symmetry of "RESTCONF-over-HTTP*" with "NETCONF-over-{SSH,TLS}
> My implementation happens to *really* like splitting out the "transport layer" part of what constitutes an HTTP conversation.
> 
> 
> 8. Mike's "I can see it for servers, but" point
> 
> Yes, and NETCONF WG has a mixin to that, called "call home". In those scenarios, the TCP connection is initialized in the opposite direction HTTPBIS assumes:
> - a RESTCONF server, which is an HTTP server underneath, would perform a connect(2) operation
> - a RESTCONF client, which is an HTTP client underneath, would perform a listen(2) operation
> This is a synchrony inversion of what one would normally consider an "HTTP Server" and "HTTP Client" when pure RFC9110 were involved, but we do have a valid use case for it (see RFC8071).
> 
> As an implementor, I just have to have a symmetric view of both a server and a client. Not having a standard here just means I will roll my own equivalent.
> 
> 9. Mike's "what is the use case for a generic HTTP client here?" point
> 
> There is none. Yes, you are exactly on the money with "HTTP client portion of a larger feature". That is exactly what it maps to in scope of my implementation: a configurable and reusable building block.
> 
> We are not looking for "Generic HTTP client", but rather for "configuration for HTTP client as implied by another protocol". In this case the implying protocol would be RESTCONF, which I personally have come to view as "NETCONF-over-HTTP".
> 
> As I have noted in the other thread: the goal is not a generic client, but an *embedded* HTTP client within the confines of a higher-level protocol. In this particular case RFC8040 defines how path/query/fragment needs to be mapped as a fixed-function device and this drown defines the schema/authority/http version parts of that conversion.
> 
> Let met reiterate this point more clearly:
> 
> ietf-http-client, however badly it is currently named, does not define anything which would be considered mandatory to implement. It just provides reusable bits and pieces that an implementation may choose to use.
> 
> I do not have a (serious) implementation (right now) to show it, but I know my implementation will need the equivalent bits and pieces in the future.
> 
> If there is an IETF standard, I will do my level best to implement it faithfully. If there is not, or the standard does not address my needs, I will roll my own.
> 
> As with anything YANG, this is not a big deal at all when an individual implementation is concerned, as anybody can roll whatever they want, and I am absolutely fine with that being the case forever.
> 
> Where it is not as fine, though, is the dream of a consistent of configuration model of internet-connected devices.
> 
> 10. The chair's comment about "HTTP semantics being version free as possible"
> 
> As someone, who has been aware of HTTP since when HTTP/1 was the prevalent thing clients used, but has only delved into the intricate details of its workings now, and only because of my implementation, I must say RFC911* do a wonderful job of separating concerns. Thank you and the entire HTTPBIS community for this work.
> 
> As a non-author, but sharing some of the authors' biases: we do not seek to circumvent this effort, nor develop it further without consultation. The way I see it, this effort is useful for standardizing the (bare minimum) configuration an embedded HTTP client implementation may require.
> 
> 
> 11. On Lars' (sorry, again the last name eludes me) point of version flexibility
> 
> Absolutely agree.
> 
> This is about the bare-minimum nerd-knobs everybody expects their HTTP client library exposed, with sanest possible of defaults. Not all implementations will have the luxury of being able to provide these -- those will not be using these models. I think most users of existing HTTP libraries will find their library allows tweaking these knobs, and those will have the option to adopt his model if and when they need to.
> 
> The model should provide "use-latest-HTTP-whenever-possible" as a manner of defaults, but account for possible implementation deficiencies -- i.e. it should be perfectly fine to use this model with an implementation which does not support anything by HTTP/3-with-mutual-authenthical. It should be equally usable by an implementation which supports nothing but HTTP/1.1-without-authentication.
> 
> That is what NETCONF WG needs to proceed this draft so that in becomes the foundation on which draft-ietf-netconf-restconf-client-server is built.
> 
> All other concerns, like "generic HTTP client", whatever that may mean, are part of a follow-up discussion, at least where my implementation is concerned.
> 
> 
> 12. On Lars' point of "decade back and forth compatibility"
> 
> It is not the case that HTTP is unique w.r.t. protocol negotiation. The codebase I represent here has BGP, PCEP and NETCONF (and other non-IETF protocols) implemented. Most of these protocols have some amount on negotiation built into them, which affects the overall semantics and my implementation deals with that just fine.
> 
> What makes HTTP stand out in this conversation is that it, unlike TLS or SSH, provides RFC6241 Figure 1 "Messages Layer" and "Operations Layer" abstractions.
> 
> As I pointed out in the other thread[2], this distinction warrants careful consideration and special care from both NETCONF and HTTPBIS WGs, so that NETCONF WG objectives are met without encroaching on HTTPBIS. This has not been the case so far where TCP, SSH, or TLS is converned -- simply because those protocols are not used by NETCONF WG beyond their "it is a bytestream" functionality and there was a 1:1 mapping between their respective communities and NETCONF WG would want.
> 
> My stance on this is that the document being discussed should only address the "scheme" and "authority" parts of an HTTP URL, plus some minimal protocol preference for negotiation purposes -- nothing less, nothing more.
> 
> If there is any appetite for anything approaching what would be called "a generic HTTP client configuration", my view is that that effort is separate and should be driven squarely by HTTPBIS. The effort currently under discussion, driven by NETCONF, should provide a solid foundation on which such an endeavor can build on.
> 
> 
> Caveat emptor: my implementation does not provide a serious HTTP/RESTCONF client implementation. On the other hand, it does provide a complete server implementation and the experience indicates client-side requirements in no uncertain terms: there needs to be a model symmetric to what the server side is doing. I estimate I will have a RESTCONF client in around 12 months' time.
> 
> Regards,
> Robert
> 
> [0] https://github.com/netty/netty/blob/4.1/example/src/main/java/io/netty/example/http2/helloworld/server/Http2ServerInitializer.java#L70-L76
> [1] https://github.com/opendaylight/netconf/blob/master/transport/transport-http/src/main/java/org/opendaylight/netconf/transport/http/HTTPClient.java#L33-L36
> [2] https://mailarchive.ietf.org/arch/msg/netconf/3RomX-rjTmDpHWmbsYHJmTUal80/
>