Re: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 12 February 2020 14:15 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 079F31200FB for <webtransport@ietfa.amsl.com>; Wed, 12 Feb 2020 06:15:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, URIBL_BLOCKED=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 M6ftmwF-es1W for <webtransport@ietfa.amsl.com>; Wed, 12 Feb 2020 06:15:23 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (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 1A03E12001E for <webtransport@ietf.org>; Wed, 12 Feb 2020 06:15:23 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id v17so2502149ljg.4 for <webtransport@ietf.org>; Wed, 12 Feb 2020 06:15:23 -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=K+S6LaidPLnBIXjExw5ERf67LsH+Anb3Jt8ZTBtvHtI=; b=CzwbMNjMVqYtu1xEs3RtNIakp0pjEa01n38gNO6PpBzC3ObV3tT7wqDwbbxCFpY0jt pD+bUlPBfN/Ei5WKzwJTO7YpNWAr5SCl81ScL6HwFwLd5rd4yTdX3cyqlKTofqqmu1kq xt+Tl3DT/YZUKLfWFdLB7vquC65Nlab7EURMLeLdYPgJSmmql0uYxPAdUvfcOl99aY2C WrFbyiWOruqEtk8rsOQGGXR9cFcBVp7eruMRLfnHP9NcLyVCUdDhdEtqH+JiVj3SU+R+ aa70AJAEMYubBXSlaWzhYmQGbcZnUxtqsglA7pVbJsIrq3DFSsS1SwvhFaUinYRQfI4W a7jg==
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=K+S6LaidPLnBIXjExw5ERf67LsH+Anb3Jt8ZTBtvHtI=; b=dhCcRwRjrme+XsiX3aoMrnWPmkp9u2HLvd71EbiMjDzxCTBl1Y4clx4J1FDb7TFsRQ EmHDuWqmhPXxFUyvjolcTj1TrDGkh53EF7HIwOY/p/uMPG3Zp9jNri6tpIoV/dAbaQFW B8oCwPodWx5ahmBdS9mb524exlz5E0KDWIQXQ03COOtKxvDfJwOUynzflVXXnMUsXzUj ScQgSLsU3LrOucgjK5gofLbMZngWpGf5492Y35Vpc5I8YdSaAjAiptxwQaaGjCH3hKwM EHy+t2ryN83GWkupNLGtnUQiJQ8z+IFzytAtmOAayUhrgdV0Ka2795uou0qR0bJnSZOY PYKw==
X-Gm-Message-State: APjAAAUvBj6350UB7bHR8YFh/4AEnLIW4LnMhHzEt2vJdU6y+/cYU/kf Mu9EBLds8MHy8exPMYIHNEie+PGoQlFPVN7BrW83lQ==
X-Google-Smtp-Source: APXvYqzicqoxVQ/pSNSTBgmFWtDgzMIYB1vNnQA0N7jgYVZGzfaPZ/hBigKrLWKuBFmSg8YLB/U0ZYA/ZtLQCT79jjs=
X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr7746334ljn.162.1581516921280; Wed, 12 Feb 2020 06:15:21 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+46DcCCN21M_MaGhi=_D_aEM5-HBrJ+4NvOazAQGmy2bw@mail.gmail.com> <EAE6E26A-CDA8-4D37-BA48-B9912F074C43@kuehlewind.net> <CABcZeBMmSURmY92GHxDLE8hr+TTmA_Jsmzd5YGPC=9HLP0huOQ@mail.gmail.com> <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net>
In-Reply-To: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 12 Feb 2020 06:14:44 -0800
Message-ID: <CABcZeBPvi9vH9e0wtD5fz3xoBPNE26px9sNAcFtvz_H-YEf3BQ@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, webtrans-chairs@ietf.org, WebTransport <webtransport@ietf.org>, The IESG <iesg@ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>, Victor Vasiliev <vasilvv@google.com>
Content-Type: multipart/alternative; boundary="0000000000004cb516059e619ac8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/AMpm8NoRYNNW_w8KBsRKEvpcHzU>
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: Wed, 12 Feb 2020 14:15:27 -0000

On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind <ietf@kuehlewind.net>
wrote:

> Hi Ekr,
>
> Yes, it is specification required, however, if we decide to pushing an RFC
> then we need to decide where this work in the IETF can be don best.
>

This seems like a very odd position. As soon as the QUIC RFC is published,
anyone else in the world can assign new QUIC code points, but inside the
IETF, until there;s some discussion in the QUIC there won't be any process
other than asking the QUIC WG?



> All I’m saying that the process how and where to define QUIC extensions in
> the IETF needs to be decided by the QUIC group and a future QUIC charter
> and not by the charter of any other working group.


I don't understand what process you think requires this. There was never
any such formal discussion in the TLS WG AFAIK. In my experience when some
WG wants to define a TLS extension there's a brief discussion between the
chairs and ADs about whether it's orthogonal enough to do separately. It's
not in the TLS charter, for instance, AFAICT.

-Ekr

Again that doesn’t mean that in future it will not be possible for other
> groups to define extension but we need to have that discussion first.
>
> Mirja
>
>
>
> > On 11. Feb 2020, at 22:34, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > 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
>
>