Re: Rechartering QUIC for Post Version 1 Work
Lucas Pardue <lucaspardue.24.7@gmail.com> Wed, 27 January 2021 00:56 UTC
Return-Path: <lucaspardue.24.7@gmail.com>
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 7C0603A0EAC for <quic@ietfa.amsl.com>; Tue, 26 Jan 2021 16:56:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Level:
X-Spam-Status: No, score=-1.846 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 h4qe2gvBhpLg for <quic@ietfa.amsl.com>; Tue, 26 Jan 2021 16:56:33 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 431073A0EA7 for <quic@ietf.org>; Tue, 26 Jan 2021 16:56:33 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id n6so307861edt.10 for <quic@ietf.org>; Tue, 26 Jan 2021 16:56:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7+fFxy+naSd72pfT+1NIZrp73r1uHNTNqRM6aDzsTzU=; b=MkfFDM2w5QXQWxHQLQHLSGicwRvz/O/3vsXNTHT0U6i/X2Sh8R98QIFt3rnCh66lWS IJX+KjZOGiL7Kcqx1dwRrZb2Jp7fSv1U2aWy1wxe9/lsMKqJu563/RVVMR5NMrNBbti9 /D12471betqPGpQcYpwBx4PaPl1ZN4ez6Az5q6DHHBqbJXd6oLY/s+TsWlGNVl+LlHOT kWDTals4b/AfIwoRnARJVWnPOrYPK3ME9wtTAfEQOmOUZlWIkxp5tDFjq6+mgZtVbrlL +AqogtH1xy857O/Srd7bJjHe30cL4WQKbkESFUYSPm2nE5fjZm8LW3Zzkxg9kr+3ddEp hsIA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7+fFxy+naSd72pfT+1NIZrp73r1uHNTNqRM6aDzsTzU=; b=lBaAaWbQsJxL2psn2fcbfKiiEn5+E84l8DJneNLe5NpUT4aGMgbPWo7Ch9ZwLXvsrm RmsPMMtqL4sEy+B8hiyPjdEziEiH5wxamPG5MaEPzsIS1OmsvxAP3K8qtR7u3Zmm4rqD 9B/FJef5bAlL3KQD3NAG5fHF9t/JRL4ChsXHrE6aF/VtX5qOck4/J0meqVAEPcqfMYQE oIK/XpfeCuYH4VK7O60VzIfulZ85PolEO56rPNSzqHfR8G/Qyy6WXIMRAcUynTbUllxm BJ9jS/JLICxlQz3wsPXDThyPI/RyArZ/UGWdi20bwgYcQEnQTr49JJhc19KL93qYzXkn Pm+A==
X-Gm-Message-State: AOAM5334x8bI/njmbDNHJOr/AaGQvZVIhFlZaJeCkR7vzG66N5pYpFTQ 5e/NtD2blqXyac8xySTy/A45GgtBhoJjBci6R8k=
X-Google-Smtp-Source: ABdhPJy3kEESTPQkli8q5S3f2m/f/spDnqwuezJ0jdwd5cUCObUlFS6cl8/fbjw87QH5CoAtQRZS8Be0b7mROmCWUug=
X-Received: by 2002:a05:6402:513:: with SMTP id m19mr6646247edv.229.1611708991459; Tue, 26 Jan 2021 16:56:31 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CAPDSy+4kVyrvmkd8vDOzASV36Y2iR2HEGzrSkxXJaMmED6JDww@mail.gmail.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Wed, 27 Jan 2021 00:56:19 +0000
Message-ID: <CALGR9oZ6i2jzk6YWRhOnSfcH7hZugy5Juzhkc7U0iNSVrC77Yg@mail.gmail.com>
Subject: Re: Rechartering QUIC for Post Version 1 Work
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ead46805b9d73d35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/VonMuwx_oYa7fC7FqqOsr5K7_CE>
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: Wed, 27 Jan 2021 00:56:36 -0000
Hi David, Thanks for the feedback. I've responded in-line, and some of that text responds to points Ian raised too. On Tue, Jan 26, 2021 at 9:54 PM David Schinazi <dschinazi.ietf@gmail.com> wrote: > I'm supportive of the overall direction of this rechartering, with some > concerns though: > > 1) multipath is not mentioned in this charter - based on the conversations > we've had over the past months, I think we should be explicit about whether > multipath is in or out of scope > The intention was that the new charter would allow the group, as the focal point for QUIC-related things, to consider work such as multipath QUIC. The guidance for discussion of multipath is still the same as Lars' sent to the WG in November [1]. To borrow a bit of that, we still feel it premature to adopt an proposal as a work item. There's an interesting contrast between this point and your second point. It seems there's a balance between being specific and appearing not open to new ideas. > 2) +1 to Ian and Dmitri's comments about mentioning current examples in a > way that seems to preclude other extensions, we could remove the examples > to help clarify > (previously I commented as an individual, but now with a chair hat on) If 3 people have the same comment, it's likely a sign that some polishing up of the text would help. Specific suggestions always appreciated. > 3) I was surprised by "Extensions intended for Standards Track need to > have general applicability to multiple application protocols." and I don't > think our charter should preclude these. We shouldn't ban standard-track > protocols that require a QUIC extension to function properly. Perhaps > another way we could phrase this would be to say that "The QUIC WG is only > chartered to work on extensions that have general applicability to multiple > application protocols. Extensions that are specific to an application > protocol should be defined in the WG responsible for that protocol, in > consultation with the QUIC WG." -- without stating anything about Standards > track. > I'd like Lars or Magnus to respond to this point too. IIUC the intention of the text is to say that QUIC transport extensions that wish to be adopted by this group under Standards Track, should apply broadly. An extension designed for only one specific use, and which the authors do not wish to spend time considering design changes that would permit more-general usage, isn't a great use of the WGs time trying to standardise. However, the QUIC WG is a good venue to catalog such work as Informational or Experimental. I don't believe we want to prevent QUIC extensions that are specific to a use from being developed as Standards Track elsewhere in the IETF. > 4) It seems off to me to simultaneously declare HTTP/3 logging in-scope > and HTTP/3 out-of-scope. I think qlog is useful, but if we want to use it > outside of the QUIC transport protocol then maybe it should live in another > WG. > That's one (fair) interpretation. The intent here is to make it clear that the QUIC WG no longer owns the HTTP/3 application mapping, as always intended. qlog doesn't change protocols so working on that falls into the deployment working area. I expect a large part of the QUIC WG population, to start with, will be made up of deployers of HTTP/3. So while there has been some discussion on the most suitable home for qlog and splitting the drafts up [2], keeping them developed in a single WG would seem like the best way to channel effort and attention of active deployers. If others have a strong sense that is not the case they should speak up. > 5) "Maintenance and evolution of the QUIC base specifications" isn't very > clear to me - does that mean that working on future versions of QUIC is in > or out of scope? > The full paragraph states: " Maintenance and evolution of the QUIC base specifications that describe its invariants, core transport mechanisms, security and privacy, loss detection and recovery, congestion control, version and extension negotiation, etc. This includes the specification of new versions of QUIC, if necessary." I think that's clear but if you have some suggestions to improve it we'll take a look. Cheers, Lucas [1] - https://mailarchive.ietf.org/arch/msg/quic/rcPf7u9AHIGwNr6j0ZqrqFujVvk/ [2] - https://mailarchive.ietf.org/arch/msg/quic/yv9FFyXItsKK6m-5I5eRE6jnqR8/
- Rechartering QUIC for Post Version 1 Work Lucas Pardue
- Re: Rechartering QUIC for Post Version 1 Work Dmitri Tikhonov
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Dmitri Tikhonov
- Re: Rechartering QUIC for Post Version 1 Work Lucas Pardue
- Re: Rechartering QUIC for Post Version 1 Work Dmitri Tikhonov
- Re: Rechartering QUIC for Post Version 1 Work Ian Swett
- Re: Rechartering QUIC for Post Version 1 Work David Schinazi
- Re: Rechartering QUIC for Post Version 1 Work Lucas Pardue
- Re: Rechartering QUIC for Post Version 1 Work David Schinazi
- Re: Rechartering QUIC for Post Version 1 Work Matt Joras
- Re: Rechartering QUIC for Post Version 1 Work Roberto Peon
- Re: Rechartering QUIC for Post Version 1 Work Behcet Sarikaya
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Ian Swett
- Re: Rechartering QUIC for Post Version 1 Work David Schinazi
- Re: Rechartering QUIC for Post Version 1 Work Roberto Peon
- Re: Rechartering QUIC for Post Version 1 Work Spencer Dawkins at IETF
- Re: Rechartering QUIC for Post Version 1 Work Spencer Dawkins at IETF
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Magnus Westerlund
- Re: Rechartering QUIC for Post Version 1 Work Christian Huitema
- Re: Rechartering QUIC for Post Version 1 Work Roberto Peon
- Re: Rechartering QUIC for Post Version 1 Work Magnus Westerlund
- Re: Rechartering QUIC for Post Version 1 Work Sean Turner
- Re: Rechartering QUIC for Post Version 1 Work Behcet Sarikaya
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert
- Re: Rechartering QUIC for Post Version 1 Work Sean Turner
- Re: Rechartering QUIC for Post Version 1 Work Lars Eggert