On 04/03/2018, 23:12, "Martin Thomson" <martin.thom...@gmail.com> wrote: > We are about to remove that bit from the QUIC packet. I don't see any > advantage in adding it here. > > Can you explain in more detail who you think consumes this bit?
Server or server-side middleware that doesn't know whether the packet that needs parsing belongs to a session that negotiated CID or not. I'm not sure the analogy with QUIC holds here: AFAIU, in QUIC the server can always say "use CID when you are talking to me"; in DTLS, the server has to live with a mix of CID and non-CID sessions. On-path diagnostic tooling. E.g., if you have a huge fleet of sensors deployed behind a NAT where rebindings happen basically every time the sensor sends the update upstream (the 5-tuple is totally ephemeral), and you need to do anomaly detection, being able to extract the CID from the flows is pretty handy. But in general, when you don't own the endpoints and are asked to debug, having a working wireshark is nice. I genuinely can't see what advantage we get by not having its presence explicitly signalled. Could you elaborate a bit on that? Cheers, thanks _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
