Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)
Eric Rescorla <ekr@rtfm.com> Tue, 11 February 2020 20:50 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: webtransport@ietfa.amsl.com
Delivered-To: webtransport@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6512006F for <webtransport@ietfa.amsl.com>; Tue, 11 Feb 2020 12:50:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 iNQZhSyTg0ew for <webtransport@ietfa.amsl.com>; Tue, 11 Feb 2020 12:50:09 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 0BFAA12083C for <webtransport@ietf.org>; Tue, 11 Feb 2020 12:50:09 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id q8so13217480ljb.2 for <webtransport@ietf.org>; Tue, 11 Feb 2020 12:50:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v6p+3blWCzAdZzmbqIlm/cdOO6sTXYpd3ltWjNAuoHU=; b=vBxYIwi/7ZhR3o6T/upYFGjsyjTH7kqkCpobKIwsutDVnKxmbOxpd9UHGTMqXR1jDG 1KQClnoIQHEd8dXAzn+PQWyR9681xDmqeSXCx5/D+4QMcO8xAZLIkeWvEDm5qCyZpg0F WGrYmEru1Y7439atSMQYK4zzjwozeZGIHs6yzspHNI8plZ6/xkptcSXFseCIeXgzwsky m2+bNEdEaLhEFhtPIEelmzUjsKF9E9u9/oNtKlaXoT6cU8gll3tBJ2svq9S8+NO7zV0X YJYfGSIhU10aawhHXwiecDkW8mUJNJsHy57YGM7mRrLUtP4UxVM2lP4gsvO9c9Beridv DTAg==
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=v6p+3blWCzAdZzmbqIlm/cdOO6sTXYpd3ltWjNAuoHU=; b=n/IDhTy4YMc7E0qm7HMbRcXFKy63a5RASt6ZYa5sx4g50eImtjlmxu5dzkulY/Mggu NgyTG5eip9MaEiSZdDhLCddlbO55Z1tWHBHQz9AHwPt/zItRVEsdtdikSEEjQEArq3xM cvDJD26iKvGOa7WW1sx3UngrdoAOGxQE3zWirSYomLD5BYkeI173QKZ847K6VgS7ZABk m9bcxIP8rf3NZ4r+uQU76hMTlajmzo8O2thLE7L06KfIBPSMFCpcxyu9gvVQYBsmZB3t m8Ocg2vtcwdwOUStLN0gbVTAK8HqFPj/yDPJCA3YinbjpkrEegDznjNkRiKfQj32iMv0 tTSQ==
X-Gm-Message-State: APjAAAXgTXJyX8X0mC8DWlmvIewIvydN/xP4RH3Qq8/en5tOC553lJ7m uUqejuhUewuAVJ60wGKxpWeNrjxhxyQFo3uvsJS48Q==
X-Google-Smtp-Source: APXvYqwfNN17TQ+AiDelpsEOoMy2quKHvH6KqoQEJbvStY49UcaAqtAGvWqe7/jrs5KlKKQ014X697mwhd6YKF6DLH8=
X-Received: by 2002:a2e:8797:: with SMTP id n23mr5157054lji.176.1581454207227; Tue, 11 Feb 2020 12:50:07 -0800 (PST)
MIME-Version: 1.0
References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> <CAAZdMae+RLZkFWA-HRO02HuU+SvM9XBPzJ1r4Er0A9MKZ-zopQ@mail.gmail.com> <CAPDSy+4MmpAsZa3cUstP5x_=GTYZXdgoindnK0STwgiMKQi5bQ@mail.gmail.com> <6737DF56-514D-48CB-8FEB-E0F6747578A6@kuehlewind.net> <CAPDSy+46DcCCN21M_MaGhi=_D_aEM5-HBrJ+4NvOazAQGmy2bw@mail.gmail.com>
In-Reply-To: <CAPDSy+46DcCCN21M_MaGhi=_D_aEM5-HBrJ+4NvOazAQGmy2bw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 11 Feb 2020 12:49:30 -0800
Message-ID: <CABcZeBPr6rZatnT+Ytw0=PRYWHGnSEG-KiHA6cNfZdvipKLD_A@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Mirja Kuehlewind <ietf@kuehlewind.net>, webtrans-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, WebTransport <webtransport@ietf.org>, The IESG <iesg@ietf.org>, Victor Vasiliev <vasilvv@google.com>
Content-Type: multipart/alternative; boundary="000000000000402e0f059e5300a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/M3s3Ls8qazpeGTqhYekmeUFFxp0>
Subject: Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)
X-BeenThere: webtransport@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <webtransport.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webtransport>, <mailto:webtransport-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webtransport/>
List-Post: <mailto:webtransport@ietf.org>
List-Help: <mailto:webtransport-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webtransport>, <mailto:webtransport-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2020 20:50:14 -0000
I basically agree with David. I might argue for a slightly higher level of implied coordination between the WGs than WGLC, but honestly given the large degree of overlap, I don't think we need to be that prescriptive. -Ekr On Tue, Feb 11, 2020 at 12:47 PM David Schinazi <dschinazi.ietf@gmail.com> wrote: > Hi Mirja, > > I'm not sure I agree with your interpretation. The fact that a WG is > responsible for a protocol does not mean that other working groups > cannot write extensions to that protocol. > > For example, the QUIC WG is defining the quic_transport_parameters > TLS extension. That extension is not defined in the TLS WG. > https://tools.ietf.org/html/draft-ietf-quic-tls-25#section-8.2 > > Similarly, the ACME WG is defining the Cert-Not-Before HTTP > header, not the HTTP WG. > https://tools.ietf.org/html/draft-ietf-acme-star-11#section-6.7 > > Additionally, MPTCP is an extension to TCP that was not > defined in the TCPM WG. The list goes on. > > We don't yet have examples for QUIC as the QUIC IANA > registries haven't been created yet, but I don't see why QUIC > would be different from TLS, HTTP, or TCP. > > David > > > On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind <ietf@kuehlewind.net> > wrote: > >> Hi David, >> >> One more comment below. >> >> > On 6. Feb 2020, at 14:46, David Schinazi <dschinazi.ietf@gmail.com> >> wrote: >> > >> > Hi Magnus, >> > >> > I realized that some of our earlier replies were accidentally not sent >> to >> > the IESG list, for which I apologize. >> > >> > To summarize that discussion: >> > >> > - It is not our intention to build a new transport protocol here. >> > The WEBTRANS WG would build application protocols that >> > run over QUIC, or TLS/TCP. This would ensure we benefit >> > from their security and congestion control properties. >> > Here is a PR to the charter that should clarify this: >> > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files >> > >> > - The WEBTRANS WG would not modify QUIC or HTTP. >> > Any discussion of modifying those core protocols would >> > happen in their existing respective working groups. >> > However, discussion of extensions to these protocols could >> > be allowed in this WG, as long as any document WGLC is >> > also sent to the mailing list responsible for that protocol. >> >> I think this is not sufficient, at least not for QUIC. More discussion is >> needed in the QUIC group on this but currently I think the assumption >> should be that all extensions will be done within the QUIC group. So just >> sending a WGLC there is not sufficient. >> >> More generally deciding on processes for other protocols/groups in this >> charter is not appropriate. I’m not sure what the defined process is for >> HTTP and TLS but that should be specified in their charter and not here. >> >> For QUIC, I would like to rather see that extension or modification are >> out of scope for this group. Of course that doesn’t mean that this group >> cannot talk about any extension but as soon as the group thinks an >> extension is needed, it needs to go to the QUIC group and cannot just adapt >> anything within WebTransport. >> >> Please also double-check what the right process is for TLS and HTTP. I >> assume for TLS it's the same but for HTTP it might be different…? >> >> Mirja >> >> >> >> > >> > Would that be an acceptable scope? >> > >> > Thanks, >> > David >> > >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev <vasilvv@google.com> >> wrote: >> > I believe most of those have been addressed in David's PR, so I'll try >> to reply >> > primarily to those that I have something to add to. >> > >> > On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker < >> noreply@ietf.org> wrote: >> > Magnus Westerlund has entered the following ballot position for >> > charter-ietf-webtrans-00-00: Block >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > BLOCK: >> > ---------------------------------------------------------------------- >> > >> > >> > [snip] >> > >> > The group will also coordinate with related working groups within the >> IETF, >> > such as QUIC and HTTPBIS, as appropriate. >> > >> > With the current state of QUIC developement and HTTP/3 mapping >> definition, i.e. >> > still working on the initial version, I would like to have a more firm >> wording >> > that the WebTrans WG will actually have to take any requests for >> extensions of >> > HTTP/3 and QUIC to the relevant WG. >> > >> > While there are no extensions to QUIC among the proposed WG documents, >> some of >> > the drafts do extend HTTP using custom SETTINGS parameters (which is the >> > intended HTTP extensibility mechanism). I've hitherto assumed that >> webtrans >> > would work with HTTP experts in httpbis/quic to ensure that the proposed >> > extensions are architecturally sound and follow best practices, but the >> main >> > bulk of work would be done in the new working group itself. >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I also would appreciate if someone can clarify what stage of formality >> the >> > Web-Transport API has been adopted in W3C and is being worked on. >> Trying to >> > find anything about which group it belongs to on the W3C page didn't >> give me >> > any information. All I found is that there have been a workshop on game >> > communication where this was discussed and raised in some discussions. >> > >> > It's a WICG draft, which basically means no formal status. We had a >> discussion >> > session at TPAC last year, and I believe most people who'd be normally >> involved >> > are aware of it, but my current understanding is that the editors of >> the W3C >> > spec currently do not believe we have enough real-world implementation >> > experience with the proposal to advance it further in the formal >> process. >> > >> > Having lived through the WebRTC / RTCWeb interactions it would good to >> know >> > more how the interaction between the bodies are intended to work. >> Especially as >> > changes to the API can have significant impact on what work needs to >> happen in >> > the IETF. >> > >> > I mostly agree with Bernard here. My plan was that the -overview doc >> would >> > list all of the protocol requirements and API expectations, acting as >> > integration point between W3C and IETF specs. >> > >> > The current API draft does not include any discussion of priority. >> However >> > draft-vvv-webtrans-overview does mention priorities. As this API >> appears to >> > support multiple parallel transmissions and transfers I think at a >> minimal a >> > sender transport protocol scheduling or HTTP/3 priority would be >> likely to be >> > part of the work. I also have to ask if this is likely to attempted to >> be >> > mapped also towards the network level, for example DSCPs? If any such >> work is >> > expected and intended I think that needs to be raised. Otherwise I >> would assume >> > that at most what this work will be to use the undefined APIs to HTTP/3 >> and >> > QUIC to influence those protocol to perform stream priorities. >> > >> > This is mostly a gap in the API spec. I've been meaning to write this >> up >> > further, but there's a lot of text to write. >> > >> > Before I elaborate further, I would like to point out that there are >> two types >> > of priorities here, and those are often confused: >> > (1) Priorities that the application indicates to the transport layer >> for the >> > purpose of scheduling writes. >> > (2) Priorities that are communicated to the peer on the wire as a hint.. >> > >> > Most of the discussion in HTTPBIS and QUIC WGs was about #2. I don't >> believe >> > any of the proposed drafts cover that topic, and I'd rather wait for >> > quic/httpbis to come up with a mechanism first. >> > >> > The priorities mentioned in -overview are of the #1 kind. Section 2.3 >> of >> > draft-ietf-quic-transport-25 explicitly encourages implementations >> (that would >> > include the proposed Web APIs) to provide those: >> > >> > """ >> > [QUIC] relies on receiving priority information from the application >> that uses >> > QUIC. >> > >> > A QUIC implementation SHOULD provide ways in which an application can >> indicate >> > the relative priority of streams. When deciding which streams to >> dedicate >> > resources to, the implementation SHOULD use the information provided by >> the >> > application. >> > """ >> > >> > Besides, I don't believe we can avoid defining a write scheduling >> mechanism in >> > the API. QUIC itself treats it as an implementation detail, but Web >> APIs >> > generally try really hard to avoid implementation-defined behavior. If >> > every browser had a completely different write scheduling approach, >> > that could make the job of writing performant cross-browser code really >> > difficult. >> > >> > Thanks, >> > Victor. >> > -- >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >> >> -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport >
- [Webtransport] Magnus Westerlund's Block on chart… Magnus Westerlund via Datatracker
- Re: [Webtransport] Magnus Westerlund's Block on c… Ted Hardie
- [Webtransport] Fwd: Magnus Westerlund's Block on … Bernard Aboba
- Re: [Webtransport] Fwd: Magnus Westerlund's Block… Martin Thomson
- Re: [Webtransport] Fwd: Magnus Westerlund's Block… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Fwd: Magnus Westerlund's Block… Magnus Westerlund
- Re: [Webtransport] Magnus Westerlund's Block on c… Magnus Westerlund
- Re: [Webtransport] Magnus Westerlund's Block on c… Victor Vasiliev
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kühlewind (IETF)
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… David Schinazi
- Re: [Webtransport] Magnus Westerlund's Block on c… Barry Leiba
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Barry Leiba
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla
- Re: [Webtransport] Magnus Westerlund's Block on c… Mirja Kuehlewind
- Re: [Webtransport] Magnus Westerlund's Block on c… Rob Wilton (rwilton)
- Re: [Webtransport] Magnus Westerlund's Block on c… Eric Rescorla