> On 23. Jul 2019, at 17:56, Max Franke <[email protected]> wrote: > > Good point, I guess this might be true for other things as well. > Take SCTP for example, you might not know if it is multistream or not until > after it has already been raced and the association has been established. > So for some transport properties you might have to race protocols before you > can determine if two protocol stacks are equivalent or not.
No! - That is exactly the reason why we need to clarify that “equivalent” actually means “satisfies requires/prohibits set by the application/profile” – that means setting all to ignore will make all protocols equivalent! > > Best > Max > > Am 23.07.2019 17:30 schrieb Theresa Enghardt <[email protected]>: > Hi, (trimmed Cc list) > > On 23.07.19 16:53, Anna Brunström wrote: > Subject: Re: [Taps] How to handle Protocol stacks that are not equivalent > > > Yes, that's correct. My interpretation is that being in the candidate set > already requires equivalence. > > > Same here, seems we all agree on this. > > Agreed. > > However, the equivalence question becomes way more interesting once you're > adding security. > > TLS 1.2 is not equivalent to TLS 1.3, therefore you can't race them, the > Architecture clearly says so and I agree. > > As the application probably never asked for any specific version -- What if > our TCP stack only supports TLS 1.2 but our QUIC stack offers basically TLS > 1.3? We always take the better version and then fall back in case this fails? > But wouldn't that be racing? > > I think this is also an interesting question for the Implementation draft. > > Best, > Theresa > > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
