Hi, Lars, On Thu, Oct 1, 2020 at 6:20 AM Lars Eggert <[email protected]> wrote:
> Hi, > > thanks for the feedback! Below is an updated draft that attempts to > incorporate it. > > Please feel free to send further comments. > > Thanks, > Lars, Lucas and Mark > > -- > > Thank you for the update on your progress and your questions. Please find > our > responses below. > > On Qn-1: The future of multipath support for QUIC is currently under active > discussion in the IETF QUIC working group. While it was part of the > original > charter due to being under active investigation for the pre-IETF "Google > QUIC" > protocol, several participants have argued during the last year that QUIC's > connection migration support is sufficient for the majority of our use > cases, > and that full-blown support for multipath QUIC should consequently be > abandoned > as a WG deliverable. Other WG participants remain of the opinion that > multipath > support for QUIC is very important. Due to this active ongoing discussion, > we do > not have an estimate at this time whether WG drafts for multipath QUIC > will be > available in 1Q2021. > This is much improved. Perhaps it is also worth pointing out that (just like 3GPP) the IETF and QUIC working group are contribution-driven, so any timeline estimates depend on people contributing to the work, and the IETF is open to participation from anyone who can contribute to the work. > On Qn-2: The QUIC WG is chartered to provide an encrypted transport > protocol. > An option to disable encryption will hence not be standardized. > That's the right answer to the question the QUIC working group was asked. I agree that a different question might have gotten a different answer, but you're not a mind reader ... Best, Spencer > Kind regards, > Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs > >
