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

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 12 February 2020 14:40 UTC

Return-Path: <ietf@kuehlewind.net>
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 1A21C12003E; Wed, 12 Feb 2020 06:40:31 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 fe2pxuib1JyM; Wed, 12 Feb 2020 06:40:27 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 9A98F12001E; Wed, 12 Feb 2020 06:40:27 -0800 (PST)
Received: from 200116b82c6541003dc68e626e80b0e7.dip.versatel-1u1.de ([2001:16b8:2c65:4100:3dc6:8e62:6e80:b0e7]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j1tBf-0000UJ-M9; Wed, 12 Feb 2020 15:40:23 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <CALaySJLYxSEcZVw8hzs1wAUKu2ysNMQ9x4Y14ATrkNRw-6eeLA@mail.gmail.com>
Date: Wed, 12 Feb 2020 15:40:22 +0100
Cc: Eric Rescorla <ekr@rtfm.com>, 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-Transfer-Encoding: quoted-printable
Message-Id: <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net>
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> <CABcZeBPvi9vH9e0wtD5fz3xoBPNE26px9sNAcFtvz_H-YEf3BQ@mail.gmail.com> <CALaySJLYxSEcZVw8hzs1wAUKu2ysNMQ9x4Y14ATrkNRw-6eeLA@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581518427;50f25ec8;
X-HE-SMSGID: 1j1tBf-0000UJ-M9
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/vKtG9nIY8RJ2rYGxD59JD56d6Gw>
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:40:31 -0000

The whole point is that the QUIC protocol is not finished yet and the respective registry doesn’t exists yet. All I’m saying that we should not bake process in the the webtransport charter that might restrict a future discuss we want to have in the QUIC group.



> On 12. Feb 2020, at 15:26, Barry Leiba <barryleiba@computer.org> wrote:
> 
> I have to agree with EKR here: I'm not aware of any other protocols
> that define Specification Required extension mechanisms where we say
> that the original working group should be in control of the
> extensions.  I wouldn't want to start it here.
> 
> The ADs will designate experts to review the extension specifications,
> and that is the mechanism for the working group to have its say in the
> extensions.  And in this case, the charter explicitly says that
> webtrans will coordinate with quic.  I see no reason to be more
> specific here, nor to require more.
> 
> Barry
> 
> On Wed, Feb 12, 2020 at 9:15 AM Eric Rescorla <ekr@rtfm.com> wrote:
>> 
>> 
>> 
>> 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
>>> 
> 
>