IETF Logo Mail Archive

Re: Rechartering QUIC for Post Version 1 Work

Lars Eggert <lars@eggert.org> Fri, 29 January 2021 08:18 UTC

Return-Path: <lars@eggert.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229593A1042 for <quic@ietfa.amsl.com>; Fri, 29 Jan 2021 00:18:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3WuZ9kpekaS for <quic@ietfa.amsl.com>; Fri, 29 Jan 2021 00:18:06 -0800 (PST)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0033A103D for <quic@ietf.org>; Fri, 29 Jan 2021 00:18:06 -0800 (PST)
From: Lars Eggert <lars@eggert.org>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1611908280; bh=TgoJFElit5cjKQU3fJY9PNNtvsg545rngsewbpgmvAQ=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=V203OKyPv+UVKyIA6QOJDt4Ml8x3v9v0bw3HsEW87ZMzvbq1gR1Cadc3I2xhMYPSO KymOCwhXWWWSKVv6J5vZUfZnebFE2BFI/lt01SMO8Nlu9Gwh8G8a7LoM/sTYfBbdIB IHDXqOp3eVUS2K6uaneIEz/FsJA3MX+9ZE0RNeSI=
Message-Id: <4C483C56-1C1C-451F-9F0B-2C7D6FC8733F@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_1CA0C97C-8F5E-4CE5-9C30-45BD7DF35DE2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Subject: Re: Rechartering QUIC for Post Version 1 Work
Date: Fri, 29 Jan 2021 10:17:56 +0200
In-Reply-To: <3CDD98E2-92D6-4E5B-838D-CD56BE5BBA1E@fb.com>
Cc: IETF QUIC WG <quic@ietf.org>
To: Roberto Peon <fenix=40fb.com@dmarc.ietf.org>
References: <CALGR9oaXpZp87ujmkDAO6Tuy=m-s8qKDY9-azpm_PhVAMfkq9A@mail.gmail.com> <20210126170048.GB364092@okhta> <D01160E4-C89E-4DF5-B0A7-C5138E33D9C1@eggert.org> <20210126170932.GC364092@okhta> <CALGR9oaO8Q7TC9zyajM20gZkZPR1cRDSv-SeDqo0MfaQbgfAjg@mail.gmail.com> <20210126184815.GD364092@okhta> <CAKcm_gNXkCko=H3VofwnubMDctCN7Smx0LDbH-ruYcTk7S4kTg@mail.gmail.com> <CAPDSy+4kVyrvmkd8vDOzASV36Y2iR2HEGzrSkxXJaMmED6JDww@mail.gmail.com> <CAC8QAcc8E3G2r9tzggRgz5t8ZxeqpFu4dwg4bmoLH39DnBHV-Q@mail.gmail.com> <9D6FDFBB-77E1-4AB9-84C2-376690A026DC@eggert.org> <3CDD98E2-92D6-4E5B-838D-CD56BE5BBA1E@fb.com>
X-MailScanner-ID: C6A3B600065.A3144
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/jj7Y_Un0406Tk6_1Vuruzqm5h1E>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2021 08:18:08 -0000

Hi,

On 2021-1-28, at 21:30, Roberto Peon <fenix=40fb.com@dmarc.ietf.org> wrote:
> What would your answer be on where partially-reliable HTTP work would be homed (where it mostly requires QUIC changes, and may require some HTTP changes)?

without having discussed this with my co-chairs:

The H3 changes should live in the HTTP WG.

If partially-reliable HTTP also needs a new QUIC extension, the new charter envisions two options:

One would be to do the QUIC extension in the HTTP WG as well, with some sort of frequent collaboration/review with the QUIC WG. This would probably the preferred approach if that QUIC extension is really only applicable to partially-reliable HTTP.

If however the QUIC extension to support partially-reliable HTTP has broader applicability to other applications, i.e., establishes something like a generic partially-reliable QUIC transport service, that'd argue for doing this work in the QUIC WG instead, and collaborate with HTTP to make sure their needs are met.

Does this make sense? Does the proposed charter text read that way to you?

Thanks,
Lars

v2.23.0 | Report a Bug | By Email