Subject: 2nd draft, response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Oct 2020 14:18:46 +0300

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.

On Qn-2: The QUIC WG is chartered to provide an encrypted transport protocol.
An option to disable encryption will hence not be standardized.

Kind regards,
Mark Nottingham, Lucas Pardue and Lars Eggert, QUIC Working Group chairs

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Oct 2020 09:32:54 -0500

Hi, Lars,

> Please feel free to send further comments.

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.

> 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

---

From: David Schinazi <[email-masked]>
Date: Thu, 1 Oct 2020 08:17:54 -0700

Thanks Lars, the second draft looks good to me.

David

On Thu, Oct 1, 2020 at 7:36 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> 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

---

From: Waqar Zia <[email-masked]>
Date: Fri, 9 Oct 2020 16:32:49 +0000

Dear Lars, all,

In the view of the recently scheduled QUIC WG Virtual Meeting on 22nd October related to this topic, what is the plan on this LS?

Thanks,
Waqar.

From: QUIC <[email-masked]> On Behalf Of David Schinazi
Sent: 01 October 2020 17:18
To: Lars Eggert <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: 2nd draft, response to Liaison Statement, "LS on ATSSS Phase 2Requirements to IETF QUIC Working Group"

CAUTION: This email originated from outside of the organization.
Thanks Lars, the second draft looks good to me.

David

On Thu, Oct 1, 2020 at 7:36 AM Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Lars,

On Thu, Oct 1, 2020 at 6:20 AM Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks,
Lars, Lucas and Mark

--

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.

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,

---

From: Lars Eggert <[email-masked]>
Date: Mon, 12 Oct 2020 09:46:38 +0300

Hi,

> In the view of the recently scheduled QUIC WG Virtual Meeting on 22nd October related to this topic, what is the plan on this LS?

our response liaison statement is waiting for AD approval (as far as I can tell) before it will be posted.

Thanks,
Lars