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 21:35 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 346F212081F for <webtransport@ietfa.amsl.com>; Tue, 11 Feb 2020 13:35: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=ham 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 fy64YNuRO9Az for <webtransport@ietfa.amsl.com>; Tue, 11 Feb 2020 13:35:11 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 B26F212081E for <webtransport@ietf.org>; Tue, 11 Feb 2020 13:35:10 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id d10so13312202ljl.9 for <webtransport@ietf.org>; Tue, 11 Feb 2020 13:35:10 -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=QPcoxXEFSxN4o/jAAW5YO327scbwi7CXaSNZQtkVh68=; b=le5PmXskuNniirwReBjWZnn4tjMmKrCNC9wQNIcYarA+wMMIh3CthIGrLlHnDDk0tN mPHyiprpqCWut+X3S6/kaV6zJPRQWn5X2NeTcN27SimzyxWaIAtGwism9eaExFel8h3j 0PkTabvFcJq5BkAhujmzn8taRAGvPijMVq+c2LQd3EfUGZmkYXaXLBqIr1+3k8f+1L8A 5udCPJoHgQaBgie9OHVd5328qbXD1xhpkBHWl3ecj1ha2diPf+XzO6uS7AFrmVTSfHqS 1VvpaPGySdcH2bZXrXtshoEfnbGjAV34zbrLZcvW578l0Y9O+uiXVkht2JnAiQiuvv7M IWeg==
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=QPcoxXEFSxN4o/jAAW5YO327scbwi7CXaSNZQtkVh68=; b=bqwdlv7ju9oVahXJuvRljpwsAMJZGwce28X9xJkg5BUGZ3ft4OBeWzvj8ClLmOzN5G +GQ1GIVAOsf5KMuyZ4Ah7l1IUVFHRxOmnEpv4b59WxkKfDyia9Q3flROL0rT5Dq+0isM eznGJcIqyb9UnccW9iezFJkCglN85c25ufQV5RzrJXOw4I7MeES6nd4Mw/7E0/Xs5era 8IEk326c0J653VTji3HhYNZ5CQvV6W1LO/UBpbTpGjT1nFBjbSUjOpC/jOKp+5WVGFkW +WDXN/Cn9q8u+dshUaUXu2/xNfK53TnHTClCoYTg4Ogs056aeQ95gAgPM2Sp5Gq4vCze k6Pw==
X-Gm-Message-State: APjAAAX5oj61PZ4zKF/d9KrXkhuRrdOXxUdFIPIAzo0GqbO7MdCt8QZJ WtMfAcQ9DeZfFhxJBmFNIS+9Vid75KFy3eO0bcuu2w==
X-Google-Smtp-Source: APXvYqxj2ydTUqb42z/W4aWCjC195d9f/u4a/KeYOn1q14ZW+Y8LbgrqV4D0U1e680c2Y5v4DhEILup/Cva4AcwtfQU=
X-Received: by 2002:a05:651c:448:: with SMTP id g8mr5671919ljg.35.1581456908696; Tue, 11 Feb 2020 13:35:08 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+46DcCCN21M_MaGhi=_D_aEM5-HBrJ+4NvOazAQGmy2bw@mail.gmail.com> <EAE6E26A-CDA8-4D37-BA48-B9912F074C43@kuehlewind.net>
In-Reply-To: <EAE6E26A-CDA8-4D37-BA48-B9912F074C43@kuehlewind.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 11 Feb 2020 13:34:32 -0800
Message-ID: <CABcZeBMmSURmY92GHxDLE8hr+TTmA_Jsmzd5YGPC=9HLP0huOQ@mail.gmail.com>
To: "Mirja Kühlewind (IETF)" <ietf@kuehlewind.net>
Cc: David Schinazi <dschinazi.ietf@gmail.com>, Victor Vasiliev <vasilvv@google.com>, webtrans-chairs@ietf.org, WebTransport <webtransport@ietf.org>, The IESG <iesg@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000045556e059e53a159"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/TqJ8zrEDf3CEdpOdfpYuE5M3UsA>
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 21:35:14 -0000
On Tue, Feb 11, 2020 at 1:31 PM "Mirja Kühlewind (IETF)" < ietf@kuehlewind.net> wrote: > Hi David, > > I didn’t say that other groups cannot define extension. I did say that > it’s the decision of the working group that maintains the protocol how to > handle that and for Quic we didn’t have had that discussion yet. > > Examples for groups that explicitly define process for extending the > protocol in their charter are dhc and 6man. As you can see different > groups/protocols have different process and as we didn’t define anything > yet for Quic, the working assumption for now should be that all extension > work will be fine in the Quic group. > Well, the IANA considerations for QUIC transport seem fairly clear: https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4 Most of the code points are assigned via Specification Required, so I don't see why you would infer that all extensions happen within the QUIC WG. -Ekr > Mirja > > > Am 11.02.2020 um 21:47 schrieb David Schinazi <dschinazi.ietf@gmail.com>: > > > 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