It seems that the dynamic subscription lifecycle of RFC8639 requires monitoring of the subscriber session – because requests to control such subscription can only come from that logical session. There does not seem to be a provision for identifying the subscriber other than the transport sesssion – which effectively means that for RESTCONF we needs explicit visibility into the transport layer, which JAX-RS cannot provide AFAICT.
The implication seems to be that if the HTTP transport session used to set up a dynamic subscription goes down, there is no way to control that subscription, nor is there a channel that can be used to notify the subscriber of events (like suspension of subscrption), hence the termination of subscriber transport needs to result in termination of subscription.

Furthermore, the QoS feature in RFC8639 requires HTTP/2 and, more importantly, a much more explicit control over transport layer (to the point of DSCP marking individual packets), which is completely outside of what JAX-RS can do (and can be expected to be able to do in any reasonable time-frame).

Coupled with the utterly-awkward and flaky JAX-RS async model, this leads to to a simple conclusion: we need to brew our own HTTP endpoint for RESTCONF.

Netty is the logical candidate, as we use it in pretty much all other low-level scenarios: NETCONF/TLS, BGP, PCEP, OFP, OVSDB ... Netty also provides HTTP/2 support out of the box and has HTTP/3 (QUIC) implementation prototype.

The focus of this issue is to provide RESTCONF service endpoint on a dedicated Netty-based server concurrently to the JAX-RS-based endpoint. This effort should define a proper distinction between the transport driver (Netty) and application (RESTCONF services) in a manner similar to how SSH/TLS/plain transports are disconnected from NETCONF.