Draft: draft-ietf-quic-http

Commentary: This 
 The transport draft talks about QUIC being resilient to NAT rebindings . However , if a QUIC server is behind an L3 load balancer which simply routes based on 5 - tuple , then connections to this server will ( likely ) not survive rebinding . I could n't find any language which addressed whether such a deployment was " OK " or not . I think that since this load balance does not support NAT binding resilience , it is implicitly " bad " according to the draft , but others might disagree . In any case , I think there should be text to address this . Note , if the server advertised a preferredaddress which routed around the load balancer , and if clients were required to use this address , then that could obviously work . But preferredaddress support is a SHOULD , not a MUST . 
 We did discuss this issue . Use of empty connection IDs and demultiplexing based on source addresses . The conclusion there was that this was OK : people could do that , as long as it was clear that what they were getting was not different than TCP . That is , we made it clear that if you do n't use the identifiers that you control ( your addresses , the connection ID ) , then you accept that you ca n't handle migration at all and connections will drop ( well , unless you do something like trial decryption , which has some obvious scaling issues ) . The outcome of that discussion was captured in . Assuming that  finds this answer satisfactory ( and I have n't missed anything ) , then I suggest we just close this as a duplicate of . 
 I do n't think this captures Ryan 's concern : when the server is using a non - zero CID and also is behind 4 - tuple routing . I think he 's looking for a section of text to coherently describe what you have to do here : send either disablemigration or preferredaddress ; or forward packets between servers ; or either do n't use a common stateless_reset key , or put client address / port in the reset token . This is sort of ops - drafty but there real requirements on servers to behave in a secure way . I think someone with full command of the transport draft would figure this out , but it is not clearly stated anywhere . 
 I agree with   and the language he suggests makes sense to me . 
 This does feel a bit ops - drafty to me , but I 'd be happy to review a PR . 
 notes that : We need to normatively reference 7540 for this capability . 
 See also discussion thread starting at
Mailing list commentary: Hi , RFC7540 allows crumbling cookies for compression efficiency with HPACK . However , neither quic - http nor quic - qpack drafts mention cookies or crumbling . Is it considered safe for a QPACK implementation to crumble cookies before compression and concatenate them after decompression ? If so , should the draft include clarification on this ? Thanks , Bence
Paragraph (version B):
To allow for better compression efficiency, the cookie header field
RFC6265 MAY be split into separate header fields, each with one or
more cookie-pairs, before compression.  If a decompressed header list
contains multiple cookie header fields, these MUST be concatenated
before being passed into a non-HTTP/2, non-HTTP/3 context, as
described in HTTP2, Section 8.1.2.5.