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

[Robert Varga <[e-mail]>]

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/