Based on experience, I would say that the state issues will likely occur with TCP accelerators over a satellite link. HTTP/1.1 isn't as deterministic as you would like to think once an accelerator with prefetching is involved, and this can break the assumptions of security protocols layered over HTTP/1.1. If you're really properly RESTful, this shouldn't be an issue, of course... Lloyd Wood lloyd.wood@xxxxxxxxxxx http://about.me/lloydwood ________________________________ From: Michael Richardson <mcr+ietf@xxxxxxxxxxxx> To: ietf@xxxxxxxx Sent: Wednesday, 4 October 2017, 8:58 Subject: should we specify HTTP/1.1 now that HTTP2 is out? I'm seeking guidance. It might be that this is a job for lwig, or perhaps there is already a document which details how to do the profiling I care about. If so, please point me at that. In ANIMA's BRSKI protocol, which is based upon RFC7030 EST, we run over HTTP 1.1 today using a single TCP connection. It's HTTP over TLS ("HTTPS") [h2c?] rather than an upgrade. In BRSKI there are state issues with both the TLS and the HTTP process. The TLS server certificate is not trusted by the client until after at least one RESTful interaction occurs. Only once that has occured is the connection considered secure. We are concerned about how the protocol could become broken if used with HTTP2 with interleaving of requests/responses. With HTTP (port-80) transactions, using the RFC7540 section 3.2 upgrade, one could just decline to ever do the upgrade and be done. With HTTPS, this is negotiated in the TLS connection, so one can go to HTTP2 directly, I think. While limiting ourselves to HTTP/1.1 might be a good policy, I worry that at some point in 10 years, the HTTP/1.1 code might be in the library only to support our use case, with the application code on the device having moved on to HTTP2 only. What I think we are looking for is a set of things we can specify that will make HTTP2 as deterministic (and slow!) as HTTP/1.1. For instance, I think that SETTINGS_MAX_CONCURRENT_STREAMS = 1 would do 90% of it. Should we turn off PUSH? Can/should we recommend lower values for window sizes, etc? (ANIMA end points are not constrained in the IoT/RFC7228 sense, but rather are control plane CPUs, with megabytes of ram, often partitioned at boot time. But, ANIMA BRSKI may also applies to Web connected devices like the baby monitors that have wreaked havoc.) -- Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works -= IPv6 IoT consulting =-