From nobody Sat Feb 1 11:53:50 2020 Return-Path: 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 614D9120125; Sat, 1 Feb 2020 11:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=TzcPfelg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m8fvWBJb 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 SHcozFmYQMBx; Sat, 1 Feb 2020 11:53:47 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8D212007C; Sat, 1 Feb 2020 11:53:46 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DB31421FB7; Sat, 1 Feb 2020 14:53:45 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sat, 01 Feb 2020 14:53:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=U+n3cNJBspeo4RviE3L3u39h9xWk SoeuCFC932akkLg=; b=TzcPfelg1SvHcb8ThTSEiX42QTnbSFD8LlEh9ZFG14f+ foGsbE3AAWTLD1G4U+eLoljsn6GSnpYdcOGAXYfT9Z8JhJOcNbUA6hzsU6tbb7Ws szlO1/z7SptQkwwX0ps9MPbgWIp/1zdWAYruSP35dYY5Ot03939/USJU+P0MHw1e 4atdRZCSZo497UYfiJuD5pUKwEIeBDuDpjQPeWhgNt+Zq4cFbmjBwa8tkFnNZ3E9 hEwG1tXAzHepq0EDigrl4fmn3MKgT4s9Kky1pWs9ZgziPOcWWEXJEzHhVX58za6b c4+dYBu61bvuNc4ZsnN4GWSUap9MEZmZpqGidhk4hQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=U+n3cN JBspeo4RviE3L3u39h9xWkSoeuCFC932akkLg=; b=m8fvWBJbalrG03kSXQWzvF /WuVX8xhhMnufT7VK+oxr27LvMpK0RV7VixT1maPKn8ovCJ+dcd7hyprA0RPNsSn u27KnVSKjm7B2OfMim8AImwmGeE2hyxrUYlFVPmliOxh0XYRF/sYJHR4Kn1Ruvbc aDBIWl/yJ/VUJnf1Brr66foR56+9d/amvz2HPGWuifcTP7mYCNKW5UHO0OEGM6YC yvPo/IjExa/iVDsCt0XuEwmZm5aTVHc+yT9gvuOlSOYHxUg198qyAUzMw/ADG7Fk smIGE2p8SPxQdqFmqJp5BadTaGCJta+2p9jm3otUOzFdWfCDon3j0UHjVVC5lFLw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrgedvgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5DAA9E00A2; Sat, 1 Feb 2020 14:53:45 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-781-gfc16016-fmstable-20200127v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> Date: Sat, 01 Feb 2020 20:53:25 +0100 From: "Martin Thomson" To: "Bernard Aboba" , "Magnus Westerlund" , webtransport@ietf.org Cc: webtrans-chairs@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Webtransport] =?utf-8?q?Fwd=3A_Magnus_Westerlund=27s_Block_on_c?= =?utf-8?q?harter-ietf-webtrans-00-00=3A_=28with_BLOCK_and_COMMENT=29?= X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2020 19:53:48 -0000 On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > [BA] Would it be sufficient to add this clarification to the existing > sentence? The result would look like this. > > The WebTransport working group will define new client-server protocols > or protocol extensions using QUIC or HTTP3 in order to support the I would instead say "building on existing protocol work" and then point out separately that this will definitely not define a new transport (or lower) layer protocol. At Mozilla we are still uncertain about the set of protocols as currently proposed, and would feel uncomfortable limiting this to just those two *in the charter*. From nobody Mon Feb 3 02:24:12 2020 Return-Path: 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 AD4D2120917 for ; Mon, 3 Feb 2020 02:24:10 -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 tojEZ47UxoeV for ; Mon, 3 Feb 2020 02:24:08 -0800 (PST) Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) (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 CA3561200F7 for ; Mon, 3 Feb 2020 02:24:07 -0800 (PST) Received: by mail-lj1-x243.google.com with SMTP id o15so8455802ljg.6 for ; Mon, 03 Feb 2020 02:24:07 -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=Shzqke5Ts+RVD9bz6LFP4XXgFUBv6/gq7Tx9doRxCRM=; b=XqCQQdECjosKiE5KZcN4BrASQSgz7svcSVWuMBUwDUsk2einIxOyAyaC5Y1ZOy/P57 szGdgbRVZmDByuDvdcjnAq8tHJ1gQuGt7Q/2mHq1WKJwMbR/cb02H02CSR/q0HJrgUxn 05e3Iw/cd1KgjoSxZwCsNA5zY34zQShUnQFYymn49SDJELOu2jHRr2RJrw+UpSj+VQL3 kC2pnpvl8FbeGBv7+BLPgqPXlcWKhsYEtD7Q67fQ6ZdES7h/W6AsSvYR7O6Q6geDKHX8 Drqm3pM4vSzt1QtXKStRusxfywIjj0C9T9ksGvYo++zppkHQsumL6PhWNrAMoAObzwJa S03A== 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=Shzqke5Ts+RVD9bz6LFP4XXgFUBv6/gq7Tx9doRxCRM=; b=g4YQeyr9fG8c5UFunaaqLwdWMfLp6TZ63mXXZzl4iL9bre5r++eGqTFWCff+C5LQBa Orhy4bCiogk85HOshSWC4MO7rw3CNg/K8x1AE+8ooUQYuCkHifmTtK93or6xKjfH72ar VsONBUQ/Bpb259BNJwMluNX5vEcjWZ4kyeqVVdlou+PQTLA7gHw8hVOkQ1nfO+QSkXBX 6rk7PeORTSJ0fUvSyqTaFsvSUuIl9BKxnRo0Ff8zukykSWLMauDgtPBIYNyahaGmrGi/ 7yQTDPsh7yEt4g8rX8QZ8jR0X76NnLS6sj0U+t6C1iRAJvjx6xIxnXBp26RGfX45X8iC VPvg== X-Gm-Message-State: APjAAAVyuir4kkR+pHBAycbwbZiG0HtzLNwaAm1SNIpzmeKo6xueSVBt /vgOrlRbfGA9x+bnOB2Aq2eX4KQqUg04ZnYutNY1cg== X-Google-Smtp-Source: APXvYqyzGmdwQmlBfkq8EhWRzlxrNf1i+Cr0QxZQLbVs7WyxA8S6Eo51BaoG4dYKWaOYkinSXmYh9eftdq80hwhHVNY= X-Received: by 2002:a2e:90f:: with SMTP id 15mr12983342ljj.120.1580725446107; Mon, 03 Feb 2020 02:24:06 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Mon, 3 Feb 2020 02:23:29 -0800 Message-ID: To: Martin Thomson Cc: Bernard Aboba , Magnus Westerlund , webtransport@ietf.org, webtrans-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000b3f71f059da952b6" Archived-At: Subject: Re: [Webtransport] Fwd: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:24:11 -0000 --000000000000b3f71f059da952b6 Content-Type: text/plain; charset="UTF-8" As MT says, I would not be comfortable if the charter defined the specific protocol starting points, given the uncertainty about exactly which pieces we will do. -Ekr On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson wrote: > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > [BA] Would it be sufficient to add this clarification to the existing > > sentence? The result would look like this. > > > > The WebTransport working group will define new client-server protocols > > or protocol extensions using QUIC or HTTP3 in order to support the > > I would instead say "building on existing protocol work" and then point > out separately that this will definitely not define a new transport (or > lower) layer protocol. > > At Mozilla we are still uncertain about the set of protocols as currently > proposed, and would feel uncomfortable limiting this to just those two *in > the charter*. > > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --000000000000b3f71f059da952b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As MT says, I would not be comfortable if the charter= defined the specific protocol starting points, given the uncertainty about= exactly which pieces we will do.

-Ekr


On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net> wrote:
On Sat, Feb 1, 2020, at 04:09, Bernard= Aboba wrote:
> [BA] Would it be sufficient to add this clarification to the existing =
> sentence? The result would look like this.
>
> The WebTransport working group will define new client-server protocols=
> or protocol extensions using QUIC or HTTP3 in order to support the
I would instead say "building on existing protocol work" and then= point out separately that this will definitely not define a new transport = (or lower) layer protocol.

At Mozilla we are still uncertain about the set of protocols as currently p= roposed, and would feel uncomfortable limiting this to just those two *in t= he charter*.

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000b3f71f059da952b6-- From nobody Mon Feb 3 02:42:14 2020 Return-Path: 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 32700120048; Mon, 3 Feb 2020 02:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 doWOJhb7_3Xn; Mon, 3 Feb 2020 02:42:11 -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 1E532120046; Mon, 3 Feb 2020 02:42:10 -0800 (PST) Received: from [2a00:79e1:abc:301:58f1:e777:f42a:c01e]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iyZBA-0003UF-T6; Mon, 03 Feb 2020 11:42:08 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 3 Feb 2020 11:42:07 +0100 Cc: Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , webtransport@ietf.org, Bernard Aboba Content-Transfer-Encoding: quoted-printable Message-Id: References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580726531;4e631e0e; X-HE-SMSGID: 1iyZBA-0003UF-T6 Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:42:13 -0000 Hi Ekr, hi Martin, I thought that building something on top of QUIC or H3 are preconditions = for any solution. If that is the case I would also prefer to put this in = the charter (to exclude it clearly from the scope of this group to = rebuild a new QUIC or a new version of quic or something like that which = should be done in the quic group; similar for http which should be done = in the httpbis in future). If you think that is somehow too restrictive = what are the option open, you would want to work on in this new group? Mirja > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: >=20 > As MT says, I would not be comfortable if the charter defined the = specific protocol starting points, given the uncertainty about exactly = which pieces we will do. >=20 > -Ekr >=20 >=20 > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson = wrote: > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > [BA] Would it be sufficient to add this clarification to the = existing=20 > > sentence? The result would look like this. > >=20 > > The WebTransport working group will define new client-server = protocols=20 > > or protocol extensions using QUIC or HTTP3 in order to support the=20= >=20 > I would instead say "building on existing protocol work" and then = point out separately that this will definitely not define a new = transport (or lower) layer protocol. >=20 > At Mozilla we are still uncertain about the set of protocols as = currently proposed, and would feel uncomfortable limiting this to just = those two *in the charter*. >=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Mon Feb 3 02:45:30 2020 Return-Path: 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 ED0831200F7 for ; Mon, 3 Feb 2020 02:45:28 -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 qdbDgudUrzea for ; Mon, 3 Feb 2020 02:45:26 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 77853120046 for ; Mon, 3 Feb 2020 02:45:26 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id r19so14093546ljg.3 for ; Mon, 03 Feb 2020 02:45:26 -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=RLksq+0sS39jzToIofxzeaCtnbfZalrXzYUIS7bDFQ8=; b=hZC6ZYs/4hN+zdfpZS90uLCNp11wm7BC/zhYU0Wuc7d6FtNihM4kKasJGKxGDO6nGy O7Lcy48Qn4jvzzfNBobUoGhCEnuu7E0vGzUwy2I5IagLDGj7OAAyz0oYq6NxSBTOulwU 3rzvQuMB+UKxL3/zUFsXjuoyaRRAHdJ9u/QMbqRHq1iFgZogtz3YnBhB9B7s0c8PVSjR 0FWOvaJTmfNUd4usIA8HLNeujS5xjYlmWL8+xh3XloH77czZgzvmyXBUwuubnF8iD3dU ql+YRHdqH1HzD5wpOYkWaJ+vGLZx5L+6Y9yLC14NefXCbc7gCHtzC0lCPtJxlcC1XC/j iyig== 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=RLksq+0sS39jzToIofxzeaCtnbfZalrXzYUIS7bDFQ8=; b=V6iti5DKCZwYUyqlWwpfvt241LLaWygxiyxmc3ankLlBXg2jVggAgO+pg2YE4PaH25 g8ReJQ5m9LGVX1WEGSAMSyW0tZ4339CzNa3PBVCNp1B2hDx5MAjWPsWh0wXPUz8Tnecc GtVnUc7iA7uaVEMMt5lZ7RwMgNnJ1Ix8cDgUP7FCwU86tOVyoPFKHqTY4KXtOtgHUjvl ZjNCj8m3TgCPiOatwJcGF0DnCLGKkxKdsWVBmQ9FPX38aGvHTAavb2BBVfys3x7SAJZr ygxgnJY7tlJUp0h4/h4xlW0ntLExdV/XQbU6yXHFn10Z0mOgn4ZOyl0A6FnGtFjANO56 1PEQ== X-Gm-Message-State: APjAAAWxEopykb92Ql2MebfKkdDODfH37tVOSNTD/w58oADgWqPxvmLy 9kQzLvzCYvZSdbfMcjH7lXdYQ+eXrrkzHxiAgmn7zh0c7F0= X-Google-Smtp-Source: APXvYqwxzoQxp+aoDKFvRUxcHMV54rrEtuLHZT7iATZKng25MFEWyIHZN9Gg/nFC7wVKgi7mPqXHGOJwuOMz+BfaGVk= X-Received: by 2002:a2e:90f:: with SMTP id 15mr13033036ljj.120.1580726724636; Mon, 03 Feb 2020 02:45:24 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Mon, 3 Feb 2020 02:44:48 -0800 Message-ID: To: Mirja Kuehlewind Cc: Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , webtransport@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="000000000000e8e526059da99efe" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:45:29 -0000 --000000000000e8e526059da99efe Content-Type: text/plain; charset="UTF-8" Well, I certainly don't think we should build a new version of QUIC, and it seems likely that QUIC will be involved somehow, but Victor had some quite specific protocol suggestions which might or might not be what we want. In addition we need to ensure that there's some parity via a TCP-based mechanism. -Ekr On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind wrote: > Hi Ekr, hi Martin, > > I thought that building something on top of QUIC or H3 are preconditions > for any solution. If that is the case I would also prefer to put this in > the charter (to exclude it clearly from the scope of this group to rebuild > a new QUIC or a new version of quic or something like that which should be > done in the quic group; similar for http which should be done in the > httpbis in future). If you think that is somehow too restrictive what are > the option open, you would want to work on in this new group? > > Mirja > > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > > > As MT says, I would not be comfortable if the charter defined the > specific protocol starting points, given the uncertainty about exactly > which pieces we will do. > > > > -Ekr > > > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson > wrote: > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > [BA] Would it be sufficient to add this clarification to the existing > > > sentence? The result would look like this. > > > > > > The WebTransport working group will define new client-server protocols > > > or protocol extensions using QUIC or HTTP3 in order to support the > > > > I would instead say "building on existing protocol work" and then point > out separately that this will definitely not define a new transport (or > lower) layer protocol. > > > > At Mozilla we are still uncertain about the set of protocols as > currently proposed, and would feel uncomfortable limiting this to just > those two *in the charter*. > > > > -- > > 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 > > --000000000000e8e526059da99efe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, I certainly don't think we should build a n= ew version of QUIC, and it seems likely that QUIC will be involved somehow,= but Victor had some quite specific protocol suggestions which might or mig= ht not be what we want. In addition we need to ensure that there's some= parity via a TCP-based mechanism.

-Ekr
<= div>


On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
Hi Ekr, hi Martin,

I thought that building something on top of QUIC or H3 are preconditions fo= r any solution. If that is the case I would also prefer to put this in the = charter (to exclude it clearly from the scope of this group to rebuild a ne= w QUIC or a new version of quic or something like that which should be done= in the quic group; similar for http which should be done in the httpbis in= future). If you think that is somehow too restrictive what are the option = open, you would want to work on in this new group?

Mirja



> On 3. Feb 2020, at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
>
> As MT says, I would not be comfortable if the charter defined the spec= ific protocol starting points, given the uncertainty about exactly which pi= eces we will do.
>
> -Ekr
>
>
> On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net> wrote:
> On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
> > [BA] Would it be sufficient to add this clarification to the exis= ting
> > sentence? The result would look like this.
> >
> > The WebTransport working group will define new client-server prot= ocols
> > or protocol extensions using QUIC or HTTP3 in order to support th= e
>
> I would instead say "building on existing protocol work" and= then point out separately that this will definitely not define a new trans= port (or lower) layer protocol.
>
> At Mozilla we are still uncertain about the set of protocols as curren= tly proposed, and would feel uncomfortable limiting this to just those two = *in the charter*.
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--000000000000e8e526059da99efe-- From nobody Mon Feb 3 02:52:58 2020 Return-Path: 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 B9CD412009E; Mon, 3 Feb 2020 02:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 eym6NwziNvyU; Mon, 3 Feb 2020 02:52:54 -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 846CF120096; Mon, 3 Feb 2020 02:52:54 -0800 (PST) Received: from [2a00:79e1:abc:301:58f1:e777:f42a:c01e]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iyZLY-00068B-OS; Mon, 03 Feb 2020 11:52:52 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 3 Feb 2020 11:52:52 +0100 Cc: Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , webtransport@ietf.org, Bernard Aboba Content-Transfer-Encoding: quoted-printable Message-Id: References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580727174;e27da53b; X-HE-SMSGID: 1iyZLY-00068B-OS Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:52:57 -0000 Yes, totally understood that you don=E2=80=99t want to put any specific = protocol suggestions in the charter but right now it seem a bit too = loose (from a transport point of view). So if you don=E2=80=99t want = what is proposed currently, do you have another proposal?=20 If you are working on a draft yourself, I think it would actually be = nice to have a first version of this draft out before the groups is = fully started to people discussion the charter right now, would actually = better understand what the discussion is about. Mirja > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: >=20 > Well, I certainly don't think we should build a new version of QUIC, = and it seems likely that QUIC will be involved somehow, but Victor had = some quite specific protocol suggestions which might or might not be = what we want. In addition we need to ensure that there's some parity via = a TCP-based mechanism. >=20 > -Ekr >=20 >=20 >=20 > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind = wrote: > Hi Ekr, hi Martin, >=20 > I thought that building something on top of QUIC or H3 are = preconditions for any solution. If that is the case I would also prefer = to put this in the charter (to exclude it clearly from the scope of this = group to rebuild a new QUIC or a new version of quic or something like = that which should be done in the quic group; similar for http which = should be done in the httpbis in future). If you think that is somehow = too restrictive what are the option open, you would want to work on in = this new group? >=20 > Mirja >=20 >=20 >=20 > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > >=20 > > As MT says, I would not be comfortable if the charter defined the = specific protocol starting points, given the uncertainty about exactly = which pieces we will do. > >=20 > > -Ekr > >=20 > >=20 > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson = wrote: > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > [BA] Would it be sufficient to add this clarification to the = existing=20 > > > sentence? The result would look like this. > > >=20 > > > The WebTransport working group will define new client-server = protocols=20 > > > or protocol extensions using QUIC or HTTP3 in order to support the=20= > >=20 > > I would instead say "building on existing protocol work" and then = point out separately that this will definitely not define a new = transport (or lower) layer protocol. > >=20 > > At Mozilla we are still uncertain about the set of protocols as = currently proposed, and would feel uncomfortable limiting this to just = those two *in the charter*. > >=20 > > --=20 > > Webtransport mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > --=20 > > Webtransport mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport >=20 From nobody Mon Feb 3 02:56:16 2020 Return-Path: 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 2FF3D120916 for ; Mon, 3 Feb 2020 02:56: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 Gd-7CHU7jIyO for ; Mon, 3 Feb 2020 02:56:12 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 D419912008C for ; Mon, 3 Feb 2020 02:56:11 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id 9so9338552lfq.10 for ; Mon, 03 Feb 2020 02:56:11 -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=ErdpTet6PmGCb7rOExdouKX5luqG9z0pv5lKdsps7zE=; b=wf2SBnY8cSNd0XElEL2HmNDtP37AxEWMMVL9UZTUBruUBuvTPy7760MJ7xqhEFGZeF U77wm/aSnFAOeBqwyV7vog50urGQcBIDBkdbMmrRp4W8rFx2LH76cDvsKZvOxXCBTg+u G1x9kKEr82X53EKZIRUTBH9NVDxDwUA/YvOVw89XoK1D58/eDoebod0Ca7Bz3EzKJ36Q Hc8453YnuQG5lZGnHLhhIuFaamWkEo9InTGPWY3LMFqd6sSan5ceyZdkUqI6hxsdkIIp dAiCmQ4np8G8/OR/QM7M9ztslruGS8aHwVKBoc1HEb9zjZuXE4mJSGDl0vSD2Dvgvgyv OUmQ== 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=ErdpTet6PmGCb7rOExdouKX5luqG9z0pv5lKdsps7zE=; b=TKNCBkKoVik1b+i3di1T3ZW2b1KWb5o5M9lJj1t1GuLoiChTxt4gHP4EDsGrHGEipJ pkoOWZtEV8PaDENXB9+9f0UDmwQlSQzrkhFp8TLUXlAMufEnRTnz4HYXDwLDTEg7km1L 1N3aHSSoQLaF+qgpJuw6od4HC8NF4wj1IMzB3X6ciBpuvUP0M/YtMA6Iy7MCLv5t5TJj CZzMaFas8F5ClhAtHSUMTD7+3td11dScRIP1uCOcdyL2Pfz2JYlLJA0iLPbIuNJY0EHa 6vrCVZzx8FrCsdjh1UXM1r/ahp8i3lt6HuDIknc44btj7H4osGw7OmHvux/FbrEmaEJM nkpA== X-Gm-Message-State: APjAAAUGDED0UrNb+J+bDViYjB6HNgQWWaFPPWz2JR5F0pZ1c3f84dZk PuOfFi0kAw4sjMeu2ox+hjO6KkF41Zior8JnkhLlMQ== X-Google-Smtp-Source: APXvYqy+2ezIGK4l4faaS7P7lch/muk7uhFZIHgxNiLwCyroQV7BZIQ2n/hvmP1ziDqpFU2VslRWznA+Y0rNRdJxowE= X-Received: by 2002:a05:6512:64:: with SMTP id i4mr11659823lfo.55.1580727370113; Mon, 03 Feb 2020 02:56:10 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Mon, 3 Feb 2020 02:55:33 -0800 Message-ID: To: Mirja Kuehlewind Cc: Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , webtransport@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="00000000000061f934059da9c5b0" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:56:14 -0000 --00000000000061f934059da9c5b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind wrote= : > Yes, totally understood that you don=E2=80=99t want to put any specific p= rotocol > suggestions in the charter but right now it seem a bit too loose (from a > transport point of view). So if you don=E2=80=99t want what is proposed c= urrently, > do you have another proposal? > I'm fine with the current text. I'm arguing against the attempts to aggressively narrow it. -Ekr If you are working on a draft yourself, I think it would actually be nice > to have a first version of this draft out before the groups is fully > started to people discussion the charter right now, would actually better > understand what the discussion is about. > > Mirja > > > > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: > > > > Well, I certainly don't think we should build a new version of QUIC, an= d > it seems likely that QUIC will be involved somehow, but Victor had some > quite specific protocol suggestions which might or might not be what we > want. In addition we need to ensure that there's some parity via a > TCP-based mechanism. > > > > -Ekr > > > > > > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind > wrote: > > Hi Ekr, hi Martin, > > > > I thought that building something on top of QUIC or H3 are precondition= s > for any solution. If that is the case I would also prefer to put this in > the charter (to exclude it clearly from the scope of this group to rebuil= d > a new QUIC or a new version of quic or something like that which should b= e > done in the quic group; similar for http which should be done in the > httpbis in future). If you think that is somehow too restrictive what are > the option open, you would want to work on in this new group? > > > > Mirja > > > > > > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > > > > > As MT says, I would not be comfortable if the charter defined the > specific protocol starting points, given the uncertainty about exactly > which pieces we will do. > > > > > > -Ekr > > > > > > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson > wrote: > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > > [BA] Would it be sufficient to add this clarification to the > existing > > > > sentence? The result would look like this. > > > > > > > > The WebTransport working group will define new client-server > protocols > > > > or protocol extensions using QUIC or HTTP3 in order to support the > > > > > > I would instead say "building on existing protocol work" and then > point out separately that this will definitely not define a new transport > (or lower) layer protocol. > > > > > > At Mozilla we are still uncertain about the set of protocols as > currently proposed, and would feel uncomfortable limiting this to just > those two *in the charter*. > > > > > > -- > > > 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 > > > > --00000000000061f934059da9c5b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 3, 2020 at 2:52 AM Mirja = Kuehlewind <ietf@kuehlewind.net> wrote:
Ye= s, totally understood that you don=E2=80=99t want to put any specific proto= col suggestions in the charter but right now it seem a bit too loose (from = a transport point of view). So if you don=E2=80=99t want what is proposed c= urrently, do you have another proposal?

I'm fine with the current text. I'm arguing against the attempts = to aggressively narrow it.

If you are working on a draft yourself, I think it would actually be nice t= o have a first version of this draft out before the groups is fully started= to people discussion the charter right now, would actually better understa= nd what the discussion is about.

Mirja



> On 3. Feb 2020, at 11:44, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Well, I certainly don't think we should build a new version of QUI= C, and it seems likely that QUIC will be involved somehow, but Victor had s= ome quite specific protocol suggestions which might or might not be what we= want. In addition we need to ensure that there's some parity via a TCP= -based mechanism.
>
> -Ekr
>
>
>
> On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote: > Hi Ekr, hi Martin,
>
> I thought that building something on top of QUIC or H3 are preconditio= ns for any solution. If that is the case I would also prefer to put this in= the charter (to exclude it clearly from the scope of this group to rebuild= a new QUIC or a new version of quic or something like that which should be= done in the quic group; similar for http which should be done in the httpb= is in future). If you think that is somehow too restrictive what are the op= tion open, you would want to work on in this new group?
>
> Mirja
>
>
>
> > On 3. Feb 2020, at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > As MT says, I would not be comfortable if the charter defined the= specific protocol starting points, given the uncertainty about exactly whi= ch pieces we will do.
> >
> > -Ekr
> >
> >
> > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net> wrote: > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
> > > [BA] Would it be sufficient to add this clarification to the= existing
> > > sentence? The result would look like this.
> > >
> > > The WebTransport working group will define new client-server= protocols
> > > or protocol extensions using QUIC or HTTP3 in order to suppo= rt the
> >
> > I would instead say "building on existing protocol work"= ; and then point out separately that this will definitely not define a new = transport (or lower) layer protocol.
> >
> > At Mozilla we are still uncertain about the set of protocols as c= urrently proposed, and would feel uncomfortable limiting this to just those= two *in the charter*.
> >
> > --
> > Webtransport mailing list
> > Webtra= nsport@ietf.org
> > https://www.ietf.org/mailman/listinfo/we= btransport
> > --
> > Webtransport mailing list
> > Webtra= nsport@ietf.org
> > https://www.ietf.org/mailman/listinfo/we= btransport
>

--00000000000061f934059da9c5b0-- From nobody Mon Feb 3 02:57:11 2020 Return-Path: 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 CC6C112009E; Mon, 3 Feb 2020 02:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 2dvGsH9FDjNQ; Mon, 3 Feb 2020 02:57:07 -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 9B2FF12008C; Mon, 3 Feb 2020 02:57:07 -0800 (PST) Received: from [2a00:79e1:abc:301:58f1:e777:f42a:c01e]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iyZPe-00015E-2j; Mon, 03 Feb 2020 11:57:06 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 3 Feb 2020 11:57:05 +0100 Cc: Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , webtransport@ietf.org, Bernard Aboba Content-Transfer-Encoding: quoted-printable Message-Id: References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580727427;7eb99082; X-HE-SMSGID: 1iyZPe-00015E-2j Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:57:10 -0000 No I meant do you have another protocol proposal (given you said you = might not want what is proposed by Victor)? > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind = wrote: > Yes, totally understood that you don=E2=80=99t want to put any = specific protocol suggestions in the charter but right now it seem a bit = too loose (from a transport point of view). So if you don=E2=80=99t want = what is proposed currently, do you have another proposal?=20 >=20 > I'm fine with the current text. I'm arguing against the attempts to = aggressively narrow it. >=20 > -Ekr >=20 > If you are working on a draft yourself, I think it would actually be = nice to have a first version of this draft out before the groups is = fully started to people discussion the charter right now, would actually = better understand what the discussion is about. >=20 > Mirja >=20 >=20 >=20 > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: > >=20 > > Well, I certainly don't think we should build a new version of QUIC, = and it seems likely that QUIC will be involved somehow, but Victor had = some quite specific protocol suggestions which might or might not be = what we want. In addition we need to ensure that there's some parity via = a TCP-based mechanism. > >=20 > > -Ekr > >=20 > >=20 > >=20 > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind = wrote: > > Hi Ekr, hi Martin, > >=20 > > I thought that building something on top of QUIC or H3 are = preconditions for any solution. If that is the case I would also prefer = to put this in the charter (to exclude it clearly from the scope of this = group to rebuild a new QUIC or a new version of quic or something like = that which should be done in the quic group; similar for http which = should be done in the httpbis in future). If you think that is somehow = too restrictive what are the option open, you would want to work on in = this new group? > >=20 > > Mirja > >=20 > >=20 > >=20 > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > >=20 > > > As MT says, I would not be comfortable if the charter defined the = specific protocol starting points, given the uncertainty about exactly = which pieces we will do. > > >=20 > > > -Ekr > > >=20 > > >=20 > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson = wrote: > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > > [BA] Would it be sufficient to add this clarification to the = existing=20 > > > > sentence? The result would look like this. > > > >=20 > > > > The WebTransport working group will define new client-server = protocols=20 > > > > or protocol extensions using QUIC or HTTP3 in order to support = the=20 > > >=20 > > > I would instead say "building on existing protocol work" and then = point out separately that this will definitely not define a new = transport (or lower) layer protocol. > > >=20 > > > At Mozilla we are still uncertain about the set of protocols as = currently proposed, and would feel uncomfortable limiting this to just = those two *in the charter*. > > >=20 > > > --=20 > > > Webtransport mailing list > > > Webtransport@ietf.org > > > https://www.ietf.org/mailman/listinfo/webtransport > > > --=20 > > > Webtransport mailing list > > > Webtransport@ietf.org > > > https://www.ietf.org/mailman/listinfo/webtransport > >=20 >=20 From nobody Mon Feb 3 03:03:03 2020 Return-Path: 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 CAB03120917 for ; Mon, 3 Feb 2020 03:03:01 -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 L28mFK2yfu-v for ; Mon, 3 Feb 2020 03:02:59 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 8CE431200B6 for ; Mon, 3 Feb 2020 03:02:58 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id a13so14105836ljm.10 for ; Mon, 03 Feb 2020 03:02:58 -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=fFd2UrpEfVK2qXv90f4M7FjNUFOFzATNqCafyQRUjNE=; b=ZmqLN6ToKV56TI0/Ge+54JktPbTD5iR/fflk9EKB528+oTOJusqXDCvS7Y2ov/8z5V HoVSmOAwYKcBUnalKhWGtREysABMcgg3MIQe6cteribl8CMCSGOdXCJPlnG9st1cQt50 yDBRBqn3WPiFEcpdaccY5zSOTolHtVh90+B/efpXZn6vwXu7o2jMLqpiD7jbNrmijVfc YMifuJ8D50IvDLGMuGstANOo4ydbK9TFh7lDvnwsWBigJKISKVKNlZy9qzn2YGRY9Z+F V0xIY2KSBBsT+POf54WlX833b5fmpMVrNZZLR9vPdjwFMl530ns0pnpNvw1jiaIdyNYI N//Q== 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=fFd2UrpEfVK2qXv90f4M7FjNUFOFzATNqCafyQRUjNE=; b=Uv7d7eb3l5+2Fd5JnHMTp2LsorDCenE7VjQZ9Lzn6hlUlH1FufyGz0HsIiJ5yFguqu dxSlm6jP/6fUDRivu24T74HMMv/QDzEZriXOn7SV73B/lZHLR+fqOumR4tkxhubhUffR zlzplPQMl1vO7gI/szzNQUsLOHuH8ltJLRfgzcWwoQKGSgAHOrPx5PrHHkZPQWwXUyGB 2dsERR1A3A6isfaAtkVO+AuECAY77ILbLa8BGFssmrfaDKTj58Q/AhupSofPLWxV0qDC frhZX/w4OG0wRJkt0D9Q/gEJEpqRTyX/c+SO2E8YRkNUiSk6IYLsUmfvlLmlMutGIZ1c bl1A== X-Gm-Message-State: APjAAAUtrDTGykhO5Kxbhd22fwZMSTVRpyOnN5QnT00jBNSAx2JUJ4Bl OFmLJPAXOqpPTv4l4lod4KclC0iHexuVdXnMxoOWhg== X-Google-Smtp-Source: APXvYqwEbd3gjERiPO/uUrGkDhNPahPJUB6dw2Wx5eDxHH9Xsq7pQ7DJexsp9mrqgCtDFP11b6bVLrccEA/YErAohk8= X-Received: by 2002:a2e:b0c4:: with SMTP id g4mr13709993ljl.83.1580727776751; Mon, 03 Feb 2020 03:02:56 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Rescorla Date: Mon, 3 Feb 2020 03:02:20 -0800 Message-ID: To: Mirja Kuehlewind Cc: Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , webtransport@ietf.org, Bernard Aboba Content-Type: multipart/alternative; boundary="0000000000009ec3e4059da9ddb6" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 11:03:02 -0000 --0000000000009ec3e4059da9ddb6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind wrote= : > No I meant do you have another protocol proposal (given you said you migh= t > not want what is proposed by Victor)? > Well, what I'm actually saying is that it's not clear that we need *all* the ones proposed by Victor. With that said, it's not clear to me if Victor has a TCP binding yet, but one is clearly needed. -Ekr > > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: > > > > > > > > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind > wrote: > > Yes, totally understood that you don=E2=80=99t want to put any specific= protocol > suggestions in the charter but right now it seem a bit too loose (from a > transport point of view). So if you don=E2=80=99t want what is proposed c= urrently, > do you have another proposal? > > > > I'm fine with the current text. I'm arguing against the attempts to > aggressively narrow it. > > > > -Ekr > > > > If you are working on a draft yourself, I think it would actually be > nice to have a first version of this draft out before the groups is fully > started to people discussion the charter right now, would actually better > understand what the discussion is about. > > > > Mirja > > > > > > > > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: > > > > > > Well, I certainly don't think we should build a new version of QUIC, > and it seems likely that QUIC will be involved somehow, but Victor had so= me > quite specific protocol suggestions which might or might not be what we > want. In addition we need to ensure that there's some parity via a > TCP-based mechanism. > > > > > > -Ekr > > > > > > > > > > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind > wrote: > > > Hi Ekr, hi Martin, > > > > > > I thought that building something on top of QUIC or H3 are > preconditions for any solution. If that is the case I would also prefer t= o > put this in the charter (to exclude it clearly from the scope of this gro= up > to rebuild a new QUIC or a new version of quic or something like that whi= ch > should be done in the quic group; similar for http which should be done i= n > the httpbis in future). If you think that is somehow too restrictive what > are the option open, you would want to work on in this new group? > > > > > > Mirja > > > > > > > > > > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > > > > > > > As MT says, I would not be comfortable if the charter defined the > specific protocol starting points, given the uncertainty about exactly > which pieces we will do. > > > > > > > > -Ekr > > > > > > > > > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson > wrote: > > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > > > [BA] Would it be sufficient to add this clarification to the > existing > > > > > sentence? The result would look like this. > > > > > > > > > > The WebTransport working group will define new client-server > protocols > > > > > or protocol extensions using QUIC or HTTP3 in order to support th= e > > > > > > > > I would instead say "building on existing protocol work" and then > point out separately that this will definitely not define a new transport > (or lower) layer protocol. > > > > > > > > At Mozilla we are still uncertain about the set of protocols as > currently proposed, and would feel uncomfortable limiting this to just > those two *in the charter*. > > > > > > > > -- > > > > 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 > > > > > > > --0000000000009ec3e4059da9ddb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


> On 3. Feb 2020, at 11:55, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote: > Yes, totally understood that you don=E2=80=99t want to put any specifi= c protocol suggestions in the charter but right now it seem a bit too loose= (from a transport point of view). So if you don=E2=80=99t want what is pro= posed currently, do you have another proposal?
>
> I'm fine with the current text. I'm arguing against the attemp= ts to aggressively narrow it.
>
> -Ekr
>
> If you are working on a draft yourself, I think it would actually be n= ice to have a first version of this draft out before the groups is fully st= arted to people discussion the charter right now, would actually better und= erstand what the discussion is about.
>
> Mirja
>
>
>
> > On 3. Feb 2020, at 11:44, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > Well, I certainly don't think we should build a new version o= f QUIC, and it seems likely that QUIC will be involved somehow, but Victor = had some quite specific protocol suggestions which might or might not be wh= at we want. In addition we need to ensure that there's some parity via = a TCP-based mechanism.
> >
> > -Ekr
> >
> >
> >
> > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <ietf@kuehlewind.net> wro= te:
> > Hi Ekr, hi Martin,
> >
> > I thought that building something on top of QUIC or H3 are precon= ditions for any solution. If that is the case I would also prefer to put th= is in the charter (to exclude it clearly from the scope of this group to re= build a new QUIC or a new version of quic or something like that which shou= ld be done in the quic group; similar for http which should be done in the = httpbis in future). If you think that is somehow too restrictive what are t= he option open, you would want to work on in this new group?
> >
> > Mirja
> >
> >
> >
> > > On 3. Feb 2020, at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > As MT says, I would not be comfortable if the charter define= d the specific protocol starting points, given the uncertainty about exactl= y which pieces we will do.
> > >
> > > -Ekr
> > >
> > >
> > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net> w= rote:
> > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
> > > > [BA] Would it be sufficient to add this clarification t= o the existing
> > > > sentence? The result would look like this.
> > > >
> > > > The WebTransport working group will define new client-s= erver protocols
> > > > or protocol extensions using QUIC or HTTP3 in order to = support the
> > >
> > > I would instead say "building on existing protocol work= " and then point out separately that this will definitely not define a= new transport (or lower) layer protocol.
> > >
> > > At Mozilla we are still uncertain about the set of protocols= as currently proposed, and would feel uncomfortable limiting this to just = those two *in the charter*.
> > >
> > > --
> > > Webtransport mailing list
> > > W= ebtransport@ietf.org
> > > https://www.ietf.org/mailman/listin= fo/webtransport
> > > --
> > > Webtransport mailing list
> > > W= ebtransport@ietf.org
> > > https://www.ietf.org/mailman/listin= fo/webtransport
> >
>

--0000000000009ec3e4059da9ddb6-- From nobody Mon Feb 3 03:10:30 2020 Return-Path: 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 60812120923; Mon, 3 Feb 2020 03:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 7q6egkK9QAV6; Mon, 3 Feb 2020 03:10:26 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 15B3C120916; Mon, 3 Feb 2020 03:10:26 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id 9so9371126lfq.10; Mon, 03 Feb 2020 03:10:25 -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=3uWEWJ4rWiAzYNkd3ZuT+BEGZox0vOfl8nWHMGbT3Vs=; b=ZkK3Nst1bHWFHjEFYFIv8fULc3c7s/dKGPk0v+mHwa6grsEXizs1yCuUOFzyclheu/ u7CLnUyLoobJ+WXdIbUsE+FNhFi1ThECFXczqN2L14BVJmqi5v+sgG2sQZPbHehn0fR7 Jee2BpJ72Z8CsFlwgND34Yg7WzDlKTZfD55H+nONu3ocS9rpLCxjOzd5gVZ92nJkHiA6 bCeg0DUBayd4GB5+e9PT0PGMCYddlekUAjrkwvZrgMjJ+aoe3RrtX9WzHHKHHM6bd21W MSoG9RXezKtJV2uVqqWks+WHjuPc+uVKaWVY+MyjmzVvcLs0W2da0U8QMxxwiP+y1Euw rxBw== 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=3uWEWJ4rWiAzYNkd3ZuT+BEGZox0vOfl8nWHMGbT3Vs=; b=dpL1xukaIxpQ+X6qu6gDjYIU7hHF4mPDHS3ohrbeh4aVixrwrtvqnqNyT+Lkco6nsj CO2kpj8+L3TnuWDdo0MZsC2AFoLOURvWxkh1jOj3MWE8Yb29qKsA9mIAJSRCgDTrxx1t L1thbBBIwC7d++SE8BJ30sNWX84AoTKQ0+rMjEKKSiRgby5nu+EWWIbDQ2q58y9p//Vy eTmZ78cN7OQ2/4AIn7oKURvzNOvEWMNuXcEg8Q+zgd0C00V2aj3HtKUIS0jhuaWXHQIl 8MZCPkk5CYX7VeCd6wJZlnQOwC++idxbIxPXq3MyysiFdALl9Dqdw7gYZbXRy4RFVk1U kVgA== X-Gm-Message-State: APjAAAVLb0rOljVPefSjL4+BTBoEC7VAIO7JVwKk9geQFgkG5wdYTHLQ D2OYmWXir+BJZw/nOR1473WCZcReXNBu1ZbrZTE= X-Google-Smtp-Source: APXvYqwE37SteJFNvXVGOP8Y+AlxrDO15sRAuBDePeMc7dR9TEDCPvn8QsjJNTihjZZsHepKnYqr3jAEv8psyeM3lp0= X-Received: by 2002:ac2:44a3:: with SMTP id c3mr11698478lfm.1.1580728224229; Mon, 03 Feb 2020 03:10:24 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Mon, 3 Feb 2020 12:10:13 +0100 Message-ID: To: Eric Rescorla Cc: Mirja Kuehlewind , Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , WebTransport , Bernard Aboba Content-Type: multipart/alternative; boundary="0000000000004aaf18059da9f854" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 11:10:28 -0000 --0000000000004aaf18059da9f854 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we are all in agreement with what the WG should do here, which is write one or several application-layer protocols over QUIC or TLS. I wrote a short PR to attempt to clarify this in the charter: https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files Thoughts? David On Mon, Feb 3, 2020 at 12:03 PM Eric Rescorla wrote: > > > On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind > wrote: > >> No I meant do you have another protocol proposal (given you said you >> might not want what is proposed by Victor)? >> > > Well, what I'm actually saying is that it's not clear that we need *all* > the ones proposed by Victor. > > With that said, it's not clear to me if Victor has a TCP binding yet, but > one is clearly needed. > > -Ekr > > >> > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: >> > >> > >> > >> > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind >> wrote: >> > Yes, totally understood that you don=E2=80=99t want to put any specifi= c >> protocol suggestions in the charter but right now it seem a bit too loos= e >> (from a transport point of view). So if you don=E2=80=99t want what is p= roposed >> currently, do you have another proposal? >> > >> > I'm fine with the current text. I'm arguing against the attempts to >> aggressively narrow it. >> > >> > -Ekr >> > >> > If you are working on a draft yourself, I think it would actually be >> nice to have a first version of this draft out before the groups is full= y >> started to people discussion the charter right now, would actually bette= r >> understand what the discussion is about. >> > >> > Mirja >> > >> > >> > >> > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: >> > > >> > > Well, I certainly don't think we should build a new version of QUIC, >> and it seems likely that QUIC will be involved somehow, but Victor had s= ome >> quite specific protocol suggestions which might or might not be what we >> want. In addition we need to ensure that there's some parity via a >> TCP-based mechanism. >> > > >> > > -Ekr >> > > >> > > >> > > >> > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind >> wrote: >> > > Hi Ekr, hi Martin, >> > > >> > > I thought that building something on top of QUIC or H3 are >> preconditions for any solution. If that is the case I would also prefer = to >> put this in the charter (to exclude it clearly from the scope of this gr= oup >> to rebuild a new QUIC or a new version of quic or something like that wh= ich >> should be done in the quic group; similar for http which should be done = in >> the httpbis in future). If you think that is somehow too restrictive wha= t >> are the option open, you would want to work on in this new group? >> > > >> > > Mirja >> > > >> > > >> > > >> > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: >> > > > >> > > > As MT says, I would not be comfortable if the charter defined the >> specific protocol starting points, given the uncertainty about exactly >> which pieces we will do. >> > > > >> > > > -Ekr >> > > > >> > > > >> > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson >> wrote: >> > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: >> > > > > [BA] Would it be sufficient to add this clarification to the >> existing >> > > > > sentence? The result would look like this. >> > > > > >> > > > > The WebTransport working group will define new client-server >> protocols >> > > > > or protocol extensions using QUIC or HTTP3 in order to support >> the >> > > > >> > > > I would instead say "building on existing protocol work" and then >> point out separately that this will definitely not define a new transpor= t >> (or lower) layer protocol. >> > > > >> > > > At Mozilla we are still uncertain about the set of protocols as >> currently proposed, and would feel uncomfortable limiting this to just >> those two *in the charter*. >> > > > >> > > > -- >> > > > 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 >> > > >> > >> >> --0000000000004aaf18059da9f854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we are all in agreement with what the WG should do= here,
which is write one or several application-layer protocols over Q= UIC or TLS.
I wrote a short PR to attempt to clarify this in the = charter:

On Mon, Feb 3, 2020 at 12:03 PM Eric Rescorla <ekr@rtfm.com> wrote:
<= br>

On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
=
No I meant do you h= ave another protocol proposal (given you said you might not want what is pr= oposed by Victor)?

Well, what I'm actually saying is that it= 's not clear that we need *all* the ones proposed by Victor.

With that said, = it's not clear to me if Victor has a TCP binding yet, but one is clearl= y needed.

-Ekr


> On 3. Feb 2020, at 11:55, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote: > Yes, totally understood that you don=E2=80=99t want to put any specifi= c protocol suggestions in the charter but right now it seem a bit too loose= (from a transport point of view). So if you don=E2=80=99t want what is pro= posed currently, do you have another proposal?
>
> I'm fine with the current text. I'm arguing against the attemp= ts to aggressively narrow it.
>
> -Ekr
>
> If you are working on a draft yourself, I think it would actually be n= ice to have a first version of this draft out before the groups is fully st= arted to people discussion the charter right now, would actually better und= erstand what the discussion is about.
>
> Mirja
>
>
>
> > On 3. Feb 2020, at 11:44, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> > Well, I certainly don't think we should build a new version o= f QUIC, and it seems likely that QUIC will be involved somehow, but Victor = had some quite specific protocol suggestions which might or might not be wh= at we want. In addition we need to ensure that there's some parity via = a TCP-based mechanism.
> >
> > -Ekr
> >
> >
> >
> > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <ietf@kuehlewind.net> wro= te:
> > Hi Ekr, hi Martin,
> >
> > I thought that building something on top of QUIC or H3 are precon= ditions for any solution. If that is the case I would also prefer to put th= is in the charter (to exclude it clearly from the scope of this group to re= build a new QUIC or a new version of quic or something like that which shou= ld be done in the quic group; similar for http which should be done in the = httpbis in future). If you think that is somehow too restrictive what are t= he option open, you would want to work on in this new group?
> >
> > Mirja
> >
> >
> >
> > > On 3. Feb 2020, at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > As MT says, I would not be comfortable if the charter define= d the specific protocol starting points, given the uncertainty about exactl= y which pieces we will do.
> > >
> > > -Ekr
> > >
> > >
> > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net> w= rote:
> > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
> > > > [BA] Would it be sufficient to add this clarification t= o the existing
> > > > sentence? The result would look like this.
> > > >
> > > > The WebTransport working group will define new client-s= erver protocols
> > > > or protocol extensions using QUIC or HTTP3 in order to = support the
> > >
> > > I would instead say "building on existing protocol work= " and then point out separately that this will definitely not define a= new transport (or lower) layer protocol.
> > >
> > > At Mozilla we are still uncertain about the set of protocols= as currently proposed, and would feel uncomfortable limiting this to just = those two *in the charter*.
> > >
> > > --
> > > Webtransport mailing list
> > > W= ebtransport@ietf.org
> > > https://www.ietf.org/mailman/listin= fo/webtransport
> > > --
> > > Webtransport mailing list
> > > W= ebtransport@ietf.org
> > > https://www.ietf.org/mailman/listin= fo/webtransport
> >
>

--0000000000004aaf18059da9f854-- From nobody Mon Feb 3 03:40:53 2020 Return-Path: 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 863F51200C5; Mon, 3 Feb 2020 03:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 K_JQrsm86d87; Mon, 3 Feb 2020 03:40:48 -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 3C4CF12001B; Mon, 3 Feb 2020 03:40:48 -0800 (PST) Received: from [2a00:79e1:abc:301:58f1:e777:f42a:c01e]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iya5r-0001T7-Et; Mon, 03 Feb 2020 12:40:43 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 3 Feb 2020 12:40:42 +0100 Cc: Eric Rescorla , Martin Thomson , webtrans-chairs@ietf.org, Magnus Westerlund , WebTransport , Bernard Aboba Content-Transfer-Encoding: quoted-printable Message-Id: <237F6BC7-8C1D-4866-B04A-9B2C57DD484E@kuehlewind.net> References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580730048;ff84037e; X-HE-SMSGID: 1iya5r-0001T7-Et Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 11:40:52 -0000 I know (or hope) that is not the plan but this new text would still = leave the option open to design a new version of http in this group=E2=80=A6= however, from a transport point of view this is certainly better. When you say TLS in that next text, do you mean TLS or TCP, or was that = meant to also include DTLS?=20 Mirja > On 3. Feb 2020, at 12:10, David Schinazi = wrote: >=20 > I think we are all in agreement with what the WG should do here, > which is write one or several application-layer protocols over QUIC or = TLS. > I wrote a short PR to attempt to clarify this in the charter: > https://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files >=20 > Thoughts? >=20 > David >=20 > On Mon, Feb 3, 2020 at 12:03 PM Eric Rescorla wrote: >=20 >=20 > On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind = wrote: > No I meant do you have another protocol proposal (given you said you = might not want what is proposed by Victor)? >=20 > Well, what I'm actually saying is that it's not clear that we need = *all* the ones proposed by Victor. >=20 > With that said, it's not clear to me if Victor has a TCP binding yet, = but one is clearly needed. >=20 > -Ekr >=20 >=20 > > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: > >=20 > >=20 > >=20 > > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind = wrote: > > Yes, totally understood that you don=E2=80=99t want to put any = specific protocol suggestions in the charter but right now it seem a bit = too loose (from a transport point of view). So if you don=E2=80=99t want = what is proposed currently, do you have another proposal?=20 > >=20 > > I'm fine with the current text. I'm arguing against the attempts to = aggressively narrow it. > >=20 > > -Ekr > >=20 > > If you are working on a draft yourself, I think it would actually be = nice to have a first version of this draft out before the groups is = fully started to people discussion the charter right now, would actually = better understand what the discussion is about. > >=20 > > Mirja > >=20 > >=20 > >=20 > > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: > > >=20 > > > Well, I certainly don't think we should build a new version of = QUIC, and it seems likely that QUIC will be involved somehow, but Victor = had some quite specific protocol suggestions which might or might not be = what we want. In addition we need to ensure that there's some parity via = a TCP-based mechanism. > > >=20 > > > -Ekr > > >=20 > > >=20 > > >=20 > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind = wrote: > > > Hi Ekr, hi Martin, > > >=20 > > > I thought that building something on top of QUIC or H3 are = preconditions for any solution. If that is the case I would also prefer = to put this in the charter (to exclude it clearly from the scope of this = group to rebuild a new QUIC or a new version of quic or something like = that which should be done in the quic group; similar for http which = should be done in the httpbis in future). If you think that is somehow = too restrictive what are the option open, you would want to work on in = this new group? > > >=20 > > > Mirja > > >=20 > > >=20 > > >=20 > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > > >=20 > > > > As MT says, I would not be comfortable if the charter defined = the specific protocol starting points, given the uncertainty about = exactly which pieces we will do. > > > >=20 > > > > -Ekr > > > >=20 > > > >=20 > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson = wrote: > > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > > > [BA] Would it be sufficient to add this clarification to the = existing=20 > > > > > sentence? The result would look like this. > > > > >=20 > > > > > The WebTransport working group will define new client-server = protocols=20 > > > > > or protocol extensions using QUIC or HTTP3 in order to support = the=20 > > > >=20 > > > > I would instead say "building on existing protocol work" and = then point out separately that this will definitely not define a new = transport (or lower) layer protocol. > > > >=20 > > > > At Mozilla we are still uncertain about the set of protocols as = currently proposed, and would feel uncomfortable limiting this to just = those two *in the charter*. > > > >=20 > > > > --=20 > > > > Webtransport mailing list > > > > Webtransport@ietf.org > > > > https://www.ietf.org/mailman/listinfo/webtransport > > > > --=20 > > > > Webtransport mailing list > > > > Webtransport@ietf.org > > > > https://www.ietf.org/mailman/listinfo/webtransport > > >=20 > >=20 >=20 From nobody Mon Feb 3 03:42:57 2020 Return-Path: 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 522B21200B9; Mon, 3 Feb 2020 03:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 so_Y1i2sVuvI; Mon, 3 Feb 2020 03:42:53 -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 EF7DC12001B; Mon, 3 Feb 2020 03:42:52 -0800 (PST) Received: from [2a00:79e1:abc:301:58f1:e777:f42a:c01e]; authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iya7v-0003Rm-FJ; Mon, 03 Feb 2020 12:42:51 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 3 Feb 2020 12:42:50 +0100 Cc: webtrans-chairs@ietf.org, webtransport@ietf.org, Bernard Aboba , Martin Thomson , Magnus Westerlund Content-Transfer-Encoding: quoted-printable Message-Id: <40683F7F-4530-4B01-874C-6B6C30813D40@kuehlewind.net> References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1580730173;10afee94; X-HE-SMSGID: 1iya7v-0003Rm-FJ Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 11:42:55 -0000 My understanding is that Victor proposed a (separate) binding for H3 or = QUIC + you say there should also be a binding for TCP (or I guess TLS = over TCP). If that are the three option why not writing in the charter = that the group works on either separate binding for these cases or one = binding that might cover multiple of these protocols? Mirja > On 3. Feb 2020, at 12:02, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind = wrote: > No I meant do you have another protocol proposal (given you said you = might not want what is proposed by Victor)? >=20 > Well, what I'm actually saying is that it's not clear that we need = *all* the ones proposed by Victor. >=20 > With that said, it's not clear to me if Victor has a TCP binding yet, = but one is clearly needed. >=20 > -Ekr >=20 >=20 > > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: > >=20 > >=20 > >=20 > > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind = wrote: > > Yes, totally understood that you don=E2=80=99t want to put any = specific protocol suggestions in the charter but right now it seem a bit = too loose (from a transport point of view). So if you don=E2=80=99t want = what is proposed currently, do you have another proposal?=20 > >=20 > > I'm fine with the current text. I'm arguing against the attempts to = aggressively narrow it. > >=20 > > -Ekr > >=20 > > If you are working on a draft yourself, I think it would actually be = nice to have a first version of this draft out before the groups is = fully started to people discussion the charter right now, would actually = better understand what the discussion is about. > >=20 > > Mirja > >=20 > >=20 > >=20 > > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: > > >=20 > > > Well, I certainly don't think we should build a new version of = QUIC, and it seems likely that QUIC will be involved somehow, but Victor = had some quite specific protocol suggestions which might or might not be = what we want. In addition we need to ensure that there's some parity via = a TCP-based mechanism. > > >=20 > > > -Ekr > > >=20 > > >=20 > > >=20 > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind = wrote: > > > Hi Ekr, hi Martin, > > >=20 > > > I thought that building something on top of QUIC or H3 are = preconditions for any solution. If that is the case I would also prefer = to put this in the charter (to exclude it clearly from the scope of this = group to rebuild a new QUIC or a new version of quic or something like = that which should be done in the quic group; similar for http which = should be done in the httpbis in future). If you think that is somehow = too restrictive what are the option open, you would want to work on in = this new group? > > >=20 > > > Mirja > > >=20 > > >=20 > > >=20 > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > > >=20 > > > > As MT says, I would not be comfortable if the charter defined = the specific protocol starting points, given the uncertainty about = exactly which pieces we will do. > > > >=20 > > > > -Ekr > > > >=20 > > > >=20 > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson = wrote: > > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > > > [BA] Would it be sufficient to add this clarification to the = existing=20 > > > > > sentence? The result would look like this. > > > > >=20 > > > > > The WebTransport working group will define new client-server = protocols=20 > > > > > or protocol extensions using QUIC or HTTP3 in order to support = the=20 > > > >=20 > > > > I would instead say "building on existing protocol work" and = then point out separately that this will definitely not define a new = transport (or lower) layer protocol. > > > >=20 > > > > At Mozilla we are still uncertain about the set of protocols as = currently proposed, and would feel uncomfortable limiting this to just = those two *in the charter*. > > > >=20 > > > > --=20 > > > > Webtransport mailing list > > > > Webtransport@ietf.org > > > > https://www.ietf.org/mailman/listinfo/webtransport > > > > --=20 > > > > Webtransport mailing list > > > > Webtransport@ietf.org > > > > https://www.ietf.org/mailman/listinfo/webtransport > > >=20 > >=20 >=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Mon Feb 3 04:27:28 2020 Return-Path: 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 2FC021200A3 for ; Mon, 3 Feb 2020 04:27:27 -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 13As5RFdMZwA for ; Mon, 3 Feb 2020 04:27:25 -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 DBA6B12001B for ; Mon, 3 Feb 2020 04:27:24 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id q8so14419692ljb.2 for ; Mon, 03 Feb 2020 04:27:24 -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=TcCVsGp+ck8HSdHvUYCv/zWLpi1WSJ+3T5wOFTmohAo=; b=HZMbSO50ZYTfplXktCqtP/0FrR4taH3KT4c+MU6Ugu2Ea3dn1We8fbJJvWRx2wGsmH sFtJr8jWPzxPKheCQo/5IP176nM8cwK/J2rlmKv2em1HVnSNxVAj0J4LnGiXbXPajg1Y tsW1IE9rjSPe6CbWR0TSFi79kDcQePR7WbXhwAj3P+7QW1GEOxuN2tbQK+Zi0eC+Seva U8JUrLCHnEZiBsxpB5BNB/hqxgOgMarEURE8iC6+e51aBjUt+uGXJRtX/4IKH6xOv6dI ulYqcldBzAnM622Kl055cx0HpKJuK1h29mMWYZpjvjMtb7ji8++O3Dr9zau6bhq0CHIz yzdQ== 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=TcCVsGp+ck8HSdHvUYCv/zWLpi1WSJ+3T5wOFTmohAo=; b=bav/Mtu0Izp+T1mQ3vk28FuMUHiF2QF43FXw3h0NLI3DKlidXgQb19ee+OJx2XiIMn NvrQzNTXePlPUp2bSt+QzYMdAvo/euPDXnl313We7rX+tVHkd1QITuARYVr7ZxPTMqlG ECN3hzZ46HxLvOcPSjCfBNlUAIChOqC0h8pR9krTctOfdh49cwvri8j3/1J9alFFHTul AW5zLTpvnHaVS49b3fG2hhsG8RHAc4vP9ijGf56pUDz24KN7vaxkbhh6cpHEm21X3lJI UPu0YboTN8UI8qdeFdZ5KqUziF2ElDsZOwixrXR03E+HpHhqFyTUM5vYw9z7Mzw96TP6 lzdA== X-Gm-Message-State: APjAAAWvEQGbFVD9jIGvA7hVUgApan8bmlnzA53W0kWJCgSiFY8TDwZY b5JjARi1PLsuzfew86o9P5nJGGWB4/++E3XUPwrD1Q== X-Google-Smtp-Source: APXvYqz+c2SzPd86WHU9LCHUVkuYf8YB+hhIx5tR1WBQrzIYELP1cCMYuf4yIsuc0BhBq8CgLVBXBKPGoQoQpWZ1eF0= X-Received: by 2002:a2e:b0c4:: with SMTP id g4mr13924804ljl.83.1580732843012; Mon, 03 Feb 2020 04:27:23 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> <40683F7F-4530-4B01-874C-6B6C30813D40@kuehlewind.net> In-Reply-To: <40683F7F-4530-4B01-874C-6B6C30813D40@kuehlewind.net> From: Eric Rescorla Date: Mon, 3 Feb 2020 04:26:46 -0800 Message-ID: To: Mirja Kuehlewind Cc: webtrans-chairs@ietf.org, webtransport@ietf.org, Bernard Aboba , Martin Thomson , Magnus Westerlund Content-Type: multipart/alternative; boundary="00000000000097c929059dab0b16" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 12:27:27 -0000 --00000000000097c929059dab0b16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 3, 2020 at 3:42 AM Mirja Kuehlewind wrote= : > My understanding is that Victor proposed a (separate) binding for H3 or > QUIC + you say there should also be a binding for TCP (or I guess TLS ove= r > TCP). If that are the three option why not writing in the charter that th= e > group works on either separate binding for these cases or one binding tha= t > might cover multiple of these protocols? > I don't understand what this means. My point is I *don't* think we should do an H3 binding. -Ekr > Mirja > > > > On 3. Feb 2020, at 12:02, Eric Rescorla wrote: > > > > > > > > On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind > wrote: > > No I meant do you have another protocol proposal (given you said you > might not want what is proposed by Victor)? > > > > Well, what I'm actually saying is that it's not clear that we need *all= * > the ones proposed by Victor. > > > > With that said, it's not clear to me if Victor has a TCP binding yet, > but one is clearly needed. > > > > -Ekr > > > > > > > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: > > > > > > > > > > > > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind > wrote: > > > Yes, totally understood that you don=E2=80=99t want to put any specif= ic > protocol suggestions in the charter but right now it seem a bit too loose > (from a transport point of view). So if you don=E2=80=99t want what is pr= oposed > currently, do you have another proposal? > > > > > > I'm fine with the current text. I'm arguing against the attempts to > aggressively narrow it. > > > > > > -Ekr > > > > > > If you are working on a draft yourself, I think it would actually be > nice to have a first version of this draft out before the groups is fully > started to people discussion the charter right now, would actually better > understand what the discussion is about. > > > > > > Mirja > > > > > > > > > > > > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: > > > > > > > > Well, I certainly don't think we should build a new version of QUIC= , > and it seems likely that QUIC will be involved somehow, but Victor had so= me > quite specific protocol suggestions which might or might not be what we > want. In addition we need to ensure that there's some parity via a > TCP-based mechanism. > > > > > > > > -Ekr > > > > > > > > > > > > > > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind > wrote: > > > > Hi Ekr, hi Martin, > > > > > > > > I thought that building something on top of QUIC or H3 are > preconditions for any solution. If that is the case I would also prefer t= o > put this in the charter (to exclude it clearly from the scope of this gro= up > to rebuild a new QUIC or a new version of quic or something like that whi= ch > should be done in the quic group; similar for http which should be done i= n > the httpbis in future). If you think that is somehow too restrictive what > are the option open, you would want to work on in this new group? > > > > > > > > Mirja > > > > > > > > > > > > > > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > > > > > > > > > As MT says, I would not be comfortable if the charter defined the > specific protocol starting points, given the uncertainty about exactly > which pieces we will do. > > > > > > > > > > -Ekr > > > > > > > > > > > > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson > wrote: > > > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > > > > [BA] Would it be sufficient to add this clarification to the > existing > > > > > > sentence? The result would look like this. > > > > > > > > > > > > The WebTransport working group will define new client-server > protocols > > > > > > or protocol extensions using QUIC or HTTP3 in order to support > the > > > > > > > > > > I would instead say "building on existing protocol work" and then > point out separately that this will definitely not define a new transport > (or lower) layer protocol. > > > > > > > > > > At Mozilla we are still uncertain about the set of protocols as > currently proposed, and would feel uncomfortable limiting this to just > those two *in the charter*. > > > > > > > > > > -- > > > > > 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 mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > --00000000000097c929059dab0b16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Feb 3, 2020 at 3:42 AM Mirja = Kuehlewind <ietf@kuehlewind.net> wrote:
My= understanding is that Victor proposed a (separate) binding for H3 or QUIC = + you say there should also be a binding for TCP (or I guess TLS over TCP).= If that are the three option why not writing in the charter that the group= works on either separate binding for these cases or one binding that might= cover multiple of these protocols?



Mirja


> On 3. Feb 2020, at 12:02, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote: > No I meant do you have another protocol proposal (given you said you m= ight not want what is proposed by Victor)?
>
> Well, what I'm actually saying is that it's not clear that we = need *all* the ones proposed by Victor.
>
> With that said, it's not clear to me if Victor has a TCP binding y= et, but one is clearly needed.
>
> -Ekr
>
>
> > On 3. Feb 2020, at 11:55, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind <ietf@kuehlewind.net> wro= te:
> > Yes, totally understood that you don=E2=80=99t want to put any sp= ecific protocol suggestions in the charter but right now it seem a bit too = loose (from a transport point of view). So if you don=E2=80=99t want what i= s proposed currently, do you have another proposal?
> >
> > I'm fine with the current text. I'm arguing against the a= ttempts to aggressively narrow it.
> >
> > -Ekr
> >
> > If you are working on a draft yourself, I think it would actually= be nice to have a first version of this draft out before the groups is ful= ly started to people discussion the charter right now, would actually bette= r understand what the discussion is about.
> >
> > Mirja
> >
> >
> >
> > > On 3. Feb 2020, at 11:44, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > Well, I certainly don't think we should build a new vers= ion of QUIC, and it seems likely that QUIC will be involved somehow, but Vi= ctor had some quite specific protocol suggestions which might or might not = be what we want. In addition we need to ensure that there's some parity= via a TCP-based mechanism.
> > >
> > > -Ekr
> > >
> > >
> > >
> > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <ietf@kuehlewind.net&g= t; wrote:
> > > Hi Ekr, hi Martin,
> > >
> > > I thought that building something on top of QUIC or H3 are p= reconditions for any solution. If that is the case I would also prefer to p= ut this in the charter (to exclude it clearly from the scope of this group = to rebuild a new QUIC or a new version of quic or something like that which= should be done in the quic group; similar for http which should be done in= the httpbis in future). If you think that is somehow too restrictive what = are the option open, you would want to work on in this new group?
> > >
> > > Mirja
> > >
> > >
> > >
> > > > On 3. Feb 2020, at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
> > > >
> > > > As MT says, I would not be comfortable if the charter d= efined the specific protocol starting points, given the uncertainty about e= xactly which pieces we will do.
> > > >
> > > > -Ekr
> > > >
> > > >
> > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net>= ; wrote:
> > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
> > > > > [BA] Would it be sufficient to add this clarificat= ion to the existing
> > > > > sentence? The result would look like this.
> > > > >
> > > > > The WebTransport working group will define new cli= ent-server protocols
> > > > > or protocol extensions using QUIC or HTTP3 in orde= r to support the
> > > >
> > > > I would instead say "building on existing protocol= work" and then point out separately that this will definitely not def= ine a new transport (or lower) layer protocol.
> > > >
> > > > At Mozilla we are still uncertain about the set of prot= ocols as currently proposed, and would feel uncomfortable limiting this to = just those two *in the charter*.
> > > >
> > > > --
> > > > Webtransport mailing list
> > > > Webtransport@ietf.org
> > > > https://www.ietf.org/mailman/l= istinfo/webtransport
> > > > --
> > > > Webtransport mailing list
> > > > Webtransport@ietf.org
> > > > https://www.ietf.org/mailman/l= istinfo/webtransport
> > >
> >
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--00000000000097c929059dab0b16-- From nobody Mon Feb 3 05:32:44 2020 Return-Path: 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 7025D120059; Mon, 3 Feb 2020 05:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 23xO8gaFC5so; Mon, 3 Feb 2020 05:32:40 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 100E012004E; Mon, 3 Feb 2020 05:32:40 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id x14so14589217ljd.13; Mon, 03 Feb 2020 05:32:39 -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=apfvZ5sjz2Ji1XbeB9nU+DjFq9twkur1BL4SA9bqogU=; b=eZOTNfebZe581bWsQn0M/wAO4AEwGJDvpHh5qQ/O+2dRaUiBzGfsQkfUX7qucmCp+Y aVcSS1N3beV5BmQIs9XAGqeZAMaZW7XyCbIb40coWBb9PhuHun57EslaqmzXVrj6aTgF z7CFbUHMfQ3nZQNoao0gPYpJShepouPQAlVDibQEaEKL2jAy4m2RYWpnNOxtzNxuysuG oHZe5KFXV17i15mu3PAyuEmlM2pm6Jyff0lF2iU2AJL3NsbRsrMzSlv3FSkJqmF6sEC+ AjXpNbfdMMJ3qv32L2nEluXzVaKTkcw8agPPh+LdMDXp6Hs2tieAv3IwOYyrylYYaraq m8rA== 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=apfvZ5sjz2Ji1XbeB9nU+DjFq9twkur1BL4SA9bqogU=; b=UDjrjojr5v1Xdc2M+LQWHRIefY/xTvq8kuXasH1b0T4qe1/06YPI1/NAITYp7uU0xA h7WQaAYQZ67zJN9ftnPytx6tchvWPLL46QbyA7hKNg9bzijmzwxzZVzvrt30wHXX2nNS bBRqY4hpcxoKoW9tKEElQsj6t9sRyV5Z3OR1+HExe87YuVETQcDC/02q0xp48NNgvhKV gE6UjR+CczoMAGzEVJSd2tEQnLO7Ggs4uOvLRBYNT9Agre3C46BaOgauoUanvxlBVyXR m0xAjAUZ3YMJJ7qrdKOj96O4Hxse0JnbRH/xgy0+wuxCxSX+EKhbJKsrEuSPHPlpRltv mW3g== X-Gm-Message-State: APjAAAVG+NJ75VijXAZOqtt7k6aFRCOpzEJzNrWJw8XTmAAhpc/WGFwE CuI4AjgBIKw3gBZjQnN2AteVeE578j9TYwTny1E= X-Google-Smtp-Source: APXvYqxy7Ks1IWukIF7X4wo7piCoYHIR5C0kVIgt7PxNN2mViQn1xhekWXW/qh4/FXOBsXuHr4B0IqgCUimp3u1pm1U= X-Received: by 2002:a05:651c:111c:: with SMTP id d28mr12972420ljo.32.1580736758252; Mon, 03 Feb 2020 05:32:38 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> <40683F7F-4530-4B01-874C-6B6C30813D40@kuehlewind.net> In-Reply-To: From: David Schinazi Date: Mon, 3 Feb 2020 14:32:27 +0100 Message-ID: To: Eric Rescorla Cc: Mirja Kuehlewind , webtrans-chairs@ietf.org, WebTransport , Bernard Aboba , Martin Thomson , Magnus Westerlund Content-Type: multipart/alternative; boundary="000000000000f586aa059dabf4f4" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 13:32:42 -0000 --000000000000f586aa059dabf4f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, We have not yet reached consensus on the exact details of a solution, which is what we'd like to do in the newly formed working group. In particular, we don't know if the new protocol will run over HTTP/3 or QUIC directly (or if we build both) for example. Therefore we wrote the charter in such a way that the working group will be able to make that decision. The latest PR attem= pts to clarify that this application protocol will run over QUIC or TLS (by TLS I mean TLS, not anything else like DTLS or eTLS) to address your concern that we might reinvent QUIC, which we explicitly do not want to do. If you don't think the PR achieves this intent clearly, can you please propose text? Thanks, David On Mon, Feb 3, 2020 at 1:27 PM Eric Rescorla wrote: > > > On Mon, Feb 3, 2020 at 3:42 AM Mirja Kuehlewind > wrote: > >> My understanding is that Victor proposed a (separate) binding for H3 or >> QUIC + you say there should also be a binding for TCP (or I guess TLS ov= er >> TCP). If that are the three option why not writing in the charter that t= he >> group works on either separate binding for these cases or one binding th= at >> might cover multiple of these protocols? >> > > I don't understand what this means. My point is I *don't* think we should > do an H3 binding. > > -Ekr > > >> Mirja >> >> >> > On 3. Feb 2020, at 12:02, Eric Rescorla wrote: >> > >> > >> > >> > On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind >> wrote: >> > No I meant do you have another protocol proposal (given you said you >> might not want what is proposed by Victor)? >> > >> > Well, what I'm actually saying is that it's not clear that we need >> *all* the ones proposed by Victor. >> > >> > With that said, it's not clear to me if Victor has a TCP binding yet, >> but one is clearly needed. >> > >> > -Ekr >> > >> > >> > > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: >> > > >> > > >> > > >> > > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind >> wrote: >> > > Yes, totally understood that you don=E2=80=99t want to put any speci= fic >> protocol suggestions in the charter but right now it seem a bit too loos= e >> (from a transport point of view). So if you don=E2=80=99t want what is p= roposed >> currently, do you have another proposal? >> > > >> > > I'm fine with the current text. I'm arguing against the attempts to >> aggressively narrow it. >> > > >> > > -Ekr >> > > >> > > If you are working on a draft yourself, I think it would actually be >> nice to have a first version of this draft out before the groups is full= y >> started to people discussion the charter right now, would actually bette= r >> understand what the discussion is about. >> > > >> > > Mirja >> > > >> > > >> > > >> > > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: >> > > > >> > > > Well, I certainly don't think we should build a new version of >> QUIC, and it seems likely that QUIC will be involved somehow, but Victor >> had some quite specific protocol suggestions which might or might not be >> what we want. In addition we need to ensure that there's some parity via= a >> TCP-based mechanism. >> > > > >> > > > -Ekr >> > > > >> > > > >> > > > >> > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind < >> ietf@kuehlewind.net> wrote: >> > > > Hi Ekr, hi Martin, >> > > > >> > > > I thought that building something on top of QUIC or H3 are >> preconditions for any solution. If that is the case I would also prefer = to >> put this in the charter (to exclude it clearly from the scope of this gr= oup >> to rebuild a new QUIC or a new version of quic or something like that wh= ich >> should be done in the quic group; similar for http which should be done = in >> the httpbis in future). If you think that is somehow too restrictive wha= t >> are the option open, you would want to work on in this new group? >> > > > >> > > > Mirja >> > > > >> > > > >> > > > >> > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: >> > > > > >> > > > > As MT says, I would not be comfortable if the charter defined th= e >> specific protocol starting points, given the uncertainty about exactly >> which pieces we will do. >> > > > > >> > > > > -Ekr >> > > > > >> > > > > >> > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson >> wrote: >> > > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: >> > > > > > [BA] Would it be sufficient to add this clarification to the >> existing >> > > > > > sentence? The result would look like this. >> > > > > > >> > > > > > The WebTransport working group will define new client-server >> protocols >> > > > > > or protocol extensions using QUIC or HTTP3 in order to support >> the >> > > > > >> > > > > I would instead say "building on existing protocol work" and the= n >> point out separately that this will definitely not define a new transpor= t >> (or lower) layer protocol. >> > > > > >> > > > > At Mozilla we are still uncertain about the set of protocols as >> currently proposed, and would feel uncomfortable limiting this to just >> those two *in the charter*. >> > > > > >> > > > > -- >> > > > > 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 mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >> >> --000000000000f586aa059dabf4f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

We have not yet reached conse= nsus on the exact details of a solution, which is what we'd like to do = in the newly formed working group.
In particular, we don't kn= ow if the new protocol will run over HTTP/3 or QUIC directly (or if we buil= d both) for example.
Therefore we wrote the charter in such a way= that the working group will be able to make that decision.
The l= atest PR=C2=A0attempts to clarify that this application protocol w= ill run over QUIC or TLS (by TLS I mean TLS, not anything else like DTLS or= eTLS) to
address your concern that we might reinvent QUIC, which= we explicitly do not want to do.

If you don't= think the PR achieves this intent clearly, can you please propose= text?

Thanks,
David


On Mon, Feb 3, 2020 at 1:27 PM Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Feb 3, 202= 0 at 3:42 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
My understanding is that Victor proposed= a (separate) binding for H3 or QUIC + you say there should also be a bindi= ng for TCP (or I guess TLS over TCP). If that are the three option why not = writing in the charter that the group works on either separate binding for = these cases or one binding that might cover multiple of these protocols?
=C2=A0
I don't understand what this means.= My point is I *don't* think we should do an H3 binding.
=
-Ekr


Mirja


> On 3. Feb 2020, at 12:02, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote: > No I meant do you have another protocol proposal (given you said you m= ight not want what is proposed by Victor)?
>
> Well, what I'm actually saying is that it's not clear that we = need *all* the ones proposed by Victor.
>
> With that said, it's not clear to me if Victor has a TCP binding y= et, but one is clearly needed.
>
> -Ekr
>
>
> > On 3. Feb 2020, at 11:55, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind <ietf@kuehlewind.net> wro= te:
> > Yes, totally understood that you don=E2=80=99t want to put any sp= ecific protocol suggestions in the charter but right now it seem a bit too = loose (from a transport point of view). So if you don=E2=80=99t want what i= s proposed currently, do you have another proposal?
> >
> > I'm fine with the current text. I'm arguing against the a= ttempts to aggressively narrow it.
> >
> > -Ekr
> >
> > If you are working on a draft yourself, I think it would actually= be nice to have a first version of this draft out before the groups is ful= ly started to people discussion the charter right now, would actually bette= r understand what the discussion is about.
> >
> > Mirja
> >
> >
> >
> > > On 3. Feb 2020, at 11:44, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > Well, I certainly don't think we should build a new vers= ion of QUIC, and it seems likely that QUIC will be involved somehow, but Vi= ctor had some quite specific protocol suggestions which might or might not = be what we want. In addition we need to ensure that there's some parity= via a TCP-based mechanism.
> > >
> > > -Ekr
> > >
> > >
> > >
> > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind <ietf@kuehlewind.net&g= t; wrote:
> > > Hi Ekr, hi Martin,
> > >
> > > I thought that building something on top of QUIC or H3 are p= reconditions for any solution. If that is the case I would also prefer to p= ut this in the charter (to exclude it clearly from the scope of this group = to rebuild a new QUIC or a new version of quic or something like that which= should be done in the quic group; similar for http which should be done in= the httpbis in future). If you think that is somehow too restrictive what = are the option open, you would want to work on in this new group?
> > >
> > > Mirja
> > >
> > >
> > >
> > > > On 3. Feb 2020, at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
> > > >
> > > > As MT says, I would not be comfortable if the charter d= efined the specific protocol starting points, given the uncertainty about e= xactly which pieces we will do.
> > > >
> > > > -Ekr
> > > >
> > > >
> > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson <mt@lowentropy.net>= ; wrote:
> > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote:
> > > > > [BA] Would it be sufficient to add this clarificat= ion to the existing
> > > > > sentence? The result would look like this.
> > > > >
> > > > > The WebTransport working group will define new cli= ent-server protocols
> > > > > or protocol extensions using QUIC or HTTP3 in orde= r to support the
> > > >
> > > > I would instead say "building on existing protocol= work" and then point out separately that this will definitely not def= ine a new transport (or lower) layer protocol.
> > > >
> > > > At Mozilla we are still uncertain about the set of prot= ocols as currently proposed, and would feel uncomfortable limiting this to = just those two *in the charter*.
> > > >
> > > > --
> > > > Webtransport mailing list
> > > > Webtransport@ietf.org
> > > > https://www.ietf.org/mailman/l= istinfo/webtransport
> > > > --
> > > > Webtransport mailing list
> > > > Webtransport@ietf.org
> > > > https://www.ietf.org/mailman/l= istinfo/webtransport
> > >
> >
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--000000000000f586aa059dabf4f4-- From nobody Tue Feb 4 01:15:44 2020 Return-Path: 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 6150E120019; Tue, 4 Feb 2020 01:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 sy0mrXQOUNfZ; Tue, 4 Feb 2020 01:15:39 -0800 (PST) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30089.outbound.protection.outlook.com [40.107.3.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13255120074; Tue, 4 Feb 2020 01:15:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XJMAqyCHs/e4G9FTcL6NhKimoazdvb/0sYgY1JqOe0I4hSAStL7nIaUxvmhbzdnzbxnZ+eazdVGJMF/LCPneJq4rZm7ZwZYwyvgg3OyvkC02qDgOeBKVdcDJ80/bwlQTiFd/uCcmVAi7ma22B9PyUPFhB2WVvM8yIGtkclSp5H3Qm5mIAS9uLdwO9x/X4QZowsOg3ALymHlaL+c6bgonW/6EpqXxYrV/AG5ACw4vsCltHGtPox55kZdfi+J6d0y8CvuBByPHfVpIbGFuk4c1nYpZxpRd30LiyMidSo3prmYrWCZT8uwYvYJjheuVA30bDXxtU+w+gb4GyL41MLCl6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ChBhb+JUJ06PDNRGfUo+W6MU2JxRT4UG3cXA1CdfMTA=; b=m46c/e84lRDka8lh67qI6LKLaNRgESpQk6xVIIjCaaha/tV5Xf2ENLGJxb/BC1eFHt6RnW9bPpQwYE3xAPA8qXcsQ7Za9i0r4xC/1a7gssU8ePIdsdyKWpbf2ZireHf+/0wAec99kbXkzyL8v+9rKUXeTD3yqx9yNEQniMW7ZzuB8WT4lbTQzWrJNhAGuqksNa3dSMwK7h/mHcd+sFMKQJiJkPMpqoUVfRzfSgsunhRQczptsAHmhVDZ5gu4dj8UO44gbW2PGojP4AXgR9wCAhqHcGXP9nW0wiloqZCf+SUI7p2NDFjb9iq3p7/egfoTv890tC7aP3WhoSGGLfjllw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ChBhb+JUJ06PDNRGfUo+W6MU2JxRT4UG3cXA1CdfMTA=; b=TQVRJljqBPXpghbF0rIGupSYKDhaCgIVKvVaizQ/mzpbsdebgIsH6FlWjSJYUE2cdaZKHOK16x8Y4/0MhPSw2LRbdGykOMlCSthCOexcLN/ZTj31Ao+49zRVSScOUUVvfFQlfshzjN3rHVcE5NQgd2tjvNmVLaoNT1STOVDk2QE= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB5180.eurprd07.prod.outlook.com (20.178.43.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.15; Tue, 4 Feb 2020 09:15:36 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2707.016; Tue, 4 Feb 2020 09:15:36 +0000 From: Magnus Westerlund To: "bernard.aboba@gmail.com" , "webtransport@ietf.org" CC: "webtrans-chairs@ietf.org" Thread-Topic: Fwd: Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT) Thread-Index: AQHV2K1OdOdV0Z9SbkejSjGz65tBT6gKxfcA Date: Tue, 4 Feb 2020 09:15:36 +0000 Message-ID: References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53fabfbc-ff68-4976-7c71-08d7a952cba7 x-ms-traffictypediagnostic: DB7PR07MB5180: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(136003)(376002)(366004)(346002)(189003)(199004)(8936002)(71200400001)(478600001)(186003)(81156014)(81166006)(6512007)(5660300002)(4326008)(8676002)(6486002)(66556008)(86362001)(966005)(6506007)(53546011)(64756008)(66476007)(44832011)(66446008)(26005)(110136005)(316002)(91956017)(66946007)(36756003)(2616005)(76116006)(66616009)(2906002)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5180; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 41QXAH7caWO6pnHsp5B5BSTkki+TrK4kWW1GJTRO48VzYyhpmynmIPux5dPKFfuW429GIHjqzY2NVwF/3X4bqa7BZCzmm1RdB5NR5YX87CcVtPo92FKYgeLfJk1Gj2xEY49p3LXXYpHJAkFVc4/AQFt6jDzWB1pxrGy8Njo599wGDg9/NltBLqhMh1t+iyjLz5mYktQWp4FiRCJPNVGDPElXGTigXwt1KzqcMDR+A/fqka1kvfr2JEUpMv/zkTsoi+WV3evclfAo1d7L26Lk22uX8Us4hohNPPpx8y8SZC9GxL2yW3OEogwTsGPJ8Zrn2FVL9yAaW6QPaSP0OqUvi5RXzp5D3G01zBgtlehec+m1yGHQkviKmGePR9rSW1U9b95id0wS35GQEWgw5AgC3C9iRiqXqOdC5273QibjlzY74L7ZFMCVGU4CtcFz9/+E/gALs1oy46YeqUmsXKseKZShebJicRFiFzBgfDvm8da0wjzwsSyNQPBOpzbMa5jPD5b48dVs+cfNjlv/k/DR10rEzM1G86AmlF5fWG8JAlCB1oe3nVAXr9XWq6sXk5dx x-ms-exchange-antispam-messagedata: QQaH5AlCnchBB75alrNVP4Er3f0eZKXuGsUMq9A9Y6qPaxJg4F/SAa2UyZfNnlsNDi7kXvgkCPl+z3jCzeRjh83l5P+L4AnXUpKLBprwPRucFO5qK6lxLP/DHXQVPp81MD8E6NUAbjoZK6zJjN26HA== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-hH5IJAnHKFbLKxpdVokM" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53fabfbc-ff68-4976-7c71-08d7a952cba7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 09:15:36.4598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: v9bE+4ohehXijeEsePcK4B58vqqF+tKNXM+hJPotghQYO6RVvf6MNpbBXTiC1cdTtTSmtFuGgId+MFEIMP9cMS4TwT3yyf2QfxHqUR9dGoU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5180 Archived-At: Subject: Re: [Webtransport] Fwd: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 09:15:42 -0000 --=-hH5IJAnHKFbLKxpdVokM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please see inline.=20 On Fri, 2020-01-31 at 19:09 -0800, Bernard Aboba wrote: > Comments below. >=20 > > From: Magnus Westerlund via Datatracker > > Date: January 31, 2020 at 08:39:10 PST > > To: The IESG > > Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.= org > > Subject: Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (wit= h > > BLOCK and COMMENT) > > Reply-To: Magnus Westerlund > >=20 > > =EF=BB=BFMagnus Westerlund has entered the following ballot position fo= r > > charter-ietf-webtrans-00-00: Block > >=20 > > 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.) > >=20 > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ > >=20 > >=20 > >=20 > > ---------------------------------------------------------------------- > > BLOCK: > > ---------------------------------------------------------------------- > >=20 > > This charter is so open ended on what protocol that is to be developed = that > > it > > could define a new IP version as well as transport protocols. I don't t= hink > > that is the intention. >=20 > [BA] Definitely not the intention . >=20 > > To my understanding this effort could more clearly be > > defined as defining one or two application protocol that fulfills the > > WebTransport API and is using QUIC or HTTP/3. >=20 > [BA] Would it be sufficient to add this clarification to the existing > sentence? The result would look like this. >=20 > The WebTransport working group will define new client-server protocols or > protocol extensions using QUIC or HTTP3 in order to support the developme= nt of > the W3C WebTransport API https://wicg.github.io/web-transport. >=20 As this part spun of into a rather long thread I will respond to this aspec= t seperately.=20 > > If the charter can be clarified > > to not include transport protocol work and which existing transport > > protocols > > or other protocols the solution will build on it would be much better a= nd > > well > > defined work. I also think creating mappings to other transport protoco= ls > > should require rechartering to enable a wider discussion of such choice= s. > >=20 > > Secondly: > >=20 > > The group will also coordinate with related working groups within the I= ETF, > > such as QUIC and HTTPBIS, as appropriate. > >=20 > > With the current state of QUIC development and HTTP/3 mapping definitio= n, > > 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 extens= ions > > of > > HTTP/3 and QUIC to the relevant WG. >=20 > [BA] Would the following work? >=20 > =E2=80=9CThe group will also coordinate with related working groups withi= n the IETF, > such as QUIC and HTTPBIS, as appropriate. Requests for extensions of HTT= P/3 > and QUIC will be brought to the relevant WG.=E2=80=9D Yes.=20 >=20 > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > >=20 > > 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. >=20 > [BA] The WebTransport API is currently under development within the W3C W= ICG:=20 > https://wicg.github.io/web-transport/ >=20 > Since the API is maturing, there is interest in moving ahead with the > standardization process. However, the next steps are not yet clear. My = last > conversation with W3C management indicated that they were considering the > implications of the recently concluded W3C-WHATWG agreement. See the end= of > this message for details.=20 So to my understanding the current formality standing in the W3C is somethi= ng equal to a proposed BOF. There exist individual drafts that a set of propon= ents are working on, but no formal WG to take on the work.=20 So for the moment I think the charter is missrepresenting what the actual W= 3C state of the effort actually is. I understand the issues with moving target here. Do we have an okay from W3C in doing in it this way. From a reputatio= n aspect I don't want IETF's acting here result in souring the relationship.= =20 I also think the next comment from me is relevant in this discussion as it = is a matter on who is pushing requirements for this effort on who.=20 >=20 > > Trying to > > find anything about which group it belongs to on the W3C page didn't gi= ve 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. > > Having lived through the WebRTC / RTCWeb interactions it would good to = know > > more how the interaction between the bodies are intended to work. Espec= ially > > as > > changes to the API can have significant impact on what work needs to ha= ppen > > in > > the IETF. >=20 > [BA] Overall, the information flow seems more likely to go from protocol = to > API than the other way around. At least that=E2=80=99s how things have w= orked so far > with the WebTransport API, whose development mirrored the development of = the > QUIC transport protocol (e.g. Introducing uni-directional streams once th= is > was introduced in the protocol). Also, please keep in mind that protocol= s > tend to have a longer lifetime than APIs (e.g. there are multiple WebSock= ets > APIs, some message-based, others streams-based).=20 I would note that I think this actually have significant impact on the IETF charter. First I thought the API would be the requirements generating proce= ss for this work that IETF would need to follow. Now I have the impression tha= t the WG will discuss and agree on what semantics the WebTrans protocol(s) will provide. Thus, it is the IETF that will push the basic semantics onto W3C. = Are they formally fine with that?=20 This makes me wondering if the charter either needs to be explicit about th= e need to come to consensus on what those simple communication methods are. T= he charter lists unreliable messages, reliable messages and ordered streams of reliable messages. So this is in the charter not an exhaustive list, and th= us there is an opening for the WG to add more.=20 >=20 > > The current API draft does not include any discussion of priority. Howe= ver > > draft-vvv-webtrans-overview does mention priorities. As this API appear= s to > > support multiple parallel transmissions and transfers I think at a mini= mal a > > sender transport protocol scheduling or HTTP/3 priority would be likel= y 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 w= ork > > is > > expected and intended I think that needs to be raised. Otherwise I woul= d > > 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. >=20 > [BA] Priority has not faired well within recent W3C API efforts, includin= g > RTCDataChannel and WebRTC. So not sure how much energy there is. Also se= e > Ted=E2=80=99s message relating to the status of priority in HTTP/3.=20 Okay, so no initial intention and there is potential work that is ongoing t= hat may be relevant for the future. So, should this be explicit out of scope, o= r just not mentioned leaving some wiggle room for the WG?=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-hH5IJAnHKFbLKxpdVokM Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIwNDA5MTUzNlowLwYJKoZIhvcN AQkEMSIEIAPvyYYtS/h9HwqSiTiT8CuVQAAjBKifMgM1R0ZWMyu/MGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAS7tawtmzpaYk 28nC0pg6pIBNpZ/oV/pimnLo0NdV9k0+Cv5QKDuEKXe3pj+gkOFsL/4em90eXERu3YmTjoMshed1 S2zQruxUHTW443Llw2Ik8GkAIAob511bKGWdS5GLC5FA475rsM6dWIWR6eDP2sg/lbmJvURgH2Rk Cg59xXxApeyidONP8n7LqwALdJ/AndtbNC65sBussAcJZQO1bsWve8lzPLQDZ0k+vN04G8K7dOfA OHKQOlr488QamQCGDssNci/6oJRcupXae1taeR5tSPuG3SiyNuICl577YW7HpyuoKhBb6/8d7eS5 mRpOlQCCg/twzVVX23avrd32SAAAAAAAAA== --=-hH5IJAnHKFbLKxpdVokM-- From nobody Tue Feb 4 01:33:04 2020 Return-Path: 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 61C7B120074; Tue, 4 Feb 2020 01:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 51rLimDEg0Z4; Tue, 4 Feb 2020 01:32:58 -0800 (PST) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60056.outbound.protection.outlook.com [40.107.6.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18687120019; Tue, 4 Feb 2020 01:32:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hDUUT3zXGedGBh+6OVCeLJwXVuAdDgExGs+v6FG1ls3QQ+e/N4O+3pDthQjFf66zwdQhhtK2YCVpFivGr5x8UxT/aA2POCEAB5iqC3NnuQiseflkl85P4siWpOPTCJhwziXz6xnnRg348zsBlAc2X9GKrqbQBJhoKaPuhzyc0YaVDjRwDgYd9NdnW700tdnHax6+HsBGE8ckyuVTu0rl5e3RTNV59mcTa5yqNgJpuc2584J06/Pxq3k4gwQpx/ER9mPOQRgxHrBOK2FMJwnjLx/8lS4GjF0rbzM5GnpDEPhBlVST6OQ2Bw32Gs1DoO6aG2FiaOu6UEYWKOzsGCHe1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jU0JwaIe6VO3vkHwA/4+6W+ww/wHPa7+SYyXOEizS0I=; b=YczBLEZqEqKHSG6sWss0rbEl8dHQLk8GvWb1upduhPC928nEUjqntIzWAOG3tTIthHvvo8h/ShMMTtCI0GZHWAl/0GQWEU1sHbsEH2QbQFlubwcdCGALt4tQt/iGEFq43AAqTBRNtDzwLSCcxhqZsyWbl9uS5B1xv6sR2GfNesZh3AnnPwlNeQgfc2SLJ6H0oTKKHCZbcKi38SPJb4eDKWgq10sfhj0XSJEgHTyl6NacRCGleAy6c+VN4agWQ/zIThFuOpPVbN3cuAIeBN0WCetuxTpQeY4BJzXnsiKUsDykfPmUFeCFO3Ob20uWTH6RNgLLGkf2eaBoXgw/cBJVtg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jU0JwaIe6VO3vkHwA/4+6W+ww/wHPa7+SYyXOEizS0I=; b=MQTvAokML7/ExAMta5ixVGqPyIlgIXFFhd4C0GRLQGWQs/3b0lxiqRn3VTTLmOeRxS/0OFc3S1jpF+fIv0edOnHDK3VbBacPXel9Skk0rt5Iaz5fES7AtNPO+zLNL1cMEHf6pZbdP5X6SXLmQHktb5yrD28/4U5IivZZ2l3mNZ0= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB5257.eurprd07.prod.outlook.com (20.178.42.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.15; Tue, 4 Feb 2020 09:32:55 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::cd9a:187a:90ab:3544%5]) with mapi id 15.20.2707.016; Tue, 4 Feb 2020 09:32:55 +0000 From: Magnus Westerlund To: "ekr@rtfm.com" , "dschinazi.ietf@gmail.com" CC: "bernard.aboba@gmail.com" , "mt@lowentropy.net" , "webtrans-chairs@ietf.org" , "ietf@kuehlewind.net" , "webtransport@ietf.org" Thread-Topic: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT) Thread-Index: AQHV2n6byBnFSAtbM0em7exJLdn5eagJSOsAgAACQQCAAADAgIAAAG6AgAABdwCAAAtRAIAADEcAgAASWoCAAU9mAA== Date: Tue, 4 Feb 2020 09:32:55 +0000 Message-ID: <59250eb3c871a1445a0cdb4be43c4d3e176424e9.camel@ericsson.com> References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> <40683F7F-4530-4B01-874C-6B6C30813D40@kuehlewind.net> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [158.174.130.211] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5c20a1c7-0fc4-4062-488b-08d7a95536ee x-ms-traffictypediagnostic: DB7PR07MB5257: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2803; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(396003)(376002)(39860400002)(366004)(199004)(189003)(8936002)(71200400001)(478600001)(54906003)(81156014)(81166006)(6512007)(186003)(5660300002)(4326008)(8676002)(966005)(66616009)(53546011)(6486002)(6506007)(110136005)(316002)(26005)(91956017)(36756003)(44832011)(66446008)(2906002)(64756008)(76116006)(2616005)(66476007)(66556008)(86362001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5257; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /8n/QEk/THR1cpHbD1mwIjgS2xAiUFEamh9UGHTk/eAaHwjK2Y8Iar4WMyCJ3IihBbeFi1mh5hUojGJrRSNfk5m21hPSnHbRuufHkc7uDGo0tDdry2M+GmRaUPV+KlStxmyz0oPgYQHEaPaxvYAKMlGYXObYmFpf2mQeBqby6fFKlsvw85rFl0zZgIb/TnR8FUzlL9qHZDsqx2dk/hALKGozwOsz1wRJhL9V4R/qWUPhawjYNFcSBSsTl1Fnj/S0FcZF4l7qSTbyVkXQAvI/CeMPz1jurdm3PIsHk7jgj5rnPh/3Ekzno3Gff5JYPQpT4VHp8iKLsMf7dhz4kVBCLTj56ti2+njZMffjuqNiNkiDYexMpiN7VRxZfA4Abgb2p/OozRSBoT2o3iqly5aeP5ATxDH+HXgoMPV+qKwQZwtU1KcDgnH5oDqqhiQu01BD5k3PKwLa2pbeyh1QaWxJoIJmH/JRfAt5mIPqlwR2DsasQwMZnpbQ7sj0iH/jyL2C73ctqWuvcSKw2WhTHgnn5Q== x-ms-exchange-antispam-messagedata: vr6KIAYJ9NHDOQMffbT2tvaS4LBGL7MevQgQtDI4wDDdZ3ReD/cyTKh5QZnu5PQssHBZw5hBvYbAq6BKb9QmtCgdbMZxnB+A0fMfwCTDOaqfGM32lOJqkYhWYn/FgjVpzC9hmvUZcAO7k9YzFMvH8A== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-MlWQ7894KNvs6nB5pVcX" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5c20a1c7-0fc4-4062-488b-08d7a95536ee X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 09:32:55.4155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SLyUMoYpQaIgwkrqMhPUKg4DjRCTiR4UKgFlf5H4gfhxXBAhxMfyctGndPI0F6hf7MDwaVBKM9UtGxMZBM4jnCHKyX15wrUDd22Nm65NqtI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5257 Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 09:33:01 -0000 --=-MlWQ7894KNvs6nB5pVcX Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please read my answer to Bernard's initial answer on my block as this is pa= rt of the context for this response.=20 So from my perspective, I think it is good to explicitly state that the WG = will use existing transport protocols. I think what Mirja was fishing after, is = the question, do you actually intended to use UDP/DTLS and build something on t= op of that? I would strongly prefer that you do not. Becasue if you do the WG wil= l have to a have a congestion control solution baked into this. Which at a mi= nimal forces the WG to develop a protocol with a feedback solution over UDP to ca= rry information necessary for the congestion control loop. In that case I think= this WG slides sufficiently into transport land that I would request that this becomes a TSV WG. So can we at least rule UDP/DTLS out of scope?=20 Frankly I don't care if this is QUIC and/or HTTP/3 specific or also have a TCP/TLS mapping also. However, this discussion do indicates that the WG wou= ld need to start with forming some consensus on those questions. And I think i= t also affects the timeline of the work.=20 The other relevant aspect of this scope setting was my comment that the API= does not appear to be binding at all, rather it becomes a question of what the W= G have consensus on. The current charter text defines that the WG must at lea= st do three communciation methods: - Unreliable messages (if it can support fragemntation or not is undefined= ) - Reliable messages (based on wording likely with fragmentation, i.e. supp= ort larger messages than one Path MTU) - Ordered streams of reliable messages (I assume supporting large message sizes) But, the above is not necessary an exhaustive list. Also the additiona deta= ils are not defined. To me this indicates that the WG will have to either do an initial effort to define the desired properties or take the proposals and t= hen document the actual properties. Does the charter needs any wording on how i= t intends to work on that aspect.=20 Cheers Magnus Westerlund TSV AD On Mon, 2020-02-03 at 14:32 +0100, David Schinazi wrote: > Hi Mirja, >=20 > We have not yet reached consensus on the exact details of a solution, whi= ch is > what we'd like to do in the newly formed working group. > In particular, we don't know if the new protocol will run over HTTP/3 or = QUIC > directly (or if we build both) for example. > Therefore we wrote the charter in such a way that the working group will = be > able to make that decision. > The latest PR attempts to clarify that this application protocol will run= over > QUIC or TLS (by TLS I mean TLS, not anything else like DTLS or eTLS) to > address your concern that we might reinvent QUIC, which we explicitly do = not > want to do. >=20 > If you don't think the PR achieves this intent clearly, can you please pr= opose > text? >=20 > Thanks, > David >=20 >=20 > On Mon, Feb 3, 2020 at 1:27 PM Eric Rescorla wrote: > >=20 > > On Mon, Feb 3, 2020 at 3:42 AM Mirja Kuehlewind w= rote: > > > My understanding is that Victor proposed a (separate) binding for H3 = or > > > QUIC + you say there should also be a binding for TCP (or I guess TLS= over > > > TCP). If that are the three option why not writing in the charter tha= t the > > > group works on either separate binding for these cases or one binding= that > > > might cover multiple of these protocols? > >=20 > > =20 > > I don't understand what this means. My point is I *don't* think we shou= ld do > > an H3 binding. > >=20 > > -Ekr > >=20 > > > Mirja > > >=20 > > >=20 > > > > On 3. Feb 2020, at 12:02, Eric Rescorla wrote: > > > >=20 > > > >=20 > > > >=20 > > > > On Mon, Feb 3, 2020 at 2:57 AM Mirja Kuehlewind > > > wrote: > > > > No I meant do you have another protocol proposal (given you said yo= u > > > might not want what is proposed by Victor)? > > > >=20 > > > > Well, what I'm actually saying is that it's not clear that we need = *all* > > > the ones proposed by Victor. > > > >=20 > > > > With that said, it's not clear to me if Victor has a TCP binding ye= t, > > > but one is clearly needed. > > > >=20 > > > > -Ekr > > > >=20 > > > >=20 > > > > > On 3. Feb 2020, at 11:55, Eric Rescorla wrote: > > > > >=20 > > > > >=20 > > > > >=20 > > > > > On Mon, Feb 3, 2020 at 2:52 AM Mirja Kuehlewind > > > wrote: > > > > > Yes, totally understood that you don=E2=80=99t want to put any sp= ecific > > > protocol suggestions in the charter but right now it seem a bit too l= oose > > > (from a transport point of view). So if you don=E2=80=99t want what i= s proposed > > > currently, do you have another proposal?=20 > > > > >=20 > > > > > I'm fine with the current text. I'm arguing against the attempts = to > > > aggressively narrow it. > > > > >=20 > > > > > -Ekr > > > > >=20 > > > > > If you are working on a draft yourself, I think it would actually= be > > > nice to have a first version of this draft out before the groups is f= ully > > > started to people discussion the charter right now, would actually be= tter > > > understand what the discussion is about. > > > > >=20 > > > > > Mirja > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > On 3. Feb 2020, at 11:44, Eric Rescorla wrote: > > > > > >=20 > > > > > > Well, I certainly don't think we should build a new version of = QUIC, > > > and it seems likely that QUIC will be involved somehow, but Victor ha= d > > > some quite specific protocol suggestions which might or might not be = what > > > we want. In addition we need to ensure that there's some parity via a= TCP- > > > based mechanism. > > > > > >=20 > > > > > > -Ekr > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > On Mon, Feb 3, 2020 at 2:42 AM Mirja Kuehlewind > > > wrote: > > > > > > Hi Ekr, hi Martin, > > > > > >=20 > > > > > > I thought that building something on top of QUIC or H3 are > > > preconditions for any solution. If that is the case I would also pref= er to > > > put this in the charter (to exclude it clearly from the scope of this > > > group to rebuild a new QUIC or a new version of quic or something lik= e > > > that which should be done in the quic group; similar for http which s= hould > > > be done in the httpbis in future). If you think that is somehow too > > > restrictive what are the option open, you would want to work on in th= is > > > new group? > > > > > >=20 > > > > > > Mirja > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > > On 3. Feb 2020, at 11:23, Eric Rescorla wrote: > > > > > > >=20 > > > > > > > As MT says, I would not be comfortable if the charter defined= the > > > specific protocol starting points, given the uncertainty about exactl= y > > > which pieces we will do. > > > > > > >=20 > > > > > > > -Ekr > > > > > > >=20 > > > > > > >=20 > > > > > > > On Sat, Feb 1, 2020 at 11:53 AM Martin Thomson > > > wrote: > > > > > > > On Sat, Feb 1, 2020, at 04:09, Bernard Aboba wrote: > > > > > > > > [BA] Would it be sufficient to add this clarification to th= e > > > existing=20 > > > > > > > > sentence? The result would look like this. > > > > > > > >=20 > > > > > > > > The WebTransport working group will define new client-serve= r > > > protocols=20 > > > > > > > > or protocol extensions using QUIC or HTTP3 in order to supp= ort > > > the=20 > > > > > > >=20 > > > > > > > I would instead say "building on existing protocol work" and = then > > > point out separately that this will definitely not define a new trans= port > > > (or lower) layer protocol. > > > > > > >=20 > > > > > > > At Mozilla we are still uncertain about the set of protocols = as > > > currently proposed, and would feel uncomfortable limiting this to jus= t > > > those two *in the charter*. > > > > > > >=20 > > > > > > > --=20 > > > > > > > Webtransport mailing list > > > > > > > Webtransport@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/webtransport > > > > > > > --=20 > > > > > > > Webtransport mailing list > > > > > > > Webtransport@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/webtransport > > > > > >=20 > > > > >=20 > > > >=20 > > > > --=20 > > > > Webtransport mailing list > > > > Webtransport@ietf.org > > > > https://www.ietf.org/mailman/listinfo/webtransport > > >=20 --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-MlWQ7894KNvs6nB5pVcX Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIwNDA5MzI1NFowLwYJKoZIhvcN AQkEMSIEIDM+lQQsxuIwgPprWfYvufHoVR/pnezwRJrIY4zjvwhuMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAK/xWu1ZpkHED lQ7Z4V7aA3IV1gSu6yNjhX/JMiMh/7VHbz5YAO6IW/xOnaJkYHZ3C3+kdci82ggF0CHNXJ/s0K2W WFNoNJa5CfCvrZRNCt4+ejhe1kSKFQB4E8lAyUXPh+9+HHqUlYlKQkkmHF/xpdNdqJwtP+IU29Ac V0JBPvDuWKCLDUpDHu0McaLcvTSZGIxuHrS/wTAw6tS5vJGi2gBRBG+msCzR4zvrCQ/El7QIdv2i tLoDFETsCsJg/qc40I3AGMRnN+4HWEg5NrPdEYl55AAB5NpjfZK54L74d+8WcqaTxPJ1xEGusFmv +0UM9wbVHFPbBPsf0IVNuNdp9gAAAAAAAA== --=-MlWQ7894KNvs6nB5pVcX-- From nobody Tue Feb 4 02:07:02 2020 Return-Path: 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 1FDCF120074 for ; Tue, 4 Feb 2020 02:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 AD9FmNwxGDGH for ; Tue, 4 Feb 2020 02:06:56 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 8E9DE120073 for ; Tue, 4 Feb 2020 02:06:55 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id o15so12372491ljg.6 for ; Tue, 04 Feb 2020 02:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KH0rl3dquxzIqgFMEnu1UOfl8aOyzdi6HkpyIvDH0S0=; b=aBD3vUqp3xXSnjNw94gmXAL1gPm0C1qMd6fea8uJyJO5ZhNYMs5sZzk/XpGOmjI3Xz 0NghYqrlHWdYNZQ/63RRPRIBBzS7bKNpjoy8QcLvVtZ5tzP0dtxYfG1k2pc+OvUyParH T0Ov3VMY67rppbjt4Dzk67axwbCrZtOUjHD86KYK9Zu/6y7PBavaH5N0SY/IN7NGzwDB hgZmZy42rFyxKVDPiytJocIygpFC8DwVX/Cz3QuXiN/xPHoKDPPVXpZb5thaOsGbq2Iz v0vARvCvV+bDdNlLJwwSjN8tP1Z03Jgw0evLUTKfVBD9cMpnReIQvmpKK6g3C6a/d81I In7w== 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=KH0rl3dquxzIqgFMEnu1UOfl8aOyzdi6HkpyIvDH0S0=; b=BbaMxFXhrn7C8ed+u6wCB2DmYE1+eKCGXvVDKlbU6IbL9obWW43BJVm3MTbWltvBl5 jT8PqscYr5AjwSa6Iqwr+Evln/qThnNapvdbDKeA8A45YvgvVVs/hYEDtqg7AzepjBMw hGA3LUBWulgfQETUogXSneUmmvr4H/ipIO1iCxDgInCQOdNsC8PEJtqjPMeBE/YGyctX jS0RycJqJEYu8MTZD2mDhapZhssG4ZU1daRXEB5iIzPE64f+lSdzZISdyfX0Ss4KeYTg EFqgv8R28B5BgS6SrDJb7VUwu4tIqoTNkVZkt6R/ONoZdwfuIzzA9LD8iD4BnY9QGch1 uvwg== X-Gm-Message-State: APjAAAU2m9Q+l3i24XBS74u9MNYgKk0Yr4SsU2hhu7VlUCeJj99deF4g MPnuShgida70cmDQpGWUpuJfhF+Fjz9xW/N7lothYB1DYaCIfQ== X-Google-Smtp-Source: APXvYqz1fPa/y2lvfswsRUjBLqZ2oNB3gIkLHmtIA+LIzQekIwc7zNac/1A2xuNpst09bBR038NXBx6SAUPlRZ9gh7U= X-Received: by 2002:a2e:5357:: with SMTP id t23mr16386238ljd.227.1580810813348; Tue, 04 Feb 2020 02:06:53 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> From: Victor Vasiliev Date: Tue, 4 Feb 2020 11:06:41 +0100 Message-ID: To: Magnus Westerlund Cc: The IESG , webtrans-chairs@ietf.org, WebTransport Content-Type: multipart/alternative; boundary="000000000000fcf461059dbd32a9" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 10:06:59 -0000 --000000000000fcf461059dbd32a9 Content-Type: text/plain; charset="UTF-8" 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. --000000000000fcf461059dbd32a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe most of those have been addressed in David&= #39;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:
----------------------------------------------------------------------
<= br>
=C2=A0
[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 word= ing
that the WebTrans WG will actually have to take any requests for extensions= of
HTTP/3 and QUIC to the relevant WG.

While th= ere are no extensions to QUIC among the proposed WG documents, some of
t= he drafts do extend HTTP using custom SETTINGS parameters (which is the
= intended HTTP extensibility mechanism).=C2=A0 I've hitherto assumed tha= t webtrans
would work with HTTP experts in httpbis/quic to ensure that t= he proposed
extensions are architecturally sound and follow best practic= es, but the main
bulk of work would be done in the new working group its= elf.
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also would appreciate if someone can clarify what stage of formality the<= br> 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 gi= ve 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.
<= /blockquote>

It's a WICG=C2=A0draft, which basically mean= s no formal status.=C2=A0 We had a discussion
session at TPAC last year,= and I believe most people who'd be normally involved
are aware of i= t, but my current understanding is that the editors of the W3C
spec curr= ently do not believe we have enough real-world implementation
experience= with the proposal to advance it further in the formal process.
=C2= =A0
Having lived through the WebRTC / RTCWeb interactions it would good to know=
more how the interaction between the bodies are intended to work. Especiall= y as
changes to the API can have significant impact on what work needs to happen= in
the IETF.

I mostly agree with Bernard h= ere.=C2=A0 My plan was that the -overview doc would
list all of the prot= ocol requirements and API expectations, acting as
integration point betw= een W3C and IETF specs.
=C2=A0
The current API draft does not include any discussion of priority. However<= br> 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=C2=A0 would be like= ly 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 as= sume
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.=C2=A0 I'v= e been meaning to write this up
further, but there's a lot of text t= o 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 t= he
=C2=A0 =C2=A0 purpose of scheduling writes.
(2) Priorities that ar= e communicated to the peer on the wire as a hint.

Most of the discus= sion in HTTPBIS and QUIC WGs was about #2.=C2=A0 I don't believe
any= of the proposed drafts cover that topic, and I'd rather wait for
qu= ic/httpbis to come up with a mechanism first.

The priorities mention= ed in -overview are of the #1 kind.=C2=A0 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 usesQUIC.

A QUIC implementation SHOULD provide ways in which an applic= ation can indicate
the relative priority of streams. When deciding which= streams to dedicate
resources to, the implementation SHOULD use the inf= ormation provided by the
application.
"""

Besid= es, I don't believe we can avoid defining a write scheduling mechanism = in
the API.=C2=A0 QUIC itself treats it as an implementation detail, but= Web APIs
generally try really hard to avoid implementation-defined beha= vior.=C2=A0 If
every browser had a completely different write scheduling= approach,
that could make the job of writing performant cross-browser c= ode really
difficult.

Thanks,
=C2= =A0 Victor.
--000000000000fcf461059dbd32a9-- From nobody Wed Feb 5 06:34:57 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F141200EC; Wed, 5 Feb 2020 06:34:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158091329253.12815.9369576484605200664.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 06:34:52 -0800 Archived-At: Subject: [Webtransport] Alissa Cooper's Block on charter-ietf-webtrans-00-00: (with BLOCK) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 14:34:53 -0000 Alissa Cooper 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: ---------------------------------------------------------------------- Based on the responses to Magnus' comment I think there are two issues to sort out before proceeding further. 1) Whether the API is creating requirements for the protocol, or the protocol is creating requirements for the API. The charter is written as if the situation is the former, but the list mail points towards the latter. The charter should be clear about this before it goes out for external review. 2) It sounds like there is still some chance that the change control for the API shifts from the W3C to the WHATWG. Would this group re-charter (or close) if that happens, or would it be better to make the charter more generically tied to the API but not to its change controller? Please keep the IESG on cc on all replies. Thanks. From nobody Thu Feb 6 02:48:46 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9A1202DD; Thu, 6 Feb 2020 02:48:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158098612131.12351.18068816915273886576.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 02:48:41 -0800 Archived-At: Subject: [Webtransport] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_o?= =?utf-8?q?n_charter-ietf-webtrans-00-00=3A_=28with_COMMENT=29?= X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 10:48:41 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-webtrans-00-00: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In support of Alissa's and Magnus' blocks I would also like to see this (initially) more narrowly scoped. Especially talking about "protocols or protocol extensions" without constraining this statement to a set of transport protocols that need to be used, as well as not constraining the list "range of simple communication methods" to a limited (initial) list basically allows this charter to define more or less any kind of protocol (over the whole stack). From nobody Thu Feb 6 04:59:28 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6507F120086; Thu, 6 Feb 2020 04:59:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158099396631.12409.17485421597898405142.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 04:59:26 -0800 Archived-At: Subject: [Webtransport] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_ch?= =?utf-8?q?arter-ietf-webtrans-00-00=3A_=28with_COMMENT=29?= X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 12:59:26 -0000 Éric Vyncke has entered the following ballot position for charter-ietf-webtrans-00-00: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I will follow the discussion around the BLOCK points of my fellow AD but I wonder why this is in ART and not in TSV? -éric From nobody Thu Feb 6 05:36:44 2020 Return-Path: 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 95F791208A9; Thu, 6 Feb 2020 05:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zSzTu5CLXxKb; Thu, 6 Feb 2020 05:36:36 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 7A50C1208A6; Thu, 6 Feb 2020 05:36:36 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id q8so6107570ljj.11; Thu, 06 Feb 2020 05:36:36 -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=Ur5Ts5Eg8zJsGpprsipLo+9kUD95wwhq9AsT6X8QPMs=; b=ZmN9N+tB8e1KexsjDV0x24i7OeXu31zELlvXqMCk9/C7KtI/A6go+MtonALa4S9H7i ukBr6CBQMV7kn1xYfLF/D+K5qOou2s7SoMxQQg4sGGo1E4rQHFsRlr6+zZNb39fxZOjN CSftlDDLPebYH00g6i1MkQ/C9X2uFUkOf3tTs8x9BmqpKdJjaOUy/yzaCkc1SZWQ0zVW TkMT7e9QHXJaDSuF8sTxpu6jSRDi6z+hmXwKsIYxC2bdj17c5Q+QWATznnm8x+8Mry7Y kN+3dYQ1iLVX7Sc1NXxIZba+z5I0xkezFIJIecMx12iehovqOjcBMRZ1nDYpdFAySnRE TBRA== 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=Ur5Ts5Eg8zJsGpprsipLo+9kUD95wwhq9AsT6X8QPMs=; b=DjFHh7/09u1nGDwpN0NEu7DH6m8P7Kb1eIac6DGOO6QEryrckUbDPnIKKK2o++b919 9yBbVRT6aQTqFdKhsoqD+NEr/L39emKaAS//sCpmuba+v8KdKBLhE2M2OBNl+SkMC4qh hkMcdGLGjvC2WYjF+GnhZai0BZmF5eimEf4Zdn8GN87GBVx6bOOYMZz5hx0lavquVt36 H7ay8PeCWMy9W5tqfazHqr9SzBDh48ktWEQpo8VPFshMh1DCwPY1+CQTe5eUKqNhHuMO SNjPF4QYNMg6psyHmPqNU4bzeo733ZdZQGc+QrMkcj8GJhpIiPf3keodfucOncuL/6Pl 6aYw== X-Gm-Message-State: APjAAAXgawSmm5ZuTqfE1/VwLjNaTgVOyerNKr3GMrCT/PPFPl9Xbcm6 oTPEFCTRHia7mLaEvGNsLAhEvPbmktT8BEcvpQdR9kK1 X-Google-Smtp-Source: APXvYqxEowHrCFzUsm8pBx9LZCf0FwUHcTbShl9AtexbzncpxMaBgs7daWBc14kk8oIAeuSgEGAzH1cfcNaKmLLecwk= X-Received: by 2002:a2e:84d0:: with SMTP id q16mr2137556ljh.138.1580996194678; Thu, 06 Feb 2020 05:36:34 -0800 (PST) MIME-Version: 1.0 References: <158091329253.12815.9369576484605200664.idtracker@ietfa.amsl.com> In-Reply-To: <158091329253.12815.9369576484605200664.idtracker@ietfa.amsl.com> From: David Schinazi Date: Thu, 6 Feb 2020 14:36:23 +0100 Message-ID: To: Alissa Cooper Cc: The IESG , WebTransport , webtrans-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000933bb1059de85c54" Archived-At: Subject: Re: [Webtransport] Alissa Cooper's Block on charter-ietf-webtrans-00-00: (with BLOCK) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 13:36:39 -0000 --000000000000933bb1059de85c54 Content-Type: text/plain; charset="UTF-8" Hi Alissa, thank you for the review - responses inline. On Wed, Feb 5, 2020 at 3:34 PM Alissa Cooper via Datatracker < noreply@ietf.org> wrote: > Alissa Cooper 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: > ---------------------------------------------------------------------- > > Based on the responses to Magnus' comment I think there are two issues to > sort > out before proceeding further. > > 1) Whether the API is creating requirements for the protocol, or the > protocol > is creating requirements for the API. The charter is written as if the > situation is the former, but the list mail points towards the latter. The > charter should be clear about this before it goes out for external review. > The intention is for the API to create requirements on the protocol. We'll clarify the text to make this more explicit. 2) It sounds like there is still some chance that the change control for the > API shifts from the W3C to the WHATWG. Would this group re-charter (or > close) > if that happens, or would it be better to make the charter more generically > tied to the API but not to its change controller? > That's a good point. We'll replace all mentions of "W3C" with something like "the owner of the API". That way, the details of interactions between W3C and WHATWG (and also internal changes in those organizations) become opaque to this WG. > Please keep the IESG on cc on all replies. Thanks. > Would these edits be satisfactory? Thanks, David --000000000000933bb1059de85c54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alissa, thank you for the review - res= ponses inline.

On Wed, Feb 5, 2020 at 3:34 PM Alissa Cooper via Datatracke= r <noreply@ietf.org> wrote:
Alissa Cooper 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:
----------------------------------------------------------------------

Based on the responses to Magnus' comment I think there are two issues = to sort
out before proceeding further.

1) Whether the API is creating requirements for the protocol, or the protoc= ol
is creating requirements for the API. The charter is written as if the
situation is the former, but the list mail points towards the latter. The charter should be clear about this before it goes out for external review.<= br>

The intention is for the API to create = requirements on the protocol.
We'll clarify the text to make = this more explicit.

2) It sounds like there is still some chance that the change control for th= e
API shifts from the W3C to the WHATWG. Would this group re-charter (or clos= e)
if that happens, or would it be better to make the charter more generically=
tied to the API but not to its change controller?

=
That's a good point. We'll replace all mentions of "= ;W3C" with something like
"the owner of the API". = That way, the details of interactions between W3C
and WHATWG (and= also internal changes in those organizations) become
opaque to t= his WG.
=C2=A0
Please keep the IESG on cc on all replies. Thanks.
Would these edits be satisfactory?

Tha= nks,
David
=C2=A0
--000000000000933bb1059de85c54-- From nobody Thu Feb 6 05:43:00 2020 Return-Path: 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 8D50912029C; Thu, 6 Feb 2020 05:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=UaHA3f6C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lw7ccWhN 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 XbP2AO3uC_Fr; Thu, 6 Feb 2020 05:42:55 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FCE12008A; Thu, 6 Feb 2020 05:42:54 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0491922110; Thu, 6 Feb 2020 08:42:54 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 06 Feb 2020 08:42:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm2; bh=GTnuuJg2jBgAse4ZNz6adjj jXYpeems+Dz7zsPC1AfY=; b=UaHA3f6C/+y22fbrsCzUht3WOutNLeDDZyYrjGU tW2ebDcqx4phcaeGt4DJi4DFyn6NnPEHat2Fvmiu8jWxrj7qC4U3jpIMKCeKA273 XUprfnJ84v8DbHyqcm9C3kyxlPsnfm1JqH0nBh8ZXIBwLukC4Lm6x40++3tSU5kP 9uXkTMlhGbsEoKDImLPR0aTZ+OEO4i3em+m6C4eugaOHSXKnFG8QN77gtmo3jlnF I1z30YwWulZG7gEcAkS2mFRaDmSH7Tfi58g07AEHJshaSTJtDkp4K0IjE/X+m3ym BoUQujN3i0nmqpbLq6d08JhKT1g1OsqVvExHlbar61WhVog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=GTnuuJ g2jBgAse4ZNz6adjjjXYpeems+Dz7zsPC1AfY=; b=lw7ccWhNylnkoVxm1yCgO7 /mkf0MFCfVZQxBwfSjZ87dO8zc3ZDoDRzP38dya7nFph6anJO5YIpG/Z9uG7FC1s ojnvodaI+OgR1BLMifr7yozpxtDXdcRnd/esPmBFIdUEPcZAORdT+MCJngCzjO9k sK0FG1eHJsW7JJTNPiBNiOv4qTt62KLJ8bgVoL8tHe14x7LtgB49O4nZiFmbs87r 10uiPgu9DxPAvPFTpxFPjA/UsDwmQfevWjfsI0kncgEc78aVqnAOnP7sl50OaHD+ WdY2xZft1fSHgJojmNAdS4h7MIQhpbuGG9aOd+Rg42U3zukU6lAnL2mwWkfaqsCg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrheefgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffktgggufffjgfvfhfosegrtdhmre hhtddvnecuhfhrohhmpeetlhhishhsrgcuvehoohhpvghruceorghlihhsshgrsegtohho phgvrhifrdhinheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfedrfe ekrdduudejrdekvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.82]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F281328005A; Thu, 6 Feb 2020 08:42:53 -0500 (EST) From: Alissa Cooper Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_70E84657-5D69-4480-856F-AB93DFA1F25A" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 6 Feb 2020 08:42:54 -0500 In-Reply-To: Cc: IESG , WebTransport , webtrans-chairs@ietf.org To: David Schinazi References: <158091329253.12815.9369576484605200664.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Webtransport] Alissa Cooper's Block on charter-ietf-webtrans-00-00: (with BLOCK) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 13:42:57 -0000 --Apple-Mail=_70E84657-5D69-4480-856F-AB93DFA1F25A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 6, 2020, at 8:36 AM, David Schinazi = wrote: >=20 > Hi Alissa, thank you for the review - responses inline. >=20 > On Wed, Feb 5, 2020 at 3:34 PM Alissa Cooper via Datatracker = > wrote: > Alissa Cooper has entered the following ballot position for > charter-ietf-webtrans-00-00: Block >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > Based on the responses to Magnus' comment I think there are two issues = to sort > out before proceeding further. >=20 > 1) Whether the API is creating requirements for the protocol, or the = protocol > is creating requirements for the API. The charter is written as if the > situation is the former, but the list mail points towards the latter. = The > charter should be clear about this before it goes out for external = review. >=20 > The intention is for the API to create requirements on the protocol. > We'll clarify the text to make this more explicit. >=20 > 2) It sounds like there is still some chance that the change control = for the > API shifts from the W3C to the WHATWG. Would this group re-charter (or = close) > if that happens, or would it be better to make the charter more = generically > tied to the API but not to its change controller? >=20 > That's a good point. We'll replace all mentions of "W3C" with = something like > "the owner of the API". That way, the details of interactions between = W3C > and WHATWG (and also internal changes in those organizations) become > opaque to this WG. > =20 > Please keep the IESG on cc on all replies. Thanks. >=20 > Would these edits be satisfactory? Yes, thanks. Alissa >=20 > Thanks, > David > =20 --Apple-Mail=_70E84657-5D69-4480-856F-AB93DFA1F25A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Feb 6, 2020, at 8:36 AM, David Schinazi <dschinazi.ietf@gmail.com> wrote:

Hi Alissa, thank you for the = review - responses inline.

On Wed, Feb = 5, 2020 at 3:34 PM Alissa Cooper via Datatracker <noreply@ietf.org> = wrote:
Alissa Cooper 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:
= ----------------------------------------------------------------------

Based on the responses to Magnus' comment I think there are two issues = to sort
out before proceeding further.

1) Whether the API is creating requirements for the protocol, or the = protocol
is creating requirements for the API. The charter is written as if = the
situation is the former, but the list mail points towards the latter. = The
charter should be clear about this before it goes out for external = review.

The intention is for the API to create = requirements on the protocol.
We'll clarify the = text to make this more explicit.

2) It sounds like there is still some chance that the change control for = the
API shifts from the W3C to the WHATWG. Would this group re-charter (or = close)
if that happens, or would it be better to make the charter more = generically
tied to the API but not to its change controller?

That's a good point. We'll replace all mentions of "W3C" with = something like
"the owner of the API". That way, = the details of interactions between W3C
and WHATWG = (and also internal changes in those organizations) become
opaque to this WG.
 
Please keep the IESG on cc on all replies. Thanks.

Would these edits be = satisfactory?

Yes, thanks.
Alissa


Thanks,
David
 

= --Apple-Mail=_70E84657-5D69-4480-856F-AB93DFA1F25A-- From nobody Thu Feb 6 05:46:57 2020 Return-Path: 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 6170812029C; Thu, 6 Feb 2020 05:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kMK_bVEBxN4n; Thu, 6 Feb 2020 05:46:47 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 0927712008A; Thu, 6 Feb 2020 05:46:47 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id n25so4152636lfl.0; Thu, 06 Feb 2020 05:46:46 -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=NyYSIZcLJV1nTbJVjOhLRIiiDrrJFn9EjPYa9Fp9l6I=; b=pTm80L+kBcNlRWYmF6fBtRRv/HzOMANoHWqdJP0Q6afdgQRybRx3En99ryOP4GWIMl dd999W66OaxR4zuxlAlSMb3GuC3b/oXnVQNa+MNtnIaleUxynavvS3UshZbTEr0WrIKB feqjlqgi94wJBykEhJHDcaady6TITXk+WpPqxnkK6Q6VN/KvTdX2HWOSah5Y03bJ3xY2 xDLov7LIEquPR46KeNVnLvjfBJtxkNLpV/RP32rXZ8Ur4a/SUNthYERg05tnQH/nulHM gqnFuyiFe+yEZh65Xbo037RKXK9ej7b2ixuMeQdK/qIf591WdOiUyDCf7hqah1/qTtsn LW6A== 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=NyYSIZcLJV1nTbJVjOhLRIiiDrrJFn9EjPYa9Fp9l6I=; b=G16jcPf0lMzBFAW67YIq5DULWbXR+K+p66niHyQNnMtu/sasEPN+uYGYSGFq5jdvcs Rv/W0r/jiNgEAKSCAALccp2Nv+t1X9Etn3lwVyrFUC7JBm9KJb06IrI2aR2jTYO1K0U7 g0lOtZ9FjgnKqppO3ixD7CmtUD2E+rY3IB5EWG2ZV/U9xdq/CzpPekCjntuZ/73vQVkH dSf/q+9Sgz4p5G5fuVxxfic9l5VmtQX+DlNYGcVRBbeiXiPkBeNwHmVkCL/bHxiMtIBy h81SUh4BeUFP8Tk9cD2RO/k+9dCfLIaOO6r3qqr6P3qIH+4rPYGXXzVZpSg3JDlegL1G 9udg== X-Gm-Message-State: APjAAAV+om6rO7BctJbQW813q88Ny5K6CTYwH96wQZq0bCAy0GOKxvtS xo697t25nzWvE0Daw6TraMX8krvf61/7DN9rFN0= X-Google-Smtp-Source: APXvYqzVjVlrPupGqWPqArHp1oMdI01r2jbQLvBRPTM/YdeED2H0UFlee/GL5cRtQGJC4NZ/CHsB8a0GlJ6lVPJgIUQ= X-Received: by 2002:a19:5f05:: with SMTP id t5mr1893586lfb.149.1580996805252; Thu, 06 Feb 2020 05:46:45 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Thu, 6 Feb 2020 14:46:34 +0100 Message-ID: To: Magnus Westerlund Cc: Victor Vasiliev , The IESG , webtrans-chairs@ietf.org, WebTransport Content-Type: multipart/alternative; boundary="000000000000f7da25059de88055" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 13:46:51 -0000 --000000000000f7da25059de88055 Content-Type: text/plain; charset="UTF-8" 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. Would that be an acceptable scope? Thanks, David On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev 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. > --000000000000f7da25059de88055 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus,

I realized that some o= f our earlier replies were accidentally=C2=A0not sent to
the IESG list,= for which I apologize.

To summarize that discussi= on:

- It is not our intention to build a new trans= port protocol here.
The WEBTRANS WG would build application proto= cols that
run over QUIC, or TLS/TCP. This would=C2=A0ensure we be= nefit
from their security and congestion control properties.
Here is a PR to the charter that should clarify this:

- The WEBTRANS WG would not modify QUIC or HTTP.<= /div>
Any discussion of modifying those core protocols would
= happen in their existing respective working groups.
However, disc= ussion of extensions to these protocols could
be allowed in t= his WG, as long as any document WGLC is
also sent to the mailing = list responsible for that protocol.

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 th= ose 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:
----------------------------------------------------------------------
<= br>
=C2=A0
[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 word= ing
that the WebTrans WG will actually have to take any requests for extensions= of
HTTP/3 and QUIC to the relevant WG.

While th= ere are no extensions to QUIC among the proposed WG documents, some of
t= he drafts do extend HTTP using custom SETTINGS parameters (which is the
= intended HTTP extensibility mechanism).=C2=A0 I've hitherto assumed tha= t webtrans
would work with HTTP experts in httpbis/quic to ensure that t= he proposed
extensions are architecturally sound and follow best practic= es, but the main
bulk of work would be done in the new working group its= elf.
=C2=A0
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also would appreciate if someone can clarify what stage of formality the<= br> 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 gi= ve 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.
<= /blockquote>

It's a WICG=C2=A0draft, which basically mean= s no formal status.=C2=A0 We had a discussion
session at TPAC last year,= and I believe most people who'd be normally involved
are aware of i= t, but my current understanding is that the editors of the W3C
spec curr= ently do not believe we have enough real-world implementation
experience= with the proposal to advance it further in the formal process.
=C2= =A0
Having lived through the WebRTC / RTCWeb interactions it would good to know=
more how the interaction between the bodies are intended to work. Especiall= y as
changes to the API can have significant impact on what work needs to happen= in
the IETF.

I mostly agree with Bernard h= ere.=C2=A0 My plan was that the -overview doc would
list all of the prot= ocol requirements and API expectations, acting as
integration point betw= een W3C and IETF specs.
=C2=A0
The current API draft does not include any discussion of priority. However<= br> 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=C2=A0 would be like= ly 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 as= sume
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.=C2=A0 I'v= e been meaning to write this up
further, but there's a lot of text t= o 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 t= he
=C2=A0 =C2=A0 purpose of scheduling writes.
(2) Priorities that ar= e communicated to the peer on the wire as a hint.

Most of the discus= sion in HTTPBIS and QUIC WGs was about #2.=C2=A0 I don't believe
any= of the proposed drafts cover that topic, and I'd rather wait for
qu= ic/httpbis to come up with a mechanism first.

The priorities mention= ed in -overview are of the #1 kind.=C2=A0 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 usesQUIC.

A QUIC implementation SHOULD provide ways in which an applic= ation can indicate
the relative priority of streams. When deciding which= streams to dedicate
resources to, the implementation SHOULD use the inf= ormation provided by the
application.
"""

Besid= es, I don't believe we can avoid defining a write scheduling mechanism = in
the API.=C2=A0 QUIC itself treats it as an implementation detail, but= Web APIs
generally try really hard to avoid implementation-defined beha= vior.=C2=A0 If
every browser had a completely different write scheduling= approach,
that could make the job of writing performant cross-browser c= ode really
difficult.

Thanks,
=C2= =A0 Victor.
--000000000000f7da25059de88055-- From nobody Thu Feb 6 05:48:06 2020 Return-Path: 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 B23941208A9; Thu, 6 Feb 2020 05:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CeUG_ZYoaQ9b; Thu, 6 Feb 2020 05:47:58 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 21BDF120806; Thu, 6 Feb 2020 05:47:58 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id h23so6168024ljc.8; Thu, 06 Feb 2020 05:47:57 -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=UMOXWcKkahrGzyi/uqqYiOmzaLnAOxaCFKGaXKiBpEs=; b=r/VWSsNxbD8Ln8YSeU7B0Bv1zVGa/frOz1uX1AayunAfU9XqVRjmegK3qGXKSp+44e g5SN9WIByi7o7jhxxzYUwYynIkVUht0iO1OHcDyITixUzMExTTMarvR5KdRCGiNBvRp7 qNpGO1TK94uYw6V88GZI1ieXMYIgOB2SBdCLlQ7hRdGDm7/8BWM1lxzFoySHqLSmWyCm hi9B42HDHLdeOmPUxqX+W3U8Khh5bCnTKOuK5Ose2B+X3ihl/AVYjgkE/Di5TWDmnmAK XCu8S2bNUx3Fduvj/3mcC2ss9fSebXdFUWBON1ToxHJvQhdI5DrmeS4tL+NrxSC4+qhg c0Eg== 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=UMOXWcKkahrGzyi/uqqYiOmzaLnAOxaCFKGaXKiBpEs=; b=R3LbhpBxgQ2wlPGgeqeLpqFaHqONudoygV+3f0MMy00a9hIxEWzroRGJXcK2fWGwsR hPRkY5u53Q1400Y80lHPWhmynAo2WAR+Al7JR21ulLTwxhCPRylAuDbwe52Hi/fsesPr uaCLi/hzdy1l0rmBx/MjrrRITkdo9KicYwVxcIytJaVnpxlcItmF3KXodsO4XEiR9Kk7 E4Os5f7cNyMg3g+U7iEapyDqUZ0LC9sTaZU+NiRo6zYppP7oBtHWicwSD+yt8RnA8r+J kIrr8JQ/I4ow8Ke5lmX++xOebQ7uyXy03ww1USWHlBVH5V0WYN+O706nZwDeeWVT2OFY dfaw== X-Gm-Message-State: APjAAAVvgqY2QnJtjxXAH1MGipVRvMk+4JtoGtBbBvznWG6P4MgpKJ0E WOB37b+T9aNLUiGVzFrcntSPfOmhCpnf/z6Ug9E= X-Google-Smtp-Source: APXvYqxVlOEOfYX8sbutSHyvVG3EKbb/vP3IDinx2RpMK14S08fvqyi0jGxM2fqrZNY2T1YZKLGepBaWUQ7J3Cqs9wU= X-Received: by 2002:a2e:b8d0:: with SMTP id s16mr1979386ljp.32.1580996876325; Thu, 06 Feb 2020 05:47:56 -0800 (PST) MIME-Version: 1.0 References: <158091329253.12815.9369576484605200664.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Thu, 6 Feb 2020 14:47:45 +0100 Message-ID: To: Alissa Cooper Cc: IESG , WebTransport , webtrans-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000003455a6059de8855f" Archived-At: Subject: Re: [Webtransport] Alissa Cooper's Block on charter-ietf-webtrans-00-00: (with BLOCK) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 13:48:01 -0000 --0000000000003455a6059de8855f Content-Type: text/plain; charset="UTF-8" Thank you. We'll send out updated text soon, probably tomorrow due to time zone differences. David On Thu, Feb 6, 2020 at 2:42 PM Alissa Cooper wrote: > > > On Feb 6, 2020, at 8:36 AM, David Schinazi > wrote: > > Hi Alissa, thank you for the review - responses inline. > > On Wed, Feb 5, 2020 at 3:34 PM Alissa Cooper via Datatracker < > noreply@ietf.org> wrote: > >> Alissa Cooper 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: >> ---------------------------------------------------------------------- >> >> Based on the responses to Magnus' comment I think there are two issues to >> sort >> out before proceeding further. >> >> 1) Whether the API is creating requirements for the protocol, or the >> protocol >> is creating requirements for the API. The charter is written as if the >> situation is the former, but the list mail points towards the latter. The >> charter should be clear about this before it goes out for external review. >> > > The intention is for the API to create requirements on the protocol. > We'll clarify the text to make this more explicit. > > 2) It sounds like there is still some chance that the change control for >> the >> API shifts from the W3C to the WHATWG. Would this group re-charter (or >> close) >> if that happens, or would it be better to make the charter more >> generically >> tied to the API but not to its change controller? >> > > That's a good point. We'll replace all mentions of "W3C" with something > like > "the owner of the API". That way, the details of interactions between W3C > and WHATWG (and also internal changes in those organizations) become > opaque to this WG. > > >> Please keep the IESG on cc on all replies. Thanks. >> > > Would these edits be satisfactory? > > > Yes, thanks. > Alissa > > > Thanks, > David > > > > --0000000000003455a6059de8855f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you. We'll send out updated text soon, probably = tomorrow
due to time zone differences.

David

On Thu, Feb 6, 2020 at 2:42 PM Alissa Cooper <alissa@cooperw.in> wrote:
=

On Feb 6, 2020, at 8:36 AM, Dav= id Schinazi <dschinazi.ietf@gmail.com> wrote:

<= div dir=3D"ltr">Hi Alissa, thank you for the review - responses inline.
On W= ed, Feb 5, 2020 at 3:34 PM Alissa Cooper via Datatracker <noreply@ietf.org> wrote:
=
Alissa Cooper has e= ntered 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:
----------------------------------------------------------------------

Based on the responses to Magnus' comment I think there are two issues = to sort
out before proceeding further.

1) Whether the API is creating requirements for the protocol, or the protoc= ol
is creating requirements for the API. The charter is written as if the
situation is the former, but the list mail points towards the latter. The charter should be clear about this before it goes out for external review.<= br>

The intention is for the API to create = requirements on the protocol.
We'll clarify the text to make = this more explicit.

2) It sounds like there is still some chance that the change control for th= e
API shifts from the W3C to the WHATWG. Would this group re-charter (or clos= e)
if that happens, or would it be better to make the charter more generically=
tied to the API but not to its change controller?

=
That's a good point. We'll replace all mentions of "= ;W3C" with something like
"the owner of the API". = That way, the details of interactions between W3C
and WHATWG (and= also internal changes in those organizations) become
opaque to t= his WG.
=C2=A0
Please keep the IESG on cc on all replies. Thanks.
Would these edits be satisfactory?

Yes, thanks.
Alissa

Thanks,
David
=C2=A0

--0000000000003455a6059de8855f-- From nobody Thu Feb 6 07:08:34 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2043F12006D; Thu, 6 Feb 2020 07:08:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158100171009.8530.1367848640419613812.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 07:08:30 -0800 Archived-At: Subject: [Webtransport] Benjamin Kaduk's No Objection on charter-ietf-webtrans-00-00: (with COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 15:08:30 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-webtrans-00-00: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Do we have a target security level (e.g., "the same as HTTPS with TLS 1.3") that we want this work to provide? From nobody Fri Feb 7 01:19:51 2020 Return-Path: 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 E7AF3120043; Fri, 7 Feb 2020 01:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Mf6hOQ34pZcf; Fri, 7 Feb 2020 01:19:44 -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 4A230120041; Fri, 7 Feb 2020 01:19:44 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id n18so1338354ljo.7; Fri, 07 Feb 2020 01:19:44 -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=GK8rVPr4DSE/3Oci2Nuzf3O3cAofSzFIe+e9TF/KT/M=; b=YnbPvlA6LUOazKODjOGpHkm7hxZh1xKQ2sJwFIgijayC1sMLinlH5HJTPq8xeuVXmn m3412UpJq8S0JO94L2stjukeowRWteMhwVEUNQiQfzweIa3jAeG/cIKZy9BJRScQG4n0 CSY0DPwYLPW1uZ/tsRUARSBb/QIIu6jS3cq0J26brhAyOiu+LRn/5D+Kx9tbCottcKXj NWjZCAaHvLbfJIrg7UJFMadEqGpy/86FeLvPo0f0WAJgMw5Q6SlS8bBMEwbYtLpIMG07 Be+wCZ5cGHvQ4skFPuSWWSbfYLWRRuP4KM7O7Tq9JFNPDgk7wDsrF+GYwBamSeH1gd8w SMIg== 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=GK8rVPr4DSE/3Oci2Nuzf3O3cAofSzFIe+e9TF/KT/M=; b=WHOhARrsJMIvpxLjt4Y9CxH7+Lm1e5xdiPKvMjH9vtV+B+5XcHLM+1W1xVKJtvG0CA oON0znJKc4TnOhenqxXeR7v/dMFpeUr3+zzTfL2t3MZPCynb49wyE4avmfymLVkiTJXA YbEhkQfh0v853hWigkDX4R0OprP3vcnOzoAJeLs4w2TTYQ57Tys66HTkqkWRbleyV85U kKy6OpxWRvg/KablXiCLjvvZLcRU0Jn+N2QMZ1aWCJu0kLk3TMTiQRdksQFoRzd95KNO A4WWrIfLO2s2CoyNKyUBAxHTnWWWaKdhwit4oD7yD5IFcoLAKpiJzehb0pLq8GgY2OOk HKcg== X-Gm-Message-State: APjAAAUCer7YOn2YCAHiBnwaSCkg7ON5YQ79MCfHcsG9yuqsrzLAm64q sunf1m78/a180HmsvdH8ob/BXrhl37urSnITwRg= X-Google-Smtp-Source: APXvYqxV9z3o2fvtYGABFQBYMZgMOocYDYDglLbDJoLOwhwOmJPro/nRHz4Q+QbJtIShM8GNm28H7zt9+xq1+8S9qsM= X-Received: by 2002:a2e:5854:: with SMTP id x20mr4474920ljd.287.1581067182424; Fri, 07 Feb 2020 01:19:42 -0800 (PST) MIME-Version: 1.0 References: <158100171009.8530.1367848640419613812.idtracker@ietfa.amsl.com> In-Reply-To: <158100171009.8530.1367848640419613812.idtracker@ietfa.amsl.com> From: David Schinazi Date: Fri, 7 Feb 2020 10:19:31 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , WebTransport , webtrans-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c647dd059df8e3cd" Archived-At: Subject: Re: [Webtransport] Benjamin Kaduk's No Objection on charter-ietf-webtrans-00-00: (with COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 09:19:47 -0000 --000000000000c647dd059df8e3cd Content-Type: text/plain; charset="UTF-8" Hi Ben, Since we'll be using existing transport/security protocols (QUIC or TLS/TCP), we will derive our security level from what they provide. - QUIC provides the same level as HTTPS over TLS 1.3 - TLS/TCP provides as much as the version of TLS in use. The working group might decide to require TLS 1.3 or greater when defining anything over TLS/TCP, but I don't think we need that in the charter? David On Thu, Feb 6, 2020 at 4:08 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > charter-ietf-webtrans-00-00: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Do we have a target security level (e.g., "the same as HTTPS with TLS 1.3") > that we want this work to provide? > > > --000000000000c647dd059df8e3cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Since we'll be using existi= ng transport/security protocols (QUIC or TLS/TCP),
we will derive= our security level from what they provide.
- QUIC provides the s= ame level as HTTPS over TLS 1.3
- TLS/TCP provides as much as the= version of TLS in use.
The working group might decide to require= TLS 1.3 or greater
when defining anything over TLS/TCP, but I do= n't think we need that
in the charter?

David


On Thu, Feb 6, 2020 at 4:08 PM Benjamin Kaduk= via Datatracker <noreply@ietf.org> wrote:
Be= njamin Kaduk has entered the following ballot position for
charter-ietf-webtrans-00-00: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Do we have a target security level (e.g., "the same as HTTPS with TLS = 1.3")
that we want this work to provide?


--000000000000c647dd059df8e3cd-- From nobody Fri Feb 7 06:58:08 2020 Return-Path: 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 3B0C812029C; Fri, 7 Feb 2020 06:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 7CKbUQMAZ-0C; Fri, 7 Feb 2020 06:58:03 -0800 (PST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 0B98F12008A; Fri, 7 Feb 2020 06:58:03 -0800 (PST) Received: by mail-io1-f44.google.com with SMTP id z193so2511532iof.1; Fri, 07 Feb 2020 06:58:03 -0800 (PST) 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=TM/BxdC4LUWEbs91DobsgWhl7kcFKnLJKy8xuSbCdY4=; b=rB4NgfFAuO0yXPbTN1muXK5ofgQfB4ZAzQimg+TTh0LeoJ3TChMXP1F57ZsGo+AhBj W0IAKNCBFWLZiuHv2yuBmY8UmCBAONgnxY3Tg7WMZrOuSHlaxHWJnMPkaq0z0y4HLCB8 zf9hR2xbpHpbcELxmHWWXntZluYv2NPvpUCxkW49myHSbENvtAaHSHPR07ig9JBEXqMW DFS9rpWAzPKdf30eyGYG6Ij5CfVpRH2m1Eut+CrdT6pJAN8261XkN98XJ9SmAyPgw6TJ nUSKVHPfabJEmBqYBFwKJPVDT+4fRjs4vcQwsiOosdukzA/IwhbHleTubjHMP2DU0DBE Z3yg== X-Gm-Message-State: APjAAAXnwKTGuAdBpeOvOC5R8iJeutJwQ/csC5EGVRoO0rfXc5qrDU4a mYZuiJOLYpi2ZSF/AXEJN2ApT2x6NqdXWmbUtGyaUfpQ X-Google-Smtp-Source: APXvYqyF9ch5jhZFPTAcHSCGNMtjNeR+gsHwgTKOEfLrSezFQ9BsIlRo06LAdfSkMdvA8PlZGZnBxq5iu9nEeOgtyuM= X-Received: by 2002:a5d:9ed4:: with SMTP id a20mr3271472ioe.187.1581087482266; Fri, 07 Feb 2020 06:58:02 -0800 (PST) MIME-Version: 1.0 References: <158100171009.8530.1367848640419613812.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Fri, 7 Feb 2020 09:57:50 -0500 Message-ID: To: David Schinazi Cc: Benjamin Kaduk , webtrans-chairs@ietf.org, WebTransport , The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Webtransport] Benjamin Kaduk's No Objection on charter-ietf-webtrans-00-00: (with COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 14:58:04 -0000 >> Do we have a target security level (e.g., "the same as HTTPS with TLS 1.3") >> that we want this work to provide? > > Since we'll be using existing transport/security protocols (QUIC or TLS/TCP), > we will derive our security level from what they provide. > - QUIC provides the same level as HTTPS over TLS 1.3 > - TLS/TCP provides as much as the version of TLS in use. > The working group might decide to require TLS 1.3 or greater > when defining anything over TLS/TCP, but I don't think we need that > in the charter? I agree that we don't need it in the charter. The chairs are certainly aware of the situation, and if I document came out that, say, suggested 1.1, I'm sure the Sec ADs would DISCUSS that. Barry From nobody Sat Feb 8 10:49:37 2020 Return-Path: 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 ADB7412004E; Sat, 8 Feb 2020 10:49:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vWM2B0QdsZYt; Sat, 8 Feb 2020 10:49:33 -0800 (PST) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 B861A1200B1; Sat, 8 Feb 2020 10:49:33 -0800 (PST) Received: by mail-vs1-xe31.google.com with SMTP id t12so1659366vso.13; Sat, 08 Feb 2020 10:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=/ARAm+G2s1G9ZOvF1/Fu/9LaaojRh5Uua0vJpWB3SNs=; b=XlcUMWVg3ai0HB3qyNo33TLEe3sLpiOuJYW3ycwMSauKsmvrDIhJjY00K7SJgBnrDy oiBGxUrEu3FwTRHRzoLKr/Nr6whWs9CIIpOMht1wPw5ele5uapNKlbrl4/OEy0kZ9I3F 4uGjSq8VY7xDYjVCdf3C4z9ezz3iFgOM1XtNecxUd4Z/Pk4tjOgXmuFdGGFH+hIIUBTQ 4Yzk1tmL8u5AgGy7OeJEn9MfLy7BNecR8kR6YbUOj0NX7OMRjW00bAwdR4fgoI2VFzhM bWFZO8oIQh4ZWnJO6hTbpDztpOPzdUldt3C9ygb7nBuyM6caDGd7jd6DR6Y7gCTQlQq9 69Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=/ARAm+G2s1G9ZOvF1/Fu/9LaaojRh5Uua0vJpWB3SNs=; b=k1xzqIj+MV3a03cJ46tpi2MBnOVM6/EjC1TRp3Bd7r+1pNn0CChIYuwy73fBHn46cQ Aec7H6/at6gA0kRn9yIX5an/DYyiRwBibKwqcro5GCYsGGYArboX5S/YUFUekv4ozBu0 bt8F3SLfFR2WpyCaKvqNZwCeI6UOub5wIqQWBAbvwn2dmgqzvIjJwRSmI/BmF0WYr8+V 48R7J6wPu+Mld8cPIQPgcDzyr1pylxGcWT8vncrtDFiB2pIAwrygmR7CfYbEitJkPFRl W3w7EdXd6VmdIn+/bg5nvOj9gIIOGVJaYjy1+xqhnLJgVGpOZSndNBp2dluqxS59nk8b md9w== X-Gm-Message-State: APjAAAVMz2A9qyb0ZFEFDnrnjzXVl4s7pPtkSRt85lRJ+BV5sq8vUQnn fnjDZi2CVhvew9U8gtsSZqkOWy8ivvYwPtkqgmzDQJQL X-Google-Smtp-Source: APXvYqwNpiFnQX83jmlbVuWgfBRbmtivzlWKwKXnqXnDkL2YeIQGIl0D4E9qbu2H+N95RjceY5kzC4/g0wC/A7+pgeM= X-Received: by 2002:a67:2c15:: with SMTP id s21mr2437624vss.104.1581187772290; Sat, 08 Feb 2020 10:49:32 -0800 (PST) MIME-Version: 1.0 From: Bernard Aboba Date: Sat, 8 Feb 2020 10:49:21 -0800 Message-ID: To: webtransport@ietf.org Cc: The IESG Content-Type: multipart/alternative; boundary="0000000000007d9cc5059e14f747" Archived-At: Subject: [Webtransport] Updated Proposal WEBTRANS WG Charter X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2020 18:49:36 -0000 --0000000000007d9cc5059e14f747 Content-Type: text/plain; charset="UTF-8" To address IESG comments, we have updated the proposed WEBTRANS WG Charter: https://github.com/DavidSchinazi/webtrans-wg-materials/blob/master/charter.md The revision is enclosed below. Description of Working Group The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport API https://quic.rocks/webtransport-api. The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of reliable messages. Attention will be paid to the performance of the protocol, in particular protocol overhead and the potential for head-of-line blocking; its ability to be deployed and used reliably under different network conditions; and the ability to integrate the protocol into the Web security model. The working group will not define new transport protocols but will instead use existing protocols such as QUIC and TLS/TCP. The group will pay attention to security issues arising from the above scenarios so as to ensure against creation of new modes of attack. To assist in the coordination with the owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. This will include requirements arising from the WebTransport API. Feedback will also be solicited at various points along the way in order to ensure the best possible match between the protocol work and the needs of the WebTransport API. The group will also coordinate with other working groups within the IETF (e.g. QUIC, HTTPBIS, TLS) as appropriate. In particular, any changes to these core protocols shall be discussed in their respective working groups. The WebTransport working group may define extensions to these protocols, but any working group last call defining such extensions shall also be sent to the mailing list of the respective working group. Goals and Milestones - March 2020 - Adopt a WebTransport Overview draft as a WG work item - March 2020 - Adopt a draft defining a WebTransport protocol as a WG work item - October 2020 - Issue WG last call of the WebTransport Overview document. - January 2021 - Issue WG last call on the first WebTransport protocol document --0000000000007d9cc5059e14f747 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To address IESG comments, we have updated the proposed WEB= TRANS WG Charter:

Th= e revision is enclosed below.=C2=A0

Description of Working Group

The WebTra= nsport working group will define new client-server protocols or protocol ex= tensions in order to support the development of the WebTransport API=C2=A0<= a href=3D"https://quic.rocks/webtransport-api" rel=3D"nofollow" style=3D"bo= x-sizing:border-box;background-color:initial;color:rgb(3,102,214);text-deco= ration-line:none">https://quic.rocks/webtransport-api.

The WebTransport working group will define an application-layer prot= ocol or suite of application-layer protocols that support a range of simple= communication methods. These must include unreliable messages (that might = be limited by the path MTU), reliable messages, and ordered streams of reli= able messages. Attention will be paid to the performance of the protocol, i= n particular protocol overhead and the potential for head-of-line blocking;= its ability to be deployed and used reliably under different network condi= tions; and the ability to integrate the protocol into the Web security mode= l. The working group will not define new transport protocols but will inste= ad use existing protocols such as QUIC and TLS/TCP.

= The group will pay attention to security issues arising from the above scen= arios so as to ensure against creation of new modes of attack.

To assist in the coordination with the owners of the WebTranspo= rt API, the group will initially develop an overview document containing us= e cases and requirements in order to clarify the goals of the effort. This = will include requirements arising from the WebTransport API. Feedback will = also be solicited at various points along the way in order to ensure the be= st possible match between the protocol work and the needs of the WebTranspo= rt API.

The group will also coordinate with other wo= rking groups within the IETF (e.g. QUIC, HTTPBIS, TLS) as appropriate. In p= articular, any changes to these core protocols shall be discussed in their = respective working groups. The WebTransport working group may define extens= ions to these protocols, but any working group last call defining such exte= nsions shall also be sent to the mailing list of the respective working gro= up.

Goals and Milestones

  • March 2020 - Adopt a WebTransport Overview draf= t as a WG work item
  • March 2020 - Adopt a draft defining a WebTransport protocol as a WG work= item
  • October 202= 0 - Issue WG last call of the WebTransport Overview document.
  • January 2021 - Issue WG last c= all on the first WebTransport protocol document
--0000000000007d9cc5059e14f747-- From nobody Tue Feb 11 04:38:37 2020 Return-Path: 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 53BD712011E; Tue, 11 Feb 2020 04:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 HwjzlV5XWowK; Tue, 11 Feb 2020 04:38:15 -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 7BDFF1200E5; Tue, 11 Feb 2020 04:38:15 -0800 (PST) Received: from 200116b82c13d0007056c073a2e217e4.dip.versatel-1u1.de ([2001:16b8:2c13:d000:7056:c073:a2e2:17e4]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j1Unu-0004Nx-46; Tue, 11 Feb 2020 13:38:14 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 11 Feb 2020 13:38:13 +0100 Cc: Magnus Westerlund , Victor Vasiliev , WebTransport , The IESG , webtrans-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6737DF56-514D-48CB-8FEB-E0F6747578A6@kuehlewind.net> References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581424695;c6211611; X-HE-SMSGID: 1j1Unu-0004Nx-46 Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 12:38:19 -0000 Hi David, One more comment below. > On 6. Feb 2020, at 14:46, David Schinazi = wrote: >=20 > Hi Magnus, >=20 > I realized that some of our earlier replies were accidentally not sent = to > the IESG list, for which I apologize. >=20 > To summarize that discussion: >=20 > - 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 >=20 > - 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=E2=80=99m 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=E2=80=99t 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=E2=80=A6? Mirja >=20 > Would that be an acceptable scope? >=20 > Thanks, > David >=20 > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev = 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. >=20 > On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker = wrote: > Magnus Westerlund has entered the following ballot position for > charter-ietf-webtrans-00-00: Block >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > =20 > [snip] >=20 > The group will also coordinate with related working groups within the = IETF, > such as QUIC and HTTPBIS, as appropriate. >=20 > 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. >=20 > 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. > =20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > 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. >=20 > 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. > =20 > 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. >=20 > 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. > =20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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: >=20 > """ > [QUIC] relies on receiving priority information from the application = that uses > QUIC. >=20 > 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. > """ >=20 > 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. >=20 > Thanks, > Victor. > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Tue Feb 11 04:41:38 2020 Return-Path: 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 4AF4212011E; Tue, 11 Feb 2020 04:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 AJrwQaSIDNKU; Tue, 11 Feb 2020 04:41:31 -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 89B8C1200E5; Tue, 11 Feb 2020 04:41:31 -0800 (PST) Received: from 200116b82c13d0007056c073a2e217e4.dip.versatel-1u1.de ([2001:16b8:2c13:d000:7056:c073:a2e2:17e4]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j1Ur2-0007Kg-LR; Tue, 11 Feb 2020 13:41:28 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <158099396631.12409.17485421597898405142.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2020 13:41:27 +0100 Cc: The IESG , webtrans-chairs@ietf.org, webtransport@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <158099396631.12409.17485421597898405142.idtracker@ietfa.amsl.com> To: =?utf-8?Q?=C3=89ric_Vyncke?= X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581424891;35644cf5; X-HE-SMSGID: 1j1Ur2-0007Kg-LR Archived-At: Subject: Re: [Webtransport] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_ch?= =?utf-8?q?arter-ietf-webtrans-00-00=3A_=28with_COMMENT=29?= X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 12:41:33 -0000 Hi Eric, hi all, I believe the assumption is that this work will not modify any transport = protocol but only =E2=80=9Cuse" it. In this case it looks like an = application protocol. Further websockets was in ART and this work seems = similar. However, if my assumption are wrong, I=E2=80=99m happy to = discuss if TSV is more appropriate! Mirja > On 6. Feb 2020, at 13:59, =C3=89ric Vyncke via Datatracker = wrote: >=20 > =C3=89ric Vyncke has entered the following ballot position for > charter-ietf-webtrans-00-00: No Objection >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I will follow the discussion around the BLOCK points of my fellow AD = but I > wonder why this is in ART and not in TSV? >=20 > -=C3=A9ric >=20 >=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Tue Feb 11 12:47:05 2020 Return-Path: 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 DCBA912006F; Tue, 11 Feb 2020 12:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GiRFE8c_cLdJ; Tue, 11 Feb 2020 12:46:52 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 05D6E120A70; Tue, 11 Feb 2020 12:46:52 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id f24so8031742lfh.3; Tue, 11 Feb 2020 12:46:51 -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=zZJtMrkCGPYLMlAJ5JNWuI/L/5QVaCjfyM6Q1nuxGZI=; b=Egcg1eNW/sxw+9mZyaAQEr9ctprx1ANcodqk0TU3cDeh8ZF7ZOBFxGx53b+LF83g/J 4zqXeec0VBvB6LcRa4ODmTI0/pmBT4aQlHJoSKEusGP/cXhCfuTUb9eVTHuwupMZwMHE hRsWyNe+rh5BSpHAxOuHgW0Aw6HtgszrOM7dy7MALfBDvGdDUdjp6Ifzt5kfWa+wC3/r 16hGRBzZFsO32oWB2lq46qXNw+8eJHaAyxe0NqnBVQNDExUVgH5jPr+lLlqT55JixigH C5OMM6fUy10myh6Bw3rlMByJmJucfxN1aU9VuD4z+rNO/RUSTALd9ZZo/ov4Wzm14EF2 TeBA== 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=zZJtMrkCGPYLMlAJ5JNWuI/L/5QVaCjfyM6Q1nuxGZI=; b=RrTEwPqHGOJLCZorigfYlVXAXGSz4FMWLNbdnHUL1G5HQCsGgh5UCMpyst8qKufCQm keyjbY6kpcwW+HJhKz0QMsCbeLfZWAdi1/ytrR7o5rek7VnpY6h5IQW4ua6savZI0xpU jvdGKLC3+loaXQKylnnhx7NGk/Ytm5yZzbTs92PR8iq7OCaSMHAcG6tUweDsGCxArm1k VMjnPTG3GzSGvq1KlyAoKDfMBeFeywjTyB16h425l6oyDDG68VmLAQ9FzrX+wK4yHRFT hq4YPZ8Mszn9pr+Enc+WC68SttYXtjpaix5x/T8jbqDUXJaRSYlPMB9gh+ljDZQ+RKFU BhPQ== X-Gm-Message-State: APjAAAUHliFhEa0XD7ZBdUz3g6PuqGoMUWV32Hu4kzae3tETPBBdTGcL ZgggBjX0sk5+BuX1leDfXR/jyAfpHGtS/hAOn/U= X-Google-Smtp-Source: APXvYqz2lxc/rl1GFaKi5Yb2065qDRopf++AntsRGV2t4JcBrGQD58mx5gCM77Nn12Tdj9SoC30SkuxPXeAK8mxQn7c= X-Received: by 2002:a19:8b89:: with SMTP id n131mr4665613lfd.14.1581454010184; Tue, 11 Feb 2020 12:46:50 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> <6737DF56-514D-48CB-8FEB-E0F6747578A6@kuehlewind.net> In-Reply-To: <6737DF56-514D-48CB-8FEB-E0F6747578A6@kuehlewind.net> From: David Schinazi Date: Tue, 11 Feb 2020 12:46:39 -0800 Message-ID: To: Mirja Kuehlewind Cc: Magnus Westerlund , Victor Vasiliev , WebTransport , The IESG , webtrans-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000817a06059e52f4f9" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 20:46:58 -0000 --000000000000817a06059e52f4f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi David, > > One more comment below. > > > On 6. Feb 2020, at 14:46, David Schinazi > 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=E2=80=99m 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=E2=80=99t mean that thi= s 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 ada= pt > 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=E2=80=A6? > > Mirja > > > > > > > Would that be an acceptable scope? > > > > Thanks, > > David > > > > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev > 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 th= e > > intended HTTP extensibility mechanism). I've hitherto assumed that > webtrans > > would work with HTTP experts in httpbis/quic to ensure that the propose= d > > 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. Tryin= g > 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 th= e > W3C > > spec currently do not believe we have enough real-world implementation > > experience with the proposal to advance it further in the formal proces= s. > > > > 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 appear= s > to > > support multiple parallel transmissions and transfers I think at a > minimal a > > sender transport protocol scheduling or HTTP/3 priority would be likel= y > 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 woul= d > 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 tw= o > types > > of priorities here, and those are often confused: > > (1) Priorities that the application indicates to the transport layer fo= r > 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 (tha= t > 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 dedica= te > > 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 AP= Is > > 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 > > --000000000000817a06059e52f4f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

I'm not sure I agree with= your interpretation. The fact that a WG is
responsible for a pro= tocol does not mean that other working groups
cannot write extens= ions to that protocol.

For example, the QUIC WG is= defining the=C2=A0quic_transport_parameters
TLS extension. That = extension is not defined in the TLS WG.

Simi= larly, the ACME WG is defining the=C2=A0Cert-Not-Before HTTP
head= er, not the HTTP WG.

Additionally, MPTCP i= s an extension to TCP that=C2=A0was not
defined in the TCPM WG. T= he list goes on.

We don't yet have examples fo= r QUIC as the QUIC IANA
registries haven't been created yet, = but I don't see why QUIC
would be different from TLS, HTTP, o= r TCP.

David


On Tue, Feb 11, 2= 020 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/DavidSchi= nazi/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 n= eeded 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 cha= rter is not appropriate. I=E2=80=99m not sure what the defined process is f= or 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=E2=80=99t mean that this gro= up cannot talk about any extension but as soon as the group thinks an exten= sion is needed, it needs to go to the QUIC group and cannot just adapt anyt= hing within WebTransport.

Please also double-check what the right process is for TLS and HTTP. I assu= me for TLS it's the same but for HTTP it might be different=E2=80=A6?
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= 9;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&= gt; 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter= -ietf-webtrans/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
>=C2=A0
> [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 definit= ion, 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 exten= sions 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 t= he
> intended HTTP extensibility mechanism).=C2=A0 I've hitherto assume= d that webtrans
> would work with HTTP experts in httpbis/quic to ensure that the propos= ed
> extensions are architecturally sound and follow best practices, but th= e main
> bulk of work would be done in the new working group itself.
>=C2=A0
> ----------------------------------------------------------------------=
> 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. Tryi= ng 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 gam= e
> communication where this was discussed and raised in some discussions.=
>
> It's a WICG draft, which basically means no formal status.=C2=A0 W= e had a discussion
> session at TPAC last year, and I believe most people who'd be norm= ally involved
> are aware of it, but my current understanding is that the editors of t= he W3C
> spec currently do not believe we have enough real-world implementation=
> experience with the proposal to advance it further in the formal proce= ss.
>=C2=A0
> Having lived through the WebRTC / RTCWeb interactions it would good to= know
> more how the interaction between the bodies are intended to work. Espe= cially as
> changes to the API can have significant impact on what work needs to h= appen in
> the IETF.
>
> I mostly agree with Bernard here.=C2=A0 My plan was that the -overview= doc would
> list all of the protocol requirements and API expectations, acting as<= br> > integration point between W3C and IETF specs.
>=C2=A0
> The current API draft does not include any discussion of priority. How= ever
> draft-vvv-webtrans-overview does mention priorities. As this API appea= rs to
> support multiple parallel transmissions and transfers I think at a min= imal a
> sender transport protocol scheduling or HTTP/3 priority=C2=A0 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 wou= ld 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.=C2=A0 I've been meaning to w= rite 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 t= wo types
> of priorities here, and those are often confused:
> (1) Priorities that the application indicates to the transport layer f= or the
>=C2=A0 =C2=A0 =C2=A0purpose 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.=C2=A0 I d= on't believe
> any of the proposed drafts cover that topic, and I'd rather wait f= or
> quic/httpbis to come up with a mechanism first.
>
> The priorities mentioned in -overview are of the #1 kind.=C2=A0 Sectio= n 2.3 of
> draft-ietf-quic-transport-25 explicitly encourages implementations (th= at would
> include the proposed Web APIs) to provide those:
>
> """
> [QUIC] relies on receiving priority information from the application t= hat uses
> QUIC.
>
> A QUIC implementation SHOULD provide ways in which an application can = indicate
> the relative priority of streams. When deciding which streams to dedic= ate
> resources to, the implementation SHOULD use the information provided b= y the
> application.
> """
>
> Besides, I don't believe we can avoid defining a write scheduling = mechanism in
> the API.=C2=A0 QUIC itself treats it as an implementation detail, but = Web APIs
> generally try really hard to avoid implementation-defined behavior.=C2= =A0 If
> every browser had a completely different write scheduling approach, > that could make the job of writing performant cross-browser code reall= y
> difficult.
>
> Thanks,
>=C2=A0 =C2=A0Victor.
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--000000000000817a06059e52f4f9-- From nobody Tue Feb 11 12:50:17 2020 Return-Path: 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 ; 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 ; 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 ; Tue, 11 Feb 2020 12:50:09 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id q8so13217480ljb.2 for ; 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> <6737DF56-514D-48CB-8FEB-E0F6747578A6@kuehlewind.net> In-Reply-To: From: Eric Rescorla Date: Tue, 11 Feb 2020 12:49:30 -0800 Message-ID: To: David Schinazi Cc: Mirja Kuehlewind , webtrans-chairs@ietf.org, Magnus Westerlund , WebTransport , The IESG , Victor Vasiliev Content-Type: multipart/alternative; boundary="000000000000402e0f059e5300a7" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 20:50:14 -0000 --000000000000402e0f059e5300a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 > wrote: > >> Hi David, >> >> One more comment below. >> >> > On 6. Feb 2020, at 14:46, David Schinazi >> 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 i= s >> 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 jus= t >> sending a WGLC there is not sufficient. >> >> More generally deciding on processes for other protocols/groups in this >> charter is not appropriate. I=E2=80=99m not sure what the defined proces= s 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=E2=80=99t mean that th= is 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 ad= apt >> 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=E2=80=A6= ? >> >> Mirja >> >> >> >> > >> > Would that be an acceptable scope? >> > >> > Thanks, >> > David >> > >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev >> 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 thi= s >> > 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 t= he >> > intended HTTP extensibility mechanism). I've hitherto assumed that >> webtrans >> > would work with HTTP experts in httpbis/quic to ensure that the propos= ed >> > extensions are architecturally sound and follow best practices, but th= e >> 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 gam= e >> > 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 b= y >> 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. I= f >> > every browser had a completely different write scheduling approach, >> > that could make the job of writing performant cross-browser code reall= y >> > 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 > --000000000000402e0f059e5300a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I basically agree with David. I might argue for a sli= ghtly higher level of implied coordination between the WGs than WGLC, but h= onestly 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,

<= /div>
I'm not sure I agree with your interpretation. The fact that = a WG is
responsible for a protocol does not mean that other worki= ng groups
cannot write extensions to that protocol.
For example, the QUIC WG is defining the=C2=A0quic_transport_pa= rameters
TLS extension. That extension is not defined in the TLS = WG.

Similarly, the ACME WG= is defining the=C2=A0Cert-Not-Before HTTP
header, not the HTTP W= G.

Additionally, MPTCP i= s an extension to TCP that=C2=A0was not
defined in the TCPM WG. T= he list goes on.

We don't yet have examples fo= r QUIC as the QUIC IANA
registries haven't been created yet, = but I don't see why QUIC
would be different from TLS, HTTP, o= r TCP.

David


On Tue, Feb 11, 2= 020 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/DavidSchi= nazi/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 n= eeded 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 cha= rter is not appropriate. I=E2=80=99m not sure what the defined process is f= or 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=E2=80=99t mean that this gro= up cannot talk about any extension but as soon as the group thinks an exten= sion is needed, it needs to go to the QUIC group and cannot just adapt anyt= hing within WebTransport.

Please also double-check what the right process is for TLS and HTTP. I assu= me for TLS it's the same but for HTTP it might be different=E2=80=A6?
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= 9;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&= gt; 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter= -ietf-webtrans/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
>=C2=A0
> [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 definit= ion, 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 exten= sions 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 t= he
> intended HTTP extensibility mechanism).=C2=A0 I've hitherto assume= d that webtrans
> would work with HTTP experts in httpbis/quic to ensure that the propos= ed
> extensions are architecturally sound and follow best practices, but th= e main
> bulk of work would be done in the new working group itself.
>=C2=A0
> ----------------------------------------------------------------------=
> 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. Tryi= ng 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 gam= e
> communication where this was discussed and raised in some discussions.=
>
> It's a WICG draft, which basically means no formal status.=C2=A0 W= e had a discussion
> session at TPAC last year, and I believe most people who'd be norm= ally involved
> are aware of it, but my current understanding is that the editors of t= he W3C
> spec currently do not believe we have enough real-world implementation=
> experience with the proposal to advance it further in the formal proce= ss.
>=C2=A0
> Having lived through the WebRTC / RTCWeb interactions it would good to= know
> more how the interaction between the bodies are intended to work. Espe= cially as
> changes to the API can have significant impact on what work needs to h= appen in
> the IETF.
>
> I mostly agree with Bernard here.=C2=A0 My plan was that the -overview= doc would
> list all of the protocol requirements and API expectations, acting as<= br> > integration point between W3C and IETF specs.
>=C2=A0
> The current API draft does not include any discussion of priority. How= ever
> draft-vvv-webtrans-overview does mention priorities. As this API appea= rs to
> support multiple parallel transmissions and transfers I think at a min= imal a
> sender transport protocol scheduling or HTTP/3 priority=C2=A0 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 wou= ld 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.=C2=A0 I've been meaning to w= rite 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 t= wo types
> of priorities here, and those are often confused:
> (1) Priorities that the application indicates to the transport layer f= or the
>=C2=A0 =C2=A0 =C2=A0purpose 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.=C2=A0 I d= on't believe
> any of the proposed drafts cover that topic, and I'd rather wait f= or
> quic/httpbis to come up with a mechanism first.
>
> The priorities mentioned in -overview are of the #1 kind.=C2=A0 Sectio= n 2.3 of
> draft-ietf-quic-transport-25 explicitly encourages implementations (th= at would
> include the proposed Web APIs) to provide those:
>
> """
> [QUIC] relies on receiving priority information from the application t= hat uses
> QUIC.
>
> A QUIC implementation SHOULD provide ways in which an application can = indicate
> the relative priority of streams. When deciding which streams to dedic= ate
> resources to, the implementation SHOULD use the information provided b= y the
> application.
> """
>
> Besides, I don't believe we can avoid defining a write scheduling = mechanism in
> the API.=C2=A0 QUIC itself treats it as an implementation detail, but = Web APIs
> generally try really hard to avoid implementation-defined behavior.=C2= =A0 If
> every browser had a completely different write scheduling approach, > that could make the job of writing performant cross-browser code reall= y
> difficult.
>
> Thanks,
>=C2=A0 =C2=A0Victor.
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000402e0f059e5300a7-- From nobody Tue Feb 11 13:31:17 2020 Return-Path: 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 1A84C12081A; Tue, 11 Feb 2020 13:31:11 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 RTIOPlOBDqsJ; Tue, 11 Feb 2020 13:31:06 -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 5D204120018; Tue, 11 Feb 2020 13:31:06 -0800 (PST) Received: from i59f7ff35.versanet.de ([89.247.255.53] helo=[192.168.178.46]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j1d7S-0000NC-Rn; Tue, 11 Feb 2020 22:30:59 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-8056B612-A9AC-495B-B6D8-0B7792620D30 Content-Transfer-Encoding: 7bit From: =?utf-8?Q?"Mirja_K=C3=BChlewind_=28IETF=29"?= Mime-Version: 1.0 (1.0) Date: Tue, 11 Feb 2020 22:30:57 +0100 Message-Id: References: Cc: webtrans-chairs@ietf.org, Magnus Westerlund , WebTransport , The IESG , Victor Vasiliev In-Reply-To: To: David Schinazi X-Mailer: iPhone Mail (17C54) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581456666;a5a43896; X-HE-SMSGID: 1j1d7S-0000NC-Rn Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 21:31:11 -0000 --Apple-Mail-8056B612-A9AC-495B-B6D8-0B7792620D30 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi David, I didn=E2=80=99t say that other groups cannot define extension. I did say th= at it=E2=80=99s the decision of the working group that maintains the protoco= l how to handle that and for Quic we didn=E2=80=99t have had that discussion= yet.=20 Examples for groups that explicitly define process for extending the protoco= l in their charter are dhc and 6man. As you can see different groups/protoco= ls have different process and as we didn=E2=80=99t define anything yet for Q= uic, the working assumption for now should be that all extension work will b= e fine in the Quic group. Mirja > Am 11.02.2020 um 21:47 schrieb David Schinazi : >=20 > =EF=BB=BF > Hi Mirja, >=20 > 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. >=20 > 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 >=20 > 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 >=20 > Additionally, MPTCP is an extension to TCP that was not > defined in the TCPM WG. The list goes on. >=20 > 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. >=20 > David >=20 >=20 >> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind wr= ote: >> Hi David, >>=20 >> One more comment below. >>=20 >> > On 6. Feb 2020, at 14:46, David Schinazi wro= te: >> >=20 >> > Hi Magnus, >> >=20 >> > I realized that some of our earlier replies were accidentally not sent t= o >> > the IESG list, for which I apologize. >> >=20 >> > To summarize that discussion: >> >=20 >> > - 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 >> >=20 >> > - 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. >>=20 >> 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 shoul= d be that all extensions will be done within the QUIC group. So just sending= a WGLC there is not sufficient. >>=20 >> More generally deciding on processes for other protocols/groups in this c= harter is not appropriate. I=E2=80=99m not sure what the defined process is f= or HTTP and TLS but that should be specified in their charter and not here. >>=20 >> For QUIC, I would like to rather see that extension or modification are o= ut of scope for this group. Of course that doesn=E2=80=99t mean that this gr= oup cannot talk about any extension but as soon as the group thinks an exten= sion is needed, it needs to go to the QUIC group and cannot just adapt anyth= ing within WebTransport. >>=20 >> Please also double-check what the right process is for TLS and HTTP. I as= sume for TLS it's the same but for HTTP it might be different=E2=80=A6? >>=20 >> Mirja >>=20 >>=20 >>=20 >> >=20 >> > Would that be an acceptable scope? >> >=20 >> > Thanks, >> > David >> >=20 >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev wr= ote: >> > I believe most of those have been addressed in David's PR, so I'll try t= o reply >> > primarily to those that I have something to add to. >> >=20 >> > On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker wrote: >> > Magnus Westerlund has entered the following ballot position for >> > charter-ietf-webtrans-00-00: Block >> >=20 >> > 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.) >> >=20 >> >=20 >> >=20 >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >> >=20 >> >=20 >> >=20 >> > ---------------------------------------------------------------------- >> > BLOCK: >> > ---------------------------------------------------------------------- >> >=20 >> > =20 >> > [snip] >> >=20 >> > The group will also coordinate with related working groups within the I= ETF, >> > such as QUIC and HTTPBIS, as appropriate. >> >=20 >> > With the current state of QUIC developement and HTTP/3 mapping definiti= on, i.e. >> > still working on the initial version, I would like to have a more firm w= ording >> > that the WebTrans WG will actually have to take any requests for extens= ions of >> > HTTP/3 and QUIC to the relevant WG. >> >=20 >> > While there are no extensions to QUIC among the proposed WG documents, s= ome of >> > the drafts do extend HTTP using custom SETTINGS parameters (which is th= e >> > intended HTTP extensibility mechanism). I've hitherto assumed that web= trans >> > would work with HTTP experts in httpbis/quic to ensure that the propose= d >> > extensions are architecturally sound and follow best practices, but the= main >> > bulk of work would be done in the new working group itself. >> > =20 >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> >=20 >> > I also would appreciate if someone can clarify what stage of formality t= he >> > Web-Transport API has been adopted in W3C and is being worked on. Tryin= g to >> > find anything about which group it belongs to on the W3C page didn't gi= ve 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. >> >=20 >> > It's a WICG draft, which basically means no formal status. We had a di= scussion >> > session at TPAC last year, and I believe most people who'd be normally i= nvolved >> > are aware of it, but my current understanding is that the editors of th= e W3C >> > spec currently do not believe we have enough real-world implementation >> > experience with the proposal to advance it further in the formal proces= s. >> > =20 >> > Having lived through the WebRTC / RTCWeb interactions it would good to k= now >> > more how the interaction between the bodies are intended to work. Espec= ially as >> > changes to the API can have significant impact on what work needs to ha= ppen in >> > the IETF. >> >=20 >> > I mostly agree with Bernard here. My plan was that the -overview doc w= ould >> > list all of the protocol requirements and API expectations, acting as >> > integration point between W3C and IETF specs. >> > =20 >> > The current API draft does not include any discussion of priority. Howe= ver >> > draft-vvv-webtrans-overview does mention priorities. As this API appear= s to >> > support multiple parallel transmissions and transfers I think at a mini= mal a >> > sender transport protocol scheduling or HTTP/3 priority would be likel= y to be >> > part of the work. I also have to ask if this is likely to attempted to b= e >> > mapped also towards the network level, for example DSCPs? If any such w= ork is >> > expected and intended I think that needs to be raised. Otherwise I woul= d 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. >> >=20 >> > This is mostly a gap in the API spec. I've been meaning to write this u= p >> > further, but there's a lot of text to write. >> >=20 >> > Before I elaborate further, I would like to point out that there are tw= o types >> > of priorities here, and those are often confused: >> > (1) Priorities that the application indicates to the transport layer fo= r the >> > purpose of scheduling writes. >> > (2) Priorities that are communicated to the peer on the wire as a hint.= . >> >=20 >> > Most of the discussion in HTTPBIS and QUIC WGs was about #2. I don't b= elieve >> > any of the proposed drafts cover that topic, and I'd rather wait for >> > quic/httpbis to come up with a mechanism first. >> >=20 >> > The priorities mentioned in -overview are of the #1 kind. Section 2.3 o= f >> > draft-ietf-quic-transport-25 explicitly encourages implementations (tha= t would >> > include the proposed Web APIs) to provide those: >> >=20 >> > """ >> > [QUIC] relies on receiving priority information from the application th= at uses >> > QUIC. >> >=20 >> > A QUIC implementation SHOULD provide ways in which an application can i= ndicate >> > the relative priority of streams. When deciding which streams to dedica= te >> > resources to, the implementation SHOULD use the information provided by= the >> > application. >> > """ >> >=20 >> > Besides, I don't believe we can avoid defining a write scheduling mecha= nism in >> > the API. QUIC itself treats it as an implementation detail, but Web AP= Is >> > 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. >> >=20 >> > Thanks, >> > Victor. >> > --=20 >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >>=20 --Apple-Mail-8056B612-A9AC-495B-B6D8-0B7792620D30 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi David,

I didn=E2=80=99t say that other groups cann= ot define extension. I did say that it=E2=80=99s the decision of the working= group that maintains the protocol how to handle that and for Quic we didn=E2= =80=99t have had that discussion yet. 

=
Examples for groups that explicitly define process for exte= nding the protocol in their charter are dhc and 6man. As you can see differe= nt groups/protocols have different process and as we didn=E2=80=99t define a= nything yet for Quic, the working assumption for now should be that all exte= nsion work will be fine in the Quic group.

<= div dir=3D"ltr">Mirja


<= blockquote type=3D"cite">Am 11.02.2020 um 21:47 schrieb David Schinazi <d= schinazi.ietf@gmail.com>:

=EF=BB=BF
Hi Mirja,

I'm not sure I agree with your interpretation. The fact that a WG is
<= div>responsible for a protocol does not mean that other working groups
=
cannot write extensions to that protocol.

For e= xample, the QUIC WG is defining the quic_transport_parameters
TLS extension. That extension is not defined in the TLS WG.
<= br>
Similarly, the ACME WG is defining the Cert-Not-Before HT= TP
header, not the HTTP WG.

Additio= nally, MPTCP is an extension to TCP that was not
defined in t= he TCPM WG. The list goes on.

We don't yet have exa= mples for QUIC as the QUIC IANA
registries haven't been created ye= t, but I don't see why QUIC
would be different from TLS, HTTP, or T= CP.

David


On Tue, Feb 11, 2020 at 4= :38 AM Mirja Kuehlewind <ietf@kueh= lewind.net> wrote:
Hi David,

One more comment below.

> On 6. Feb 2020, at 14:46, David Schinazi <dschinazi.ietf@gmail.com> wrote:<= br> >
> Hi Magnus,
>
> I realized that some of our earlier replies were accidentally not sent t= o
> 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/DavidSchina= zi/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 ne= eded in the QUIC group on this but currently I think the assumption should b= e that all extensions will be done within the QUIC group. So just sending a W= GLC there is not sufficient.

More generally deciding on processes for other protocols/groups in this char= ter is not appropriate. I=E2=80=99m 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 o= f scope for this group. Of course that doesn=E2=80=99t mean that this group c= annot talk about any extension but as soon as the group thinks an extension i= s needed, it needs to go to the QUIC group and cannot just adapt anything wi= thin WebTransport.

Please also double-check what the right process is for TLS and HTTP. I assum= e for TLS it's the same but for HTTP it might be different=E2=80=A6?

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 t= o reply
> primarily to those that I have something to add to.
>
> On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker <<= a href=3D"mailto:noreply@ietf.org" target=3D"_blank">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-i= etf-webtrans/
>
>
>
> ----------------------------------------------------------------------<= br> > BLOCK:
> ----------------------------------------------------------------------<= br> >
> 
> [snip]
>
> The group will also coordinate with related working groups within the I= ETF,
> such as QUIC and HTTPBIS, as appropriate.
>
> With the current state of QUIC developement and HTTP/3 mapping definiti= on, i.e.
> still working on the initial version, I would like to have a more firm w= ording
> that the WebTrans WG will actually have to take any requests for extens= ions of
> HTTP/3 and QUIC to the relevant WG.
>
> While there are no extensions to QUIC among the proposed WG documents, s= ome of
> the drafts do extend HTTP using custom SETTINGS parameters (which is th= e
> intended HTTP extensibility mechanism).  I've hitherto assumed tha= t webtrans
> would work with HTTP experts in httpbis/quic to ensure that the propose= d
> extensions are architecturally sound and follow best practices, but the= main
> bulk of work would be done in the new working group itself.
> 
> ----------------------------------------------------------------------<= br> > COMMENT:
> ----------------------------------------------------------------------<= br> >
> I also would appreciate if someone can clarify what stage of formality t= he
> Web-Transport API has been adopted in W3C and is being worked on. Tryin= g to
> find anything about which group it belongs to on the W3C page didn't gi= ve 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.<= br> >
> 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 i= nvolved
> are aware of it, but my current understanding is that the editors of th= e W3C
> spec currently do not believe we have enough real-world implementation<= br> > experience with the proposal to advance it further in the formal proces= s.
> 
> Having lived through the WebRTC / RTCWeb interactions it would good to k= now
> more how the interaction between the bodies are intended to work. Espec= ially as
> changes to the API can have significant impact on what work needs to ha= ppen in
> the IETF.
>
> I mostly agree with Bernard here.  My plan was that the -overview d= oc 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. Howe= ver
> draft-vvv-webtrans-overview does mention priorities. As this API appear= s to
> support multiple parallel transmissions and transfers I think at a mini= mal a
> sender transport protocol scheduling or HTTP/3 priority  would be l= ikely to be
> part of the work. I also have to ask if this is likely to attempted to b= e
> mapped also towards the network level, for example DSCPs? If any such w= ork is
> expected and intended I think that needs to be raised. Otherwise I woul= d 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 t= his up
> further, but there's a lot of text to write.
>
> Before I elaborate further, I would like to point out that there are tw= o types
> of priorities here, and those are often confused:
> (1) Priorities that the application indicates to the transport layer fo= r 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 do= n'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 (tha= t would
> include the proposed Web APIs) to provide those:
>
> """
> [QUIC] relies on receiving priority information from the application th= at uses
> QUIC.
>
> A QUIC implementation SHOULD provide ways in which an application can i= ndicate
> the relative priority of streams. When deciding which streams to dedica= te
> resources to, the implementation SHOULD use the information provided by= the
> application.
> """
>
> Besides, I don't believe we can avoid defining a write scheduling mecha= nism in
> the API.  QUIC itself treats it as an implementation detail, but W= eb APIs
> generally try really hard to avoid implementation-defined behavior.&nbs= p; 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/webtransp= ort

= --Apple-Mail-8056B612-A9AC-495B-B6D8-0B7792620D30-- From nobody Tue Feb 11 13:35:16 2020 Return-Path: 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 ; 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 ; 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 ; Tue, 11 Feb 2020 13:35:10 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id d10so13312202ljl.9 for ; 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: In-Reply-To: From: Eric Rescorla Date: Tue, 11 Feb 2020 13:34:32 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= Cc: David Schinazi , Victor Vasiliev , webtrans-chairs@ietf.org, WebTransport , The IESG , Magnus Westerlund Content-Type: multipart/alternative; boundary="00000000000045556e059e53a159" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 21:35:14 -0000 --00000000000045556e059e53a159 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" < ietf@kuehlewind.net> wrote: > Hi David, > > I didn=E2=80=99t say that other groups cannot define extension. I did say= that > it=E2=80=99s the decision of the working group that maintains the protoco= l how to > handle that and for Quic we didn=E2=80=99t 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=E2=80=99t define a= nything > 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 : > > =EF=BB=BF > 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 > wrote: > >> Hi David, >> >> One more comment below. >> >> > On 6. Feb 2020, at 14:46, David Schinazi >> 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 i= s >> 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 jus= t >> sending a WGLC there is not sufficient. >> >> More generally deciding on processes for other protocols/groups in this >> charter is not appropriate. I=E2=80=99m not sure what the defined proces= s 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=E2=80=99t mean that th= is 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 ad= apt >> 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=E2=80=A6= ? >> >> Mirja >> >> >> >> > >> > Would that be an acceptable scope? >> > >> > Thanks, >> > David >> > >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev >> 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 thi= s >> > 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 t= he >> > intended HTTP extensibility mechanism). I've hitherto assumed that >> webtrans >> > would work with HTTP experts in httpbis/quic to ensure that the propos= ed >> > extensions are architecturally sound and follow best practices, but th= e >> 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 gam= e >> > 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 b= y >> 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. I= f >> > every browser had a completely different write scheduling approach, >> > that could make the job of writing performant cross-browser code reall= y >> > 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 > --00000000000045556e059e53a159 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 11, 2020 at 1:31 PM "= ;Mirja K=C3=BChlewind (IETF)" <ietf@kuehlewind.net> wrote:
Hi David,

I didn=E2=80=99t say that other gr= oups cannot define extension. I did say that it=E2=80=99s the decision of t= he working group that maintains the protocol how to handle that and for Qui= c we didn=E2=80=99t have had that discussion yet.=C2=A0

Examples for groups that explicitly define pr= ocess 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=E2= =80=99t 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 transpo= rt seem fairly clear:


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 Q= UIC WG.

-Ekr







Mirja

=
Am 11.02.2020 um 21:47 schrieb David Schinazi= <dschinaz= i.ietf@gmail.com>:

=EF=BB=BF
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<= /div>
cannot write extensions to that protocol.

For example, the QUIC WG is defining the=C2=A0quic_transport_parameters
TLS extension. That extension is not defined in the TLS WG.
<= div>https://tools.ietf.org/html/draft-ietf-quic-tls-25#se= ction-8.2

Similarly, the ACME WG is defini= ng the=C2=A0Cert-Not-Before HTTP
header, not the HTTP WG.
https://tools.ietf.org/html/draft-ietf-acme-star-11#s= ection-6.7

Additionally, MPTCP is an exten= sion to TCP that=C2=A0was not
defined in the TCPM WG. The list go= es on.

We don't yet have examples for QUIC as = the QUIC IANA
registries haven't been created yet, but I don&= #39;t see why QUIC
would be different from TLS, HTTP, or TCP.

David


On Tue, Feb 11, 2020 at 4:3= 8 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/DavidSchi= nazi/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 n= eeded 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 cha= rter is not appropriate. I=E2=80=99m not sure what the defined process is f= or 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=E2=80=99t mean that this gro= up cannot talk about any extension but as soon as the group thinks an exten= sion is needed, it needs to go to the QUIC group and cannot just adapt anyt= hing within WebTransport.

Please also double-check what the right process is for TLS and HTTP. I assu= me for TLS it's the same but for HTTP it might be different=E2=80=A6?
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= 9;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&= gt; 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter= -ietf-webtrans/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
>=C2=A0
> [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 definit= ion, 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 exten= sions 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 t= he
> intended HTTP extensibility mechanism).=C2=A0 I've hitherto assume= d that webtrans
> would work with HTTP experts in httpbis/quic to ensure that the propos= ed
> extensions are architecturally sound and follow best practices, but th= e main
> bulk of work would be done in the new working group itself.
>=C2=A0
> ----------------------------------------------------------------------=
> 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. Tryi= ng 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 gam= e
> communication where this was discussed and raised in some discussions.=
>
> It's a WICG draft, which basically means no formal status.=C2=A0 W= e had a discussion
> session at TPAC last year, and I believe most people who'd be norm= ally involved
> are aware of it, but my current understanding is that the editors of t= he W3C
> spec currently do not believe we have enough real-world implementation=
> experience with the proposal to advance it further in the formal proce= ss.
>=C2=A0
> Having lived through the WebRTC / RTCWeb interactions it would good to= know
> more how the interaction between the bodies are intended to work. Espe= cially as
> changes to the API can have significant impact on what work needs to h= appen in
> the IETF.
>
> I mostly agree with Bernard here.=C2=A0 My plan was that the -overview= doc would
> list all of the protocol requirements and API expectations, acting as<= br> > integration point between W3C and IETF specs.
>=C2=A0
> The current API draft does not include any discussion of priority. How= ever
> draft-vvv-webtrans-overview does mention priorities. As this API appea= rs to
> support multiple parallel transmissions and transfers I think at a min= imal a
> sender transport protocol scheduling or HTTP/3 priority=C2=A0 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 wou= ld 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.=C2=A0 I've been meaning to w= rite 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 t= wo types
> of priorities here, and those are often confused:
> (1) Priorities that the application indicates to the transport layer f= or the
>=C2=A0 =C2=A0 =C2=A0purpose 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.=C2=A0 I d= on't believe
> any of the proposed drafts cover that topic, and I'd rather wait f= or
> quic/httpbis to come up with a mechanism first.
>
> The priorities mentioned in -overview are of the #1 kind.=C2=A0 Sectio= n 2.3 of
> draft-ietf-quic-transport-25 explicitly encourages implementations (th= at would
> include the proposed Web APIs) to provide those:
>
> """
> [QUIC] relies on receiving priority information from the application t= hat uses
> QUIC.
>
> A QUIC implementation SHOULD provide ways in which an application can = indicate
> the relative priority of streams. When deciding which streams to dedic= ate
> resources to, the implementation SHOULD use the information provided b= y the
> application.
> """
>
> Besides, I don't believe we can avoid defining a write scheduling = mechanism in
> the API.=C2=A0 QUIC itself treats it as an implementation detail, but = Web APIs
> generally try really hard to avoid implementation-defined behavior.=C2= =A0 If
> every browser had a completely different write scheduling approach, > that could make the job of writing performant cross-browser code reall= y
> difficult.
>
> Thanks,
>=C2=A0 =C2=A0Victor.
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--00000000000045556e059e53a159-- From nobody Tue Feb 11 14:04:24 2020 Return-Path: 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 81B0512081F; Tue, 11 Feb 2020 14:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 2nnNsk96h1dK; Tue, 11 Feb 2020 14:04:13 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 82FC2120024; Tue, 11 Feb 2020 14:04:12 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id h23so13389405ljc.8; Tue, 11 Feb 2020 14:04:12 -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=5sE2GePwbvsFwzHWBycEKAxMSCjKTfdCH3OpdP80DK0=; b=cLg5Vv4ftxv9bc7UQHVxHmihNw2zzp+EIRO0Oc/Kg/ZZQIrVpED9pEtk0vZ8qdWjf/ 55jpo1yV+/CbFuxB+RkG/RIOfnxs9fAm3zMD9tXbcyr610S2ZlKstSPLw7nUU2PwlkHd EgdpmTOZq/z5MSLvaYnB31RanF/CpHhr2W9NeqrfEy8+bfAe7E56FgCfZs40eGTCVyWh rjAYweAbBx//C5PE983fmC0mK5Ufr+Ia1BEOGHSBTHPRMiqs3seKQM65MIoT14n383WM ASIzC+ToM1WhL961MuHrIBQT4+PM5OiQ4fy6+kIT/MUxqmUJSIwg6UM88mfve1zAeoVs wOAg== 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=5sE2GePwbvsFwzHWBycEKAxMSCjKTfdCH3OpdP80DK0=; b=R2YgY7VXeeFViRw2fMN9+sFozq2GYBxEYkODECkIiYLkyiX6a4sJZx3tL0Y1P+8cjz zbOTdzkh7hxUMx88HaTHwH9lB/PhpygNOP+3UY8YTLmaFzYs0nD/c3Sd79LmxYsoLMLV lmGXRnAvtFX9cAcKXeUZDRgwwKhzDtju490wxBfMpkYhOYdCh10sImEs4F769/8POYKm KoGFkQbgQRfr+yBa/d3bxzrHZeOEsneTF54V3cDW2OIK5s0C3rA/ta/miMbrRVRbg8Tc 09G82hlZqMXxnb1Lx6pmhvIJKNaryzo+wcXCnWuzLoSEtOCo4flGk0fEC/Hr2ScEam4N tejw== X-Gm-Message-State: APjAAAUhEWzl6a0e0xmo5e5RwB462k9IczOxtyHgu3YQjHQBd6q06O31 M5Zn2g6Q2bycRUUbV8Od7jixsQVxH7fkF+y8wQk= X-Google-Smtp-Source: APXvYqyUW+qnpXLQ7LoZSvewU2r0wvhgRPcUgMXVfnGfDYH1ADjtUr6iSBrxFrGyA8bDvPVxlFN4KFtDMDCoveZBJ3k= X-Received: by 2002:a2e:8591:: with SMTP id b17mr5590492lji.249.1581458650741; Tue, 11 Feb 2020 14:04:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Tue, 11 Feb 2020 14:03:59 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind_=28IETF=29?= Cc: webtrans-chairs@ietf.org, Magnus Westerlund , WebTransport , The IESG , Victor Vasiliev Content-Type: multipart/alternative; boundary="0000000000001abd17059e540935" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 22:04:18 -0000 --0000000000001abd17059e540935 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" < ietf@kuehlewind.net> wrote: > Hi David, > > I didn=E2=80=99t say that other groups cannot define extension. I did say= that > it=E2=80=99s the decision of the working group that maintains the protoco= l how to > handle that and for Quic we didn=E2=80=99t 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=E2=80=99t define a= nything > yet for Quic, the working assumption for now should be that all extension > work will be fine in the Quic group. > Your examples don't prevent other working groups from defining extensions. The 6man charter is very clear on this point: it gives 6man the option to provide input on IPv6 extensions defined in other WGs, it does not prevent other WGs from defining IPv6 extensions. RPL (RFC 6550) is an example of the ROLL WG defining an IPv6 extension. RFC 5986 is an example of the GEOPRIV WG defining a DHCP option. On this specific one, the DHC charter has an explicit custom definition of a DHCP option vs a DHCP extension, but any extensions that WEBTRANS would produce would be closer to options than to extensions in the DHC meaning of the terms. And the QUIC WG has an existing charter that does not prevent work on QUIC extensions in other WGs. Could you elaborate on why you want to prevent the WEBTRANS WG from producing extensions? I think I'm misunderstanding the motivation here. David > Mirja > > > Am 11.02.2020 um 21:47 schrieb David Schinazi : > > =EF=BB=BF > 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 > wrote: > >> Hi David, >> >> One more comment below. >> >> > On 6. Feb 2020, at 14:46, David Schinazi >> 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 i= s >> 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 jus= t >> sending a WGLC there is not sufficient. >> >> More generally deciding on processes for other protocols/groups in this >> charter is not appropriate. I=E2=80=99m not sure what the defined proces= s 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=E2=80=99t mean that th= is 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 ad= apt >> 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=E2=80=A6= ? >> >> Mirja >> >> >> >> > >> > Would that be an acceptable scope? >> > >> > Thanks, >> > David >> > >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev >> 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 thi= s >> > 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 t= he >> > intended HTTP extensibility mechanism). I've hitherto assumed that >> webtrans >> > would work with HTTP experts in httpbis/quic to ensure that the propos= ed >> > extensions are architecturally sound and follow best practices, but th= e >> 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 gam= e >> > 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 b= y >> 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. I= f >> > every browser had a completely different write scheduling approach, >> > that could make the job of writing performant cross-browser code reall= y >> > difficult. >> > >> > Thanks, >> > Victor. >> > -- >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >> >> --0000000000001abd17059e540935 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 11, 2020 at 1:31 PM "= ;Mirja K=C3=BChlewind (IETF)" <ietf@kuehlewind.net> wrote:
Hi David,

I didn=E2=80=99t say that other gr= oups cannot define extension. I did say that it=E2=80=99s the decision of t= he working group that maintains the protocol how to handle that and for Qui= c we didn=E2=80=99t have had that discussion yet.=C2=A0

Examples for groups that explicitly define pr= ocess 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=E2= =80=99t define anything yet for Quic, the working assumption for now should= be that all extension work will be fine in the Quic group.

Your examples don't prevent other working = groups from defining extensions.
The 6man charter is very clear o= n this point: it gives 6man the option to provide input on IPv6 extensions = defined in other WGs, it does not prevent other WGs from defining IPv6 exte= nsions. RPL (RFC=C2=A06550) is an example of the ROLL WG defining an IPv6 e= xtension.
RFC=C2=A05986 is an example of the GEOPRIV WG defining = a DHCP option. On this specific one, the DHC charter has an explicit custom= definition of a DHCP option vs a DHCP extension, but any extensions that W= EBTRANS would produce would be closer to options than to extensions in the = DHC meaning of the terms. And the QUIC WG has an existing charter that does= not prevent work on QUIC extensions in other WGs.
Could you elab= orate on why you want to prevent the WEBTRANS WG from producing extensions?= I think I'm misunderstanding the motivation here.

=
David

=C2=A0
Mirja


Am 11.0= 2.2020 um 21:47 schrieb David Schinazi <dschinazi.ietf@gmail.com>:

=EF=BB=BF
Hi Mirja,

I'm not sure I agree with your in= terpretation. The fact that a WG is
responsible for a protocol do= es not mean that other working groups
cannot write extensions to = that protocol.

For example, the QUIC WG is definin= g the=C2=A0quic_transport_parameters
TLS extension. That extensio= n is not defined in the TLS WG.

Similarly, the ACME WG is defining the=C2=A0Cert-Not-Before HTTP
header, not the HTTP WG.

Additionally, MPTCP is an extension to TCP that=C2=A0was not
defined in the TCPM WG. The list goes on.

We do= n't yet have examples for QUIC as the QUIC IANA
registries ha= ven'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> w= rote:
Hi David,<= br>
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/DavidSchi= nazi/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 n= eeded 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 cha= rter is not appropriate. I=E2=80=99m not sure what the defined process is f= or 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=E2=80=99t mean that this gro= up cannot talk about any extension but as soon as the group thinks an exten= sion is needed, it needs to go to the QUIC group and cannot just adapt anyt= hing within WebTransport.

Please also double-check what the right process is for TLS and HTTP. I assu= me for TLS it's the same but for HTTP it might be different=E2=80=A6?
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= 9;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&= gt; 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<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter= -ietf-webtrans/
>
>
>
> ----------------------------------------------------------------------=
> BLOCK:
> ----------------------------------------------------------------------=
>
>=C2=A0
> [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 definit= ion, 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 exten= sions 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 t= he
> intended HTTP extensibility mechanism).=C2=A0 I've hitherto assume= d that webtrans
> would work with HTTP experts in httpbis/quic to ensure that the propos= ed
> extensions are architecturally sound and follow best practices, but th= e main
> bulk of work would be done in the new working group itself.
>=C2=A0
> ----------------------------------------------------------------------=
> 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. Tryi= ng 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 gam= e
> communication where this was discussed and raised in some discussions.=
>
> It's a WICG draft, which basically means no formal status.=C2=A0 W= e had a discussion
> session at TPAC last year, and I believe most people who'd be norm= ally involved
> are aware of it, but my current understanding is that the editors of t= he W3C
> spec currently do not believe we have enough real-world implementation=
> experience with the proposal to advance it further in the formal proce= ss.
>=C2=A0
> Having lived through the WebRTC / RTCWeb interactions it would good to= know
> more how the interaction between the bodies are intended to work. Espe= cially as
> changes to the API can have significant impact on what work needs to h= appen in
> the IETF.
>
> I mostly agree with Bernard here.=C2=A0 My plan was that the -overview= doc would
> list all of the protocol requirements and API expectations, acting as<= br> > integration point between W3C and IETF specs.
>=C2=A0
> The current API draft does not include any discussion of priority. How= ever
> draft-vvv-webtrans-overview does mention priorities. As this API appea= rs to
> support multiple parallel transmissions and transfers I think at a min= imal a
> sender transport protocol scheduling or HTTP/3 priority=C2=A0 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 wou= ld 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.=C2=A0 I've been meaning to w= rite 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 t= wo types
> of priorities here, and those are often confused:
> (1) Priorities that the application indicates to the transport layer f= or the
>=C2=A0 =C2=A0 =C2=A0purpose 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.=C2=A0 I d= on't believe
> any of the proposed drafts cover that topic, and I'd rather wait f= or
> quic/httpbis to come up with a mechanism first.
>
> The priorities mentioned in -overview are of the #1 kind.=C2=A0 Sectio= n 2.3 of
> draft-ietf-quic-transport-25 explicitly encourages implementations (th= at would
> include the proposed Web APIs) to provide those:
>
> """
> [QUIC] relies on receiving priority information from the application t= hat uses
> QUIC.
>
> A QUIC implementation SHOULD provide ways in which an application can = indicate
> the relative priority of streams. When deciding which streams to dedic= ate
> resources to, the implementation SHOULD use the information provided b= y the
> application.
> """
>
> Besides, I don't believe we can avoid defining a write scheduling = mechanism in
> the API.=C2=A0 QUIC itself treats it as an implementation detail, but = Web APIs
> generally try really hard to avoid implementation-defined behavior.=C2= =A0 If
> every browser had a completely different write scheduling approach, > that could make the job of writing performant cross-browser code reall= y
> difficult.
>
> Thanks,
>=C2=A0 =C2=A0Victor.
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--0000000000001abd17059e540935-- From nobody Tue Feb 11 21:33:45 2020 Return-Path: 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 8FE5512022C; Tue, 11 Feb 2020 21:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 5kdQ4F0T4WHv; Tue, 11 Feb 2020 21:33:37 -0800 (PST) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 6D8701200E3; Tue, 11 Feb 2020 21:33:37 -0800 (PST) Received: by mail-io1-f44.google.com with SMTP id c16so830935ioh.6; Tue, 11 Feb 2020 21:33:37 -0800 (PST) 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=kZG9MCC3DhQRSY0v6a1ms/T2mxcdqZfkdAFbVbE6xsQ=; b=YJcUcZBgk1GAk056JzLfOMHbmEnkOlOTHLZMDN/24xh4EnFRPjzSBLJ3u++A/lUxaZ 7ivBswXWP8/XiZoBm15QxRb68Q8yn7ATYdjgbe3e59VEl4YhihNoGdGSZT9KtaZOkDu9 1v/pBXPQ2MMdwaQ8VFoY1GL06vEpfF3HZdam4UQ6ss8Z8QJQKQyyisXeAqotKFV6v+rK TyP344AMKTa9SFEVfA9cXeKxz1r0s2DSGVaL4Q0ULfg6oo9zBRCwcK2wgqa7JqfqlMhM sa1WQlwi0HAP7yB1aMOZWnvlrdgpV1uqhA/ew9NbyriUvI7fqpdbdAXITI5co7mVdUEW NPzA== X-Gm-Message-State: APjAAAX11Eu5lSYWODvs+CNKefaxbFuWCd4E2fV2n8N5wBSiqG806Cfv S9ap8qcck37Y24/TTx5rz+a7B5wAVO4xpw0xDow= X-Google-Smtp-Source: APXvYqzvhnktKLtJYuO8lSgYcDzGg4aMDKzE8iNHvpW30qEFkzLDIt24TuYHXPRCEaZYPSQu75gSIOqEZUWc0YFSOyE= X-Received: by 2002:a5d:9b94:: with SMTP id r20mr16096649iom.140.1581485616417; Tue, 11 Feb 2020 21:33:36 -0800 (PST) MIME-Version: 1.0 References: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> In-Reply-To: <158048874973.21096.7146214036477975185.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 12 Feb 2020 00:33:25 -0500 Message-ID: To: Magnus Westerlund Cc: The IESG , webtrans-chairs@ietf.org, webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000624eda059e5a50a0" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 05:33:40 -0000 --000000000000624eda059e5a50a0 Content-Type: text/plain; charset="UTF-8" Magnus, the charter has been updated. Will you check whether -01 will clear your BLOCK? Thanks, Barry On Fri, Jan 31, 2020 at 11:39 AM 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: > ---------------------------------------------------------------------- > > This charter is so open ended on what protocol that is to be developed > that it > could define a new IP version as well as transport protocols. I don't think > that is the intention. To my understanding this effort could more clearly > be > defined as defining one or two application protocol that fulfills the > WebTransport API and is using QUIC or HTTP/3. If the charter can be > clarified > to not include transport protocol work and which existing transport > protocols > or other protocols the solution will build on it would be much better and > well > defined work. I also think creating mappings to other transport protocols > should require rechartering to enable a wider discussion of such choices. > > Secondly: > > 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. > > > ---------------------------------------------------------------------- > 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. > > 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. > > 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. > > > --000000000000624eda059e5a50a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Magnus, the charter has been updated.=C2=A0 Will you= check whether -01 will clear your BLOCK?

=
Thanks,
Barry

=
On Fri, Ja= n 31, 2020 at 11:39 AM Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
Magnus Westerlund has entered the following ballot posit= ion 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:
----------------------------------------------------------------------

This charter is so open ended on what protocol that is to be developed that= it
could define a new IP version as well as transport protocols. I don't t= hink
that is the intention. To my understanding this effort could more clearly b= e
defined as defining one or two application protocol that fulfills the
WebTransport API and is using QUIC or HTTP/3. If the charter can be clarifi= ed
to not include transport protocol work and which existing transport protoco= ls
or other protocols the solution will build on it would be much better and w= ell
defined work. I also think creating mappings to other transport protocols should require rechartering to enable a wider discussion of such choices.
Secondly:

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 word= ing
that the WebTrans WG will actually have to take any requests for extensions= of
HTTP/3 and QUIC to the relevant WG.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also would appreciate if someone can clarify what stage of formality the<= br> 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 gi= ve 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.

Having lived through the WebRTC / RTCWeb interactions it would good to know=
more how the interaction between the bodies are intended to work. Especiall= y as
changes to the API can have significant impact on what work needs to happen= in
the IETF.

The current API draft does not include any discussion of priority. However<= br> 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=C2=A0 would be like= ly 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 as= sume
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.


--000000000000624eda059e5a50a0-- From nobody Tue Feb 11 21:38:12 2020 Return-Path: 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 C6A03120AB6; Tue, 11 Feb 2020 21:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 kVm4c1K4naz2; Tue, 11 Feb 2020 21:38:02 -0800 (PST) Received: from mail-il1-f178.google.com (mail-il1-f178.google.com [209.85.166.178]) (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 C1112120A24; Tue, 11 Feb 2020 21:37:54 -0800 (PST) Received: by mail-il1-f178.google.com with SMTP id v13so698435iln.4; Tue, 11 Feb 2020 21:37:54 -0800 (PST) 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=vDByzHKLcbZxaT+kf5RFp4WKOZo8R4e4/4QAb44lkzc=; b=WWHhEYtzG3/9Bw2owPB1dmO20hPLDWyc/umDjRWqZbuJ9yL9NQag5eEv9ZZupU1x8o RKsWL6XBCn3dzRa/1q+Qtps7C82rY+5dWA4k4hxkJHo8NPvdrbRYcvL2px4brK40pA4b T8gT229Xedz8ybVMIFd+RBXiOflMm823ODLEaPqgXro/lv3MxA6x5Age2PWR+PRhGKV6 hpzgFXQUxArnSKboHbW6p+rP9xFrurX8GBe4BStut8PJ1wl2svHsXYkVaqv1TtglOlpR j6CboxcXa/PIM0ISIqvi5fbn0EQxkHPqA48W4bu+ubRSoP8BZ4v4NJrCawdjvuWjX7Ne N3bg== X-Gm-Message-State: APjAAAW5nY5zrKkInQJJ0c/S3LQKWeqeG9eotNKMpl2QjQiYOx9lpNPx dEKiwL5ttOq6/Cg5kwV3zL1tcQmWhnfUnR1aTGEgTg== X-Google-Smtp-Source: APXvYqxKWv3viXfkbkinwLMwVKOqi2Q3W5QiEMrwwr++QpYqLFhG1/c26g9Dpdrzx0hi59A8VfeJCKgxJqRnHrnt/6w= X-Received: by 2002:a92:508:: with SMTP id q8mr9501271ile.187.1581485873559; Tue, 11 Feb 2020 21:37:53 -0800 (PST) MIME-Version: 1.0 References: <158091329253.12815.9369576484605200664.idtracker@ietfa.amsl.com> In-Reply-To: <158091329253.12815.9369576484605200664.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 12 Feb 2020 00:37:42 -0500 Message-ID: To: Alissa Cooper Cc: The IESG , webtrans-chairs@ietf.org, webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000b5fc4b059e5a5f0c" Archived-At: Subject: Re: [Webtransport] Alissa Cooper's Block on charter-ietf-webtrans-00-00: (with BLOCK) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 05:38:08 -0000 --000000000000b5fc4b059e5a5f0c Content-Type: text/plain; charset="UTF-8" Alissa, the charter has been updated. Will you please check whether -01 will clear your BLOCK? Thanks, Barry On Wed, Feb 5, 2020 at 9:35 AM Alissa Cooper via Datatracker < noreply@ietf.org> wrote: > Alissa Cooper 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: > ---------------------------------------------------------------------- > > Based on the responses to Magnus' comment I think there are two issues to > sort > out before proceeding further. > > 1) Whether the API is creating requirements for the protocol, or the > protocol > is creating requirements for the API. The charter is written as if the > situation is the former, but the list mail points towards the latter. The > charter should be clear about this before it goes out for external review. > > 2) It sounds like there is still some chance that the change control for > the > API shifts from the W3C to the WHATWG. Would this group re-charter (or > close) > if that happens, or would it be better to make the charter more generically > tied to the API but not to its change controller? > > Please keep the IESG on cc on all replies. Thanks. > > > > > --000000000000b5fc4b059e5a5f0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alissa, the charter has been updated.=C2=A0 Will you= please check whether -01 will clear your BLOCK?

Thanks,
Barry

On = Wed, Feb 5, 2020 at 9:35 AM Alissa Cooper via Datatracker <noreply@ietf.org> wrote:
Alissa Cooper 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:
----------------------------------------------------------------------

Based on the responses to Magnus' comment I think there are two issues = to sort
out before proceeding further.

1) Whether the API is creating requirements for the protocol, or the protoc= ol
is creating requirements for the API. The charter is written as if the
situation is the former, but the list mail points towards the latter. The charter should be clear about this before it goes out for external review.<= br>
2) It sounds like there is still some chance that the change control for th= e
API shifts from the W3C to the WHATWG. Would this group re-charter (or clos= e)
if that happens, or would it be better to make the charter more generically=
tied to the API but not to its change controller?

Please keep the IESG on cc on all replies. Thanks.




--000000000000b5fc4b059e5a5f0c-- From nobody Wed Feb 12 02:46:15 2020 Return-Path: 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 517E012022A; Wed, 12 Feb 2020 02:46:11 -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 BkGAVP6H193Z; Wed, 12 Feb 2020 02:46:07 -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 7D229120220; Wed, 12 Feb 2020 02:46:07 -0800 (PST) Received: from [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 1j1pWu-0005kS-Px; Wed, 12 Feb 2020 11:46:05 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 12 Feb 2020 11:45:44 +0100 Cc: webtrans-chairs@ietf.org, Magnus Westerlund , WebTransport , The IESG , Victor Vasiliev Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David Schinazi X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581504367;9299cffc; X-HE-SMSGID: 1j1pWu-0005kS-Px Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 10:46:11 -0000 Hi David, Again, I don=E2=80=99t want to prevent anybody from defining extension, = I=E2=80=99m only saying the process is not defined yet (as you say = below, there is nothing in the QUIC charter (yet) that talks about it = because so far there was not even an option to define extensions for = QUIC at all because QUIC didn=E2=80=99t exists fully yet). We have to have this discussion in the QUIC group and need to add = something to the QUIC charter with the new re-charter we likely will do = in summer. And therefore it is not okay to make up an alternative = process within the WebTransport charter. Mirja > On 11. Feb 2020, at 23:03, David Schinazi = wrote: >=20 >=20 >=20 > On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" = wrote: > Hi David, >=20 > I didn=E2=80=99t say that other groups cannot define extension. I did = say that it=E2=80=99s the decision of the working group that maintains = the protocol how to handle that and for Quic we didn=E2=80=99t have had = that discussion yet.=20 >=20 > 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=E2=80=99t define = anything yet for Quic, the working assumption for now should be that all = extension work will be fine in the Quic group. >=20 > Your examples don't prevent other working groups from defining = extensions. > The 6man charter is very clear on this point: it gives 6man the option = to provide input on IPv6 extensions defined in other WGs, it does not = prevent other WGs from defining IPv6 extensions. RPL (RFC 6550) is an = example of the ROLL WG defining an IPv6 extension. > RFC 5986 is an example of the GEOPRIV WG defining a DHCP option. On = this specific one, the DHC charter has an explicit custom definition of = a DHCP option vs a DHCP extension, but any extensions that WEBTRANS = would produce would be closer to options than to extensions in the DHC = meaning of the terms. And the QUIC WG has an existing charter that does = not prevent work on QUIC extensions in other WGs. > Could you elaborate on why you want to prevent the WEBTRANS WG from = producing extensions? I think I'm misunderstanding the motivation here. >=20 > David >=20 > =20 > Mirja >=20 >=20 >> Am 11.02.2020 um 21:47 schrieb David Schinazi = : >>=20 >> =EF=BB=BF >> Hi Mirja, >>=20 >> 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. >>=20 >> 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 >>=20 >> 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 >>=20 >> Additionally, MPTCP is an extension to TCP that was not >> defined in the TCPM WG. The list goes on. >>=20 >> 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. >>=20 >> David >>=20 >>=20 >> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind = wrote: >> Hi David, >>=20 >> One more comment below. >>=20 >> > On 6. Feb 2020, at 14:46, David Schinazi = wrote: >> >=20 >> > Hi Magnus, >> >=20 >> > I realized that some of our earlier replies were accidentally not = sent to >> > the IESG list, for which I apologize. >> >=20 >> > To summarize that discussion: >> >=20 >> > - 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 >> >=20 >> > - 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. >>=20 >> 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. >>=20 >> More generally deciding on processes for other protocols/groups in = this charter is not appropriate. I=E2=80=99m not sure what the defined = process is for HTTP and TLS but that should be specified in their = charter and not here. >>=20 >> For QUIC, I would like to rather see that extension or modification = are out of scope for this group. Of course that doesn=E2=80=99t 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. >>=20 >> 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=E2=80=A6= ? >>=20 >> Mirja >>=20 >>=20 >>=20 >> >=20 >> > Would that be an acceptable scope? >> >=20 >> > Thanks, >> > David >> >=20 >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev = 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. >> >=20 >> > On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker = wrote: >> > Magnus Westerlund has entered the following ballot position for >> > charter-ietf-webtrans-00-00: Block >> >=20 >> > 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.) >> >=20 >> >=20 >> >=20 >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >> >=20 >> >=20 >> >=20 >> > = ---------------------------------------------------------------------- >> > BLOCK: >> > = ---------------------------------------------------------------------- >> >=20 >> > =20 >> > [snip] >> >=20 >> > The group will also coordinate with related working groups within = the IETF, >> > such as QUIC and HTTPBIS, as appropriate. >> >=20 >> > 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. >> >=20 >> > 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. >> > =20 >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> >=20 >> > 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. >> >=20 >> > 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. >> > =20 >> > 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. >> >=20 >> > 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. >> > =20 >> > 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. >> >=20 >> > 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. >> >=20 >> > 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.. >> >=20 >> > 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. >> >=20 >> > 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: >> >=20 >> > """ >> > [QUIC] relies on receiving priority information from the = application that uses >> > QUIC. >> >=20 >> > 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. >> > """ >> >=20 >> > 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. >> >=20 >> > Thanks, >> > Victor. >> > --=20 >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >>=20 From nobody Wed Feb 12 02:49:07 2020 Return-Path: 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 87E9F12022A; Wed, 12 Feb 2020 02:49:05 -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 fbtR-Ke-k6jZ; Wed, 12 Feb 2020 02:49:02 -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 F3FB8120220; Wed, 12 Feb 2020 02:49:01 -0800 (PST) Received: from [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 1j1pZj-00076Q-2R; Wed, 12 Feb 2020 11:48:59 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 12 Feb 2020 11:48:38 +0100 Cc: Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev Content-Transfer-Encoding: quoted-printable Message-Id: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581504542;b6024d40; X-HE-SMSGID: 1j1pZj-00076Q-2R Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 10:49:06 -0000 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.=20= All I=E2=80=99m 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. = Again that doesn=E2=80=99t mean that in future it will not be possible = for other groups to define extension but we need to have that discussion = first. Mirja =20 > On 11. Feb 2020, at 22:34, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" = wrote: > Hi David, >=20 > I didn=E2=80=99t say that other groups cannot define extension. I did = say that it=E2=80=99s the decision of the working group that maintains = the protocol how to handle that and for Quic we didn=E2=80=99t have had = that discussion yet.=20 >=20 > 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=E2=80=99t define = anything yet for Quic, the working assumption for now should be that all = extension work will be fine in the Quic group. >=20 > Well, the IANA considerations for QUIC transport seem fairly clear: >=20 > = https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4 >=20 > 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. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Mirja >=20 >=20 >> Am 11.02.2020 um 21:47 schrieb David Schinazi = : >>=20 >> =EF=BB=BF >> Hi Mirja, >>=20 >> 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. >>=20 >> 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 >>=20 >> 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 >>=20 >> Additionally, MPTCP is an extension to TCP that was not >> defined in the TCPM WG. The list goes on. >>=20 >> 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. >>=20 >> David >>=20 >>=20 >> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind = wrote: >> Hi David, >>=20 >> One more comment below. >>=20 >> > On 6. Feb 2020, at 14:46, David Schinazi = wrote: >> >=20 >> > Hi Magnus, >> >=20 >> > I realized that some of our earlier replies were accidentally not = sent to >> > the IESG list, for which I apologize. >> >=20 >> > To summarize that discussion: >> >=20 >> > - 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 >> >=20 >> > - 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. >>=20 >> 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. >>=20 >> More generally deciding on processes for other protocols/groups in = this charter is not appropriate. I=E2=80=99m not sure what the defined = process is for HTTP and TLS but that should be specified in their = charter and not here. >>=20 >> For QUIC, I would like to rather see that extension or modification = are out of scope for this group. Of course that doesn=E2=80=99t 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. >>=20 >> 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=E2=80=A6= ? >>=20 >> Mirja >>=20 >>=20 >>=20 >> >=20 >> > Would that be an acceptable scope? >> >=20 >> > Thanks, >> > David >> >=20 >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev = 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. >> >=20 >> > On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker = wrote: >> > Magnus Westerlund has entered the following ballot position for >> > charter-ietf-webtrans-00-00: Block >> >=20 >> > 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.) >> >=20 >> >=20 >> >=20 >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >> >=20 >> >=20 >> >=20 >> > = ---------------------------------------------------------------------- >> > BLOCK: >> > = ---------------------------------------------------------------------- >> >=20 >> > =20 >> > [snip] >> >=20 >> > The group will also coordinate with related working groups within = the IETF, >> > such as QUIC and HTTPBIS, as appropriate. >> >=20 >> > 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. >> >=20 >> > 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. >> > =20 >> > = ---------------------------------------------------------------------- >> > COMMENT: >> > = ---------------------------------------------------------------------- >> >=20 >> > 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. >> >=20 >> > 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. >> > =20 >> > 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. >> >=20 >> > 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. >> > =20 >> > 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. >> >=20 >> > 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. >> >=20 >> > 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.... >> >=20 >> > 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. >> >=20 >> > 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: >> >=20 >> > """ >> > [QUIC] relies on receiving priority information from the = application that uses >> > QUIC. >> >=20 >> > 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. >> > """ >> >=20 >> > 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. >> >=20 >> > Thanks, >> > Victor. >> > --=20 >> > Webtransport mailing list >> > Webtransport@ietf.org >> > https://www.ietf.org/mailman/listinfo/webtransport >>=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Wed Feb 12 06:15:28 2020 Return-Path: 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 ; 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 ; 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 ; Wed, 12 Feb 2020 06:15:23 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id v17so2502149ljg.4 for ; 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: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> In-Reply-To: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> From: Eric Rescorla Date: Wed, 12 Feb 2020 06:14:44 -0800 Message-ID: To: Mirja Kuehlewind Cc: Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev Content-Type: multipart/alternative; boundary="0000000000004cb516059e619ac8" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 14:15:27 -0000 --0000000000004cb516059e619ac8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind wrote: > Hi Ekr, > > Yes, it is specification required, however, if we decide to pushing an RF= C > 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=E2=80=99m saying that the process how and where to define QUIC exte= nsions 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=E2=80=99t 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 wrote: > > > > > > > > On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" < > ietf@kuehlewind.net> wrote: > > Hi David, > > > > I didn=E2=80=99t say that other groups cannot define extension. I did s= ay that > it=E2=80=99s the decision of the working group that maintains the protoco= l how to > handle that and for Quic we didn=E2=80=99t 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=E2=80=99t define a= nything > 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 >: > >> > >> =EF=BB=BF > >> 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 > wrote: > >> Hi David, > >> > >> One more comment below. > >> > >> > On 6. Feb 2020, at 14:46, David Schinazi > 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 thi= s > charter is not appropriate. I=E2=80=99m 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 ar= e > out of scope for this group. Of course that doesn=E2=80=99t mean that thi= s 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 ada= pt > 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=E2=80=A6? > >> > >> Mirja > >> > >> > >> > >> > > >> > Would that be an acceptable scope? > >> > > >> > Thanks, > >> > David > >> > > >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev > 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 al= l > >> > 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 th= e > 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 discussion= s. > >> > > >> > 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 implementati= on > >> > 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 do= c > would > >> > list all of the protocol requirements and API expectations, acting a= s > >> > 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 suc= h > 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 ca= n > 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 > > --0000000000004cb516059e619ac8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 12, 2020 at 2:49 AM Mirja= Kuehlewind <ietf@kuehlewind.net<= /a>> wrote:
H= i 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=E2=80=99m saying that the process how and where to define QUIC extens= ions in the IETF needs to be decided by the QUIC group and a future QUIC ch= arter and not by the charter of any other working group.


Again that doesn=E2=80=99t 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=C3=BChlewind (IETF)"= ; <ietf@kuehlew= ind.net> wrote:
> Hi David,
>
> I didn=E2=80=99t say that other groups cannot define extension. I did = say that it=E2=80=99s the decision of the working group that maintains the = protocol how to handle that and for Quic we didn=E2=80=99t have had that di= scussion yet.
>
> Examples for groups that explicitly define process for extending the p= rotocol in their charter are dhc and 6man. As you can see different groups/= protocols have different process and as we didn=E2=80=99t define anything y= et for Quic, the working assumption for now should be that all extension wo= rk will be fine in the Quic group.
>
> Well, the IANA considerations for QUIC transport seem fairly clear: >
> https://tools.ietf.org/h= tml/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 QUI= C WG.
>
> -Ekr
>
>
>
>
>
>
>
> Mirja
>
>
>> Am 11.02.2020 um 21:47 schrieb David Schinazi <dschinazi.ietf@gmail.com&= gt;:
>>
>> =EF=BB=BF
>> 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/d= raft-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 Q= UIC
>> would be different from TLS, HTTP, or TCP.
>>
>> David
>>
>>
>> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind <ietf@kuehlewind.net> wro= te:
>> Hi David,
>>
>> One more comment below.
>>
>> > On 6. Feb 2020, at 14:46, David Schinazi <dschinazi.ietf@gmail.com&= gt; 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 h= ere.
>> > 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.<= br> >>
>> I think this is not sufficient, at least not for QUIC. More discus= sion is needed in the QUIC group on this but currently I think the assumpti= on should be that all extensions will be done within the QUIC group. So jus= t sending a WGLC there is not sufficient.
>>
>> More generally deciding on processes for other protocols/groups in= this charter is not appropriate. I=E2=80=99m not sure what the defined pro= cess 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 modificatio= n are out of scope for this group. Of course that doesn=E2=80=99t 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 a= dapt anything within WebTransport.
>>
>> Please also double-check what the right process is for TLS and HTT= P. I assume for TLS it's the same but for HTTP it might be different=E2= =80=A6?
>>
>> 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 Datatra= cker <noreply@ietf= .org> wrote:
>> > Magnus Westerlund has entered the following ballot position f= or
>> > charter-ietf-webtrans-00-00: Block
>> >
>> > When responding, please keep the subject line intact and repl= y to all
>> > email addresses included in the To and CC lines. (Feel free t= o cut this
>> > introductory paragraph, however.)
>> >
>> >
>> >
>> > The document, along with other ballot positions, can be found= here:
>> > https://datatracker.ietf.org/do= c/charter-ietf-webtrans/
>> >
>> >
>> >
>> > -------------------------------------------------------------= ---------
>> > BLOCK:
>> > -------------------------------------------------------------= ---------
>> >
>> >=C2=A0
>> > [snip]
>> >
>> > The group will also coordinate with related working groups wi= thin the IETF,
>> > such as QUIC and HTTPBIS, as appropriate.
>> >
>> > With the current state of QUIC developement and HTTP/3 mappin= g 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 d= ocuments, some of
>> > the drafts do extend HTTP using custom SETTINGS parameters (w= hich is the
>> > intended HTTP extensibility mechanism).=C2=A0 I've hither= to assumed that webtrans
>> > would work with HTTP experts in httpbis/quic to ensure that t= he proposed
>> > extensions are architecturally sound and follow best practice= s, but the main
>> > bulk of work would be done in the new working group itself. >> >=C2=A0
>> > -------------------------------------------------------------= ---------
>> > 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 worksh= op on game
>> > communication where this was discussed and raised in some dis= cussions.
>> >
>> > It's a WICG draft, which basically means no formal status= .=C2=A0 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 edi= tors of the W3C
>> > spec currently do not believe we have enough real-world imple= mentation
>> > experience with the proposal to advance it further in the for= mal process.
>> >=C2=A0
>> > Having lived through the WebRTC / RTCWeb interactions it woul= d good to know
>> > more how the interaction between the bodies are intended to w= ork. Especially as
>> > changes to the API can have significant impact on what work n= eeds to happen in
>> > the IETF.
>> >
>> > I mostly agree with Bernard here.=C2=A0 My plan was that the = -overview doc would
>> > list all of the protocol requirements and API expectations, a= cting as
>> > integration point between W3C and IETF specs.
>> >=C2=A0
>> > The current API draft does not include any discussion of prio= rity. 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=C2=A0= would be likely to be
>> > part of the work. I also have to ask if this is likely to att= empted 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. Otherw= ise 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.=C2=A0 I've been mea= ning 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 th= ere are two types
>> > of priorities here, and those are often confused:
>> > (1) Priorities that the application indicates to the transpor= t layer for the
>> >=C2=A0 =C2=A0 =C2=A0purpose 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.= =C2=A0 I don't believe
>> > any of the proposed drafts cover that topic, and I'd rath= er wait for
>> > quic/httpbis to come up with a mechanism first.
>> >
>> > The priorities mentioned in -overview are of the #1 kind.=C2= =A0 Section 2.3 of
>> > draft-ietf-quic-transport-25 explicitly encourages implementa= tions (that would
>> > include the proposed Web APIs) to provide those:
>> >
>> > """
>> > [QUIC] relies on receiving priority information from the appl= ication that uses
>> > QUIC.
>> >
>> > A QUIC implementation SHOULD provide ways in which an applica= tion can indicate
>> > the relative priority of streams. When deciding which streams= to dedicate
>> > resources to, the implementation SHOULD use the information p= rovided by the
>> > application.
>> > """
>> >
>> > Besides, I don't believe we can avoid defining a write sc= heduling mechanism in
>> > the API.=C2=A0 QUIC itself treats it as an implementation det= ail, but Web APIs
>> > generally try really hard to avoid implementation-defined beh= avior.=C2=A0 If
>> > every browser had a completely different write scheduling app= roach,
>> > that could make the job of writing performant cross-browser c= ode really
>> > difficult.
>> >
>> > Thanks,
>> >=C2=A0 =C2=A0Victor.
>> > --
>> > Webtransport mailing list
>> > We= btransport@ietf.org
>> > https://www.ietf.org/mailman/listinf= o/webtransport
>>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--0000000000004cb516059e619ac8-- From nobody Wed Feb 12 06:26:30 2020 Return-Path: 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 F39F712003E; Wed, 12 Feb 2020 06:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 NM5O02VwiUUS; Wed, 12 Feb 2020 06:26:21 -0800 (PST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (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 9421312001E; Wed, 12 Feb 2020 06:26:21 -0800 (PST) Received: by mail-io1-f66.google.com with SMTP id i11so2372841ioi.12; Wed, 12 Feb 2020 06:26:21 -0800 (PST) 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:content-transfer-encoding; bh=z9yNO5xv9NLjlbR1Q6/nUCzGPSQz/JV1hnGzvUDre6M=; b=cNHmLcU/P5AM+ERPUOgvsljd9TfmNSJ3IJDeKqdm7EXTsZtrA+XaoLAlOgUUx6V9mh l1IvfVu2F3fFmNdjmTrG7k5Rx+KLT/0B7uBALhNYdsfLhsdAbT6i2y0fcq00jNU466ed gouxZpYdsq8S2w53Y4xa7cnyJUdqKkdZ1HUPGLce9Id1hTV/0t+oxbQ6gKqyDJpxEEYG E77ekxWkzYImKPyB7iqBCN5WQsE1CAHfW0LdaBAD8ILv4vjA/9LYppqLNpbDXcFKn0Ii y3bsUDx6vG/p6hmQMbLiflkW3ISijNkumiOiPqPcI2XBs/A/eZf5ME5Z+6K0kmuwY+Rc SBow== X-Gm-Message-State: APjAAAWYDVR3b0+6FAQikVIo8JTfP+4yEjLZgBS0yEKRhfdHOo26p7vC sisfr/m+uaaxLGg2iOsN14I7Whx/dc+1R9Fxmrc= X-Google-Smtp-Source: APXvYqxfv2EyqUGLefL6YPDjTUgU+9RzpZtW3VpeWS4NWKeLzjVOmFGxdF/bqf7vnxnnpWqjOukkcdiP8wg2O+sVb5E= X-Received: by 2002:a02:a388:: with SMTP id y8mr19182308jak.70.1581517580382; Wed, 12 Feb 2020 06:26:20 -0800 (PST) MIME-Version: 1.0 References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> In-Reply-To: From: Barry Leiba Date: Wed, 12 Feb 2020 09:26:09 -0500 Message-ID: To: Eric Rescorla Cc: Mirja Kuehlewind , Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 14:26:25 -0000 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 wrote: > > > > On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind wr= ote: >> >> Hi Ekr, >> >> Yes, it is specification required, however, if we decide to pushing an R= FC 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=E2=80=99m saying that the process how and where to define QUIC ext= ensions 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 c= hairs and ADs about whether it's orthogonal enough to do separately. It's n= ot in the TLS charter, for instance, AFAICT. > > -Ekr > >> Again that doesn=E2=80=99t mean that in future it will not be possible f= or other groups to define extension but we need to have that discussion fir= st. >> >> Mirja >> >> >> >> > On 11. Feb 2020, at 22:34, Eric Rescorla wrote: >> > >> > >> > >> > On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" wrote: >> > Hi David, >> > >> > I didn=E2=80=99t say that other groups cannot define extension. I did = say that it=E2=80=99s the decision of the working group that maintains the = protocol how to handle that and for Quic we didn=E2=80=99t have had that di= scussion yet. >> > >> > Examples for groups that explicitly define process for extending the p= rotocol in their charter are dhc and 6man. As you can see different groups/= protocols have different process and as we didn=E2=80=99t define anything y= et for Quic, the working assumption for now should be that all extension wo= rk 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 : >> >> >> >> =EF=BB=BF >> >> 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 wrote: >> >> Hi David, >> >> >> >> One more comment below. >> >> >> >> > On 6. Feb 2020, at 14:46, David Schinazi = wrote: >> >> > >> >> > Hi Magnus, >> >> > >> >> > I realized that some of our earlier replies were accidentally not s= ent 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 discussio= n 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 s= ending a WGLC there is not sufficient. >> >> >> >> More generally deciding on processes for other protocols/groups in th= is charter is not appropriate. I=E2=80=99m not sure what the defined proces= s 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 a= re out of scope for this group. Of course that doesn=E2=80=99t mean that th= is 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 adap= t 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=E2=80=A6? >> >> >> >> Mirja >> >> >> >> >> >> >> >> > >> >> > Would that be an acceptable scope? >> >> > >> >> > Thanks, >> >> > David >> >> > >> >> > On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev 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 a= ll >> >> > 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 t= he IETF, >> >> > such as QUIC and HTTPBIS, as appropriate. >> >> > >> >> > With the current state of QUIC developement and HTTP/3 mapping defi= nition, i.e. >> >> > still working on the initial version, I would like to have a more f= irm wording >> >> > that the WebTrans WG will actually have to take any requests for ex= tensions of >> >> > HTTP/3 and QUIC to the relevant WG. >> >> > >> >> > While there are no extensions to QUIC among the proposed WG documen= ts, some of >> >> > the drafts do extend HTTP using custom SETTINGS parameters (which i= s the >> >> > intended HTTP extensibility mechanism). I've hitherto assumed that= webtrans >> >> > would work with HTTP experts in httpbis/quic to ensure that the pro= posed >> >> > 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 formal= ity the >> >> > Web-Transport API has been adopted in W3C and is being worked on. T= rying 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 discussio= ns. >> >> > >> >> > 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 norma= lly involved >> >> > are aware of it, but my current understanding is that the editors o= f the W3C >> >> > spec currently do not believe we have enough real-world implementat= ion >> >> > experience with the proposal to advance it further in the formal pr= ocess. >> >> > >> >> > Having lived through the WebRTC / RTCWeb interactions it would good= to know >> >> > more how the interaction between the bodies are intended to work. E= specially as >> >> > changes to the API can have significant impact on what work needs t= o happen in >> >> > the IETF. >> >> > >> >> > I mostly agree with Bernard here. My plan was that the -overview d= oc 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 ap= pears to >> >> > support multiple parallel transmissions and transfers I think at a = minimal a >> >> > sender transport protocol scheduling or HTTP/3 priority would be l= ikely 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 su= ch 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 HT= TP/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 t= his up >> >> > further, but there's a lot of text to write. >> >> > >> >> > Before I elaborate further, I would like to point out that there ar= e two types >> >> > of priorities here, and those are often confused: >> >> > (1) Priorities that the application indicates to the transport laye= r for the >> >> > purpose of scheduling writes. >> >> > (2) Priorities that are communicated to the peer on the wire as a h= int.... >> >> > >> >> > 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 fo= r >> >> > 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 applicatio= n that uses >> >> > QUIC. >> >> > >> >> > A QUIC implementation SHOULD provide ways in which an application c= an indicate >> >> > the relative priority of streams. When deciding which streams to de= dicate >> >> > resources to, the implementation SHOULD use the information provide= d by the >> >> > application. >> >> > """ >> >> > >> >> > Besides, I don't believe we can avoid defining a write scheduling m= echanism in >> >> > the API. QUIC itself treats it as an implementation detail, but We= b 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 re= ally >> >> > 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 >> From nobody Wed Feb 12 06:31:25 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A44B12003E; Wed, 12 Feb 2020 06:31:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158151788119.17939.481816948087890002.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2020 06:31:21 -0800 Archived-At: Subject: [Webtransport] Alissa Cooper's No Objection on charter-ietf-webtrans-00-01: (with COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 14:31:21 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-webtrans-00-01: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my comments. From nobody Wed Feb 12 06:40:33 2020 Return-Path: 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 In-Reply-To: Date: Wed, 12 Feb 2020 15:40:22 +0100 Cc: Eric Rescorla , Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev Content-Transfer-Encoding: quoted-printable Message-Id: <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> To: Barry Leiba 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: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=E2=80=99t exists yet. All I=E2=80=99m 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 = wrote: >=20 > 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. >=20 > 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. >=20 > Barry >=20 > On Wed, Feb 12, 2020 at 9:15 AM Eric Rescorla wrote: >>=20 >>=20 >>=20 >> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind = wrote: >>>=20 >>> Hi Ekr, >>>=20 >>> 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. >>=20 >>=20 >> 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? >>=20 >>=20 >>>=20 >>> All I=E2=80=99m 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. >>=20 >>=20 >> 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. >>=20 >> -Ekr >>=20 >>> Again that doesn=E2=80=99t mean that in future it will not be = possible for other groups to define extension but we need to have that = discussion first. >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>>> On 11. Feb 2020, at 22:34, Eric Rescorla wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" = wrote: >>>> Hi David, >>>>=20 >>>> I didn=E2=80=99t say that other groups cannot define extension. I = did say that it=E2=80=99s the decision of the working group that = maintains the protocol how to handle that and for Quic we didn=E2=80=99t = have had that discussion yet. >>>>=20 >>>> 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=E2=80=99t define = anything yet for Quic, the working assumption for now should be that all = extension work will be fine in the Quic group. >>>>=20 >>>> Well, the IANA considerations for QUIC transport seem fairly clear: >>>>=20 >>>> = https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4 >>>>=20 >>>> 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.. >>>>=20 >>>> -Ekr >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Mirja >>>>=20 >>>>=20 >>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi = : >>>>>=20 >>>>> =EF=BB=BF >>>>> Hi Mirja, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>>>=20 >>>>> 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 >>>>>=20 >>>>> Additionally, MPTCP is an extension to TCP that was not >>>>> defined in the TCPM WG. The list goes on. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> David >>>>>=20 >>>>>=20 >>>>> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind = wrote: >>>>> Hi David, >>>>>=20 >>>>> One more comment below. >>>>>=20 >>>>>> On 6. Feb 2020, at 14:46, David Schinazi = wrote: >>>>>>=20 >>>>>> Hi Magnus, >>>>>>=20 >>>>>> I realized that some of our earlier replies were accidentally not = sent to >>>>>> the IESG list, for which I apologize. >>>>>>=20 >>>>>> To summarize that discussion: >>>>>>=20 >>>>>> - 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 >>>>>>=20 >>>>>> - 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> More generally deciding on processes for other protocols/groups in = this charter is not appropriate. I=E2=80=99m not sure what the defined = process is for HTTP and TLS but that should be specified in their = charter and not here. >>>>>=20 >>>>> For QUIC, I would like to rather see that extension or = modification are out of scope for this group. Of course that doesn=E2=80=99= 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. >>>>>=20 >>>>> 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=E2=80=A6? >>>>>=20 >>>>> Mirja >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Would that be an acceptable scope? >>>>>>=20 >>>>>> Thanks, >>>>>> David >>>>>>=20 >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev = 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. >>>>>>=20 >>>>>> On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via Datatracker = wrote: >>>>>> Magnus Westerlund has entered the following ballot position for >>>>>> charter-ietf-webtrans-00-00: Block >>>>>>=20 >>>>>> 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.) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> The document, along with other ballot positions, can be found = here: >>>>>> https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> BLOCK: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>>>> [snip] >>>>>>=20 >>>>>> The group will also coordinate with related working groups within = the IETF, >>>>>> such as QUIC and HTTPBIS, as appropriate. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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.. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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.... >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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: >>>>>>=20 >>>>>> """ >>>>>> [QUIC] relies on receiving priority information from the = application that uses >>>>>> QUIC. >>>>>>=20 >>>>>> 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. >>>>>> """ >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Thanks, >>>>>> Victor. >>>>>> -- >>>>>> Webtransport mailing list >>>>>> Webtransport@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/webtransport >>>>>=20 >>>> -- >>>> Webtransport mailing list >>>> Webtransport@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webtransport >>>=20 >=20 >=20 From nobody Wed Feb 12 07:14:09 2020 Return-Path: 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 AA9151200F1 for ; Wed, 12 Feb 2020 07:14:04 -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=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 Lf2aqBtM3hN6 for ; Wed, 12 Feb 2020 07:14:00 -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 204851200E5 for ; Wed, 12 Feb 2020 07:14:00 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id w1so2738616ljh.5 for ; Wed, 12 Feb 2020 07:14:00 -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=oLbUsECxIZYxMJGSQfPy5k/dTkzl4Uqu71aT15f/GjI=; b=umymY1Z9KBwf/K1b3yjpzfziTkuR06ItDpSbKMVgxs8pruhS3WYPQc2IsRu+64KncH RJNuev3mOWKSDoF4EdVKZp/X9evYnG6YzTe88K1s3J87EpCWBFBX3tOv85Ah7w8CdSsM eN0xWivGpIDSi4kVxFbTxI1hYFHNwfkxwZMrGZAa8bZoGjLVgJGQ5z3HuZ3Qso7O9Yuv TQeEbYJM75uzocPR6bb0ISF6u7CUDpymaKDVV+vdlwAj97qrDwV4w8ku51HItGqjeygE 4zDgFQt9vHGuLaKl4aKei3RHwrqYK0j2unkJaTw33Ti5cLrgVfZlzw0dtiUOjELoApMh lPzA== 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=oLbUsECxIZYxMJGSQfPy5k/dTkzl4Uqu71aT15f/GjI=; b=D4xq76AdurX3N+I2Zn+fQeTvEO4FEwakAj9xPsHAp6bO8COH94xP9q07R5Trcz6ZHY RLg1tk2J7URQ//Rvo3iqAR/OfF2iCFxZRDigCHnAt01C+sot0CtL1OPyVqLzYr1oB7No 4eKn9Uj213UUN33eMZKpqJzym/4KiGJnTQwD0489NRXhiBqSSYYo02dBqokNHE1Pzub2 t6r1O0JpTGRChz/UyfymvQs4GgixjHE4KN2+Jw5IauSAQTxfh4pcINg2JS7Gj+ytTfUl XaUALjq4McAp7NGSpTCIjq0JKWP+4fmdH0AvB3z8QM/yaSIdzPCnYDt+cE0EkZ0vas25 8vUQ== X-Gm-Message-State: APjAAAX1XFrDwJmScUhkDwYqwlADogb8kazFMB74xvVi13vshFMDYDc6 bk8IJn+QSlzL59Qw9VQnPguJZm85miJIzzFhpmGJog== X-Google-Smtp-Source: APXvYqyoIX4QO6sCDxtrAQDY1Xt/bS10yKCkDWbtBBLyi0pxvYUFjujbPEXBs0V390Qg4p4sHmZv+OCd/T4AEo0uw/0= X-Received: by 2002:a2e:b5a5:: with SMTP id f5mr7891648ljn.162.1581520438088; Wed, 12 Feb 2020 07:13:58 -0800 (PST) MIME-Version: 1.0 References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> In-Reply-To: <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> From: Eric Rescorla Date: Wed, 12 Feb 2020 07:13:21 -0800 Message-ID: To: Mirja Kuehlewind Cc: Barry Leiba , Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev Content-Type: multipart/alternative; boundary="000000000000eae74e059e626b00" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 15:14:05 -0000 --000000000000eae74e059e626b00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind wrote: > The whole point is that the QUIC protocol is not finished yet and the > respective registry doesn=E2=80=99t exists yet. And WebTransport will have a normative dependency on QUIC and therefore will not be finished prior to that registry existing. All I=E2=80=99m saying that we should not bake process in the the webtransp= ort > charter that might restrict a future discuss we want to have in the QUIC > group. > What future discussion? As I said, the IANA considerations implicit decide this matter. Is someone arguing to change those to Standards Track? -Ekr > > > On 12. Feb 2020, at 15:26, Barry Leiba 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 wrote: > >> > >> > >> > >> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind > wrote: > >>> > >>> Hi Ekr, > >>> > >>> Yes, it is specification required, however, if we decide to pushing a= n > 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=E2=80=99m 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 wh= en > some WG wants to define a TLS extension there's a brief discussion betwee= n > 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=E2=80=99t mean that in future it will not be possibl= e for > other groups to define extension but we need to have that discussion firs= t. > >>> > >>> Mirja > >>> > >>> > >>> > >>>> On 11. Feb 2020, at 22:34, Eric Rescorla wrote: > >>>> > >>>> > >>>> > >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" < > ietf@kuehlewind.net> wrote: > >>>> Hi David, > >>>> > >>>> I didn=E2=80=99t say that other groups cannot define extension. I di= d say > that it=E2=80=99s the decision of the working group that maintains the pr= otocol how > to handle that and for Quic we didn=E2=80=99t have had that discussion ye= t. > >>>> > >>>> 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=E2=80=99t define a= nything > 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>: > >>>>> > >>>>> =EF=BB=BF > >>>>> Hi Mirja, > >>>>> > >>>>> I'm not sure I agree with your interpretation. The fact that a WG i= s > >>>>> 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 > 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/file= s > >>>>>> > >>>>>> - 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=E2=80=99m not sure what the defined pr= ocess is > for HTTP and TLS but that should be specified in their charter and not he= re. > >>>>> > >>>>> For QUIC, I would like to rather see that extension or modification > are out of scope for this group. Of course that doesn=E2=80=99t 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 ada= pt > 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=E2=80= =A6? > >>>>> > >>>>> Mirja > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> Would that be an acceptable scope? > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> > >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev > 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 > 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 tha= t > webtrans > >>>>>> would work with HTTP experts in httpbis/quic to ensure that the > proposed > >>>>>> extensions are architecturally sound and follow best practices, bu= t > 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 ha= d > 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 goo= d > 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 attempte= d > 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 f= or > >>>>>> 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 > >>> > > > > > > --000000000000eae74e059e626b00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 12, 2020 at 6:40 AM Mirja= Kuehlewind <ietf@kuehlewind.net<= /a>> wrote:
T= he whole point is that the QUIC protocol is not finished yet and the respec= tive registry doesn=E2=80=99t exists yet.


All I=E2=80= =99m 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 protocol= s
> that define Specification Required extension mechanisms where we say > that the original working group should be in control of the
> extensions.=C2=A0 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.=C2=A0 And in this case, the charter explicitly says that > webtrans will coordinate with quic.=C2=A0 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> wro= te:
>>>
>>> Hi Ekr,
>>>
>>> Yes, it is specification required, however, if we decide to pu= shing 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 pu= blished, anyone else in the world can assign new QUIC code points, but insi= de the IETF, until there;s some discussion in the QUIC there won't be a= ny process other than asking the QUIC WG?
>>
>>
>>>
>>> All I=E2=80=99m saying that the process how and where to defin= e QUIC extensions in the IETF needs to be decided by the QUIC group and a f= uture 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 discussio= n 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=E2=80=99t mean that in future it will not be = possible for other groups to define extension but we need to have that disc= ussion 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=C3=BChlewind= (IETF)" <= ietf@kuehlewind.net> wrote:
>>>> Hi David,
>>>>
>>>> I didn=E2=80=99t say that other groups cannot define exten= sion. I did say that it=E2=80=99s the decision of the working group that ma= intains the protocol how to handle that and for Quic we didn=E2=80=99t have= had that discussion yet.
>>>>
>>>> Examples for groups that explicitly define process for ext= ending the protocol in their charter are dhc and 6man. As you can see diffe= rent groups/protocols have different process and as we didn=E2=80=99t defin= e 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 fair= ly clear:
>>>>
>>>> https://tool= s.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4
>>>>
>>>> Most of the code points are assigned via Specification Req= uired, so I don't see why you would infer that all extensions happen wi= thin the QUIC WG..
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Mirja
>>>>
>>>>
>>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi <dschinazi.ietf@gm= ail.com>:
>>>>>
>>>>> =EF=BB=BF
>>>>> 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 wo= rking groups
>>>>> cannot write extensions to that protocol.
>>>>>
>>>>> For example, the QUIC WG is defining the quic_transpor= t_parameters
>>>>> TLS extension. That extension is not defined in the TL= S WG.
>>>>> https://tools.iet= f.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.ie= tf.org/html/draft-ietf-acme-star-11#section-6.7
>>>>>
>>>>> Additionally, MPTCP is an extension to TCP that was no= t
>>>>> defined in the TCPM WG. The list goes on.
>>>>>
>>>>> We don't yet have examples for QUIC as the QUIC IA= NA
>>>>> 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 <<= a href=3D"mailto:ietf@kuehlewind.net" target=3D"_blank">ietf@kuehlewind.net= > wrote:
>>>>> Hi David,
>>>>>
>>>>> One more comment below.
>>>>>
>>>>>> On 6. Feb 2020, at 14:46, David Schinazi <dschinazi.ietf@gma= il.com> wrote:
>>>>>>
>>>>>> Hi Magnus,
>>>>>>
>>>>>> I realized that some of our earlier replies were a= ccidentally 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 be= nefit
>>>>>> from their security and congestion control propert= ies.
>>>>>> Here is a PR to the charter that should clarify th= is:
>>>>>> 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 w= ould
>>>>>> happen in their existing respective working groups= .
>>>>>> However, discussion of extensions to these protoco= ls could
>>>>>> be allowed in this WG, as long as any document WGL= C 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 g= roup. So just sending a WGLC there is not sufficient.
>>>>>
>>>>> More generally deciding on processes for other protoco= ls/groups in this charter is not appropriate. I=E2=80=99m 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=E2=80= =99t mean that this group cannot talk about any extension but as soon as th= e 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=E2=80=A6?
>>>>>
>>>>> Mirja
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Would that be an acceptable scope?
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev &l= t;vasilvv@google.co= m> wrote:
>>>>>> I believe most of those have been addressed in Dav= id'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 inta= ct 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, c= an be found here:
>>>>>> https://datatracker.= ietf.org/doc/charter-ietf-webtrans/
>>>>>>
>>>>>>
>>>>>>
>>>>>> --------------------------------------------------= --------------------
>>>>>> BLOCK:
>>>>>> --------------------------------------------------= --------------------
>>>>>>
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>> The group will also coordinate with related workin= g groups within the IETF,
>>>>>> such as QUIC and HTTPBIS, as appropriate.
>>>>>>
>>>>>> With the current state of QUIC developement and HT= TP/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 an= y requests for extensions of
>>>>>> HTTP/3 and QUIC to the relevant WG.
>>>>>>
>>>>>> While there are no extensions to QUIC among the pr= oposed WG documents, some of
>>>>>> the drafts do extend HTTP using custom SETTINGS pa= rameters (which is the
>>>>>> intended HTTP extensibility mechanism).=C2=A0 I= 9;ve hitherto assumed that webtrans
>>>>>> would work with HTTP experts in httpbis/quic to en= sure that the proposed
>>>>>> extensions are architecturally sound and follow be= st practices, but the main
>>>>>> bulk of work would be done in the new working grou= p itself.
>>>>>>
>>>>>> --------------------------------------------------= --------------------
>>>>>> COMMENT:
>>>>>> --------------------------------------------------= --------------------
>>>>>>
>>>>>> I also would appreciate if someone can clarify wha= t stage of formality the
>>>>>> Web-Transport API has been adopted in W3C and is b= eing worked on. Trying to
>>>>>> find anything about which group it belongs to on t= he W3C page didn't give me
>>>>>> any information. All I found is that there have be= en a workshop on game
>>>>>> communication where this was discussed and raised = in some discussions.
>>>>>>
>>>>>> It's a WICG draft, which basically means no fo= rmal status..=C2=A0 We had a discussion
>>>>>> session at TPAC last year, and I believe most peop= le who'd be normally involved
>>>>>> are aware of it, but my current understanding is t= hat 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 interacti= ons it would good to know
>>>>>> more how the interaction between the bodies are in= tended 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.=C2=A0 My plan wa= s that the -overview doc would
>>>>>> list all of the protocol requirements and API expe= ctations, acting as
>>>>>> integration point between W3C and IETF specs.
>>>>>>
>>>>>> The current API draft does not include any discuss= ion of priority. However
>>>>>> draft-vvv-webtrans-overview does mention prioritie= s. As this API appears to
>>>>>> support multiple parallel transmissions and transf= ers I think at a minimal a
>>>>>> sender transport protocol scheduling or HTTP/3 pri= ority=C2=A0 would be likely to be
>>>>>> part of the work. I also have to ask if this is li= kely 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 rai= sed. Otherwise I would assume
>>>>>> that at most what this work will be to use the und= efined APIs to HTTP/3 and
>>>>>> QUIC to influence those protocol to perform stream= priorities..
>>>>>>
>>>>>> This is mostly a gap in the API spec.=C2=A0 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:<= br> >>>>>> (1) Priorities that the application indicates to t= he transport layer for the
>>>>>>=C2=A0 =C2=A0 purpose of scheduling writes.
>>>>>> (2) Priorities that are communicated to the peer o= n the wire as a hint....
>>>>>>
>>>>>> Most of the discussion in HTTPBIS and QUIC WGs was= about #2.=C2=A0 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.=C2=A0 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 fr= om the application that uses
>>>>>> QUIC.
>>>>>>
>>>>>> A QUIC implementation SHOULD provide ways in which= an application can indicate
>>>>>> the relative priority of streams. When deciding wh= ich streams to dedicate
>>>>>> resources to, the implementation SHOULD use the in= formation provided by the
>>>>>> application.
>>>>>> """
>>>>>>
>>>>>> Besides, I don't believe we can avoid defining= a write scheduling mechanism in
>>>>>> the API.=C2=A0 QUIC itself treats it as an impleme= ntation detail, but Web APIs
>>>>>> generally try really hard to avoid implementation-= defined behavior.=C2=A0 If
>>>>>> every browser had a completely different write sch= eduling approach,
>>>>>> that could make the job of writing performant cros= s-browser code really
>>>>>> difficult.
>>>>>>
>>>>>> Thanks,
>>>>>>=C2=A0 Victor.
>>>>>> --
>>>>>> Webtransport mailing list
>>>>>> Webtransport@ietf.org
>>>>>> https://www.ietf.org/mail= man/listinfo/webtransport
>>>>>
>>>> --
>>>> Webtransport mailing list
>>>> Webtransport@ietf.org
>>>> https://www.ietf.org/mailman/list= info/webtransport
>>>
>
>

--000000000000eae74e059e626b00-- From nobody Wed Feb 12 07:17:26 2020 Return-Path: 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 B26FA1200A3; Wed, 12 Feb 2020 07:17:23 -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 OwUOKqddzX3m; Wed, 12 Feb 2020 07:17:20 -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 0DA46120013; Wed, 12 Feb 2020 07:17:20 -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 1j1tlL-0000Pa-Sp; Wed, 12 Feb 2020 16:17:15 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 12 Feb 2020 16:17:14 +0100 Cc: Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev , Barry Leiba Content-Transfer-Encoding: quoted-printable Message-Id: <84F34F5C-DFD6-42F6-9B12-BD10F2B37DB5@kuehlewind.net> References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581520640;521af2de; X-HE-SMSGID: 1j1tlL-0000Pa-Sp Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 15:17:24 -0000 > On 12. Feb 2020, at 16:13, Eric Rescorla wrote: >=20 >=20 >=20 > On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind = wrote: > The whole point is that the QUIC protocol is not finished yet and the = respective registry doesn=E2=80=99t exists yet. >=20 > And WebTransport will have a normative dependency on QUIC and = therefore will not be finished prior to that registry existing. But the charter will be finished before that and we need to decide now = what to write in there. That=E2=80=99s what we are discussing. >=20 >=20 > All I=E2=80=99m 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. >=20 > What future discussion? As I said, the IANA considerations implicit = decide this matter. Is someone arguing to change those to Standards = Track? As Magnus wrote several times in the resented re-chartering discussion: "A reason for the two step rechartering is that I think we will need to = have a serious discussion of how to work on v2 and extensions more generally. I = think going into these details now is premature. But we will need to come back = to this later.=E2=80=9D Mirja >=20 > -Ekr >=20 >=20 >=20 > > On 12. Feb 2020, at 15:26, Barry Leiba = wrote: > >=20 > > 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. > >=20 > > 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. > >=20 > > Barry > >=20 > > On Wed, Feb 12, 2020 at 9:15 AM Eric Rescorla wrote: > >>=20 > >>=20 > >>=20 > >> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind = wrote: > >>>=20 > >>> Hi Ekr, > >>>=20 > >>> 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. > >>=20 > >>=20 > >> 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? > >>=20 > >>=20 > >>>=20 > >>> All I=E2=80=99m 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. > >>=20 > >>=20 > >> 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. > >>=20 > >> -Ekr > >>=20 > >>> Again that doesn=E2=80=99t mean that in future it will not be = possible for other groups to define extension but we need to have that = discussion first. > >>>=20 > >>> Mirja > >>>=20 > >>>=20 > >>>=20 > >>>> On 11. Feb 2020, at 22:34, Eric Rescorla wrote: > >>>>=20 > >>>>=20 > >>>>=20 > >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" = wrote: > >>>> Hi David, > >>>>=20 > >>>> I didn=E2=80=99t say that other groups cannot define extension. I = did say that it=E2=80=99s the decision of the working group that = maintains the protocol how to handle that and for Quic we didn=E2=80=99t = have had that discussion yet. > >>>>=20 > >>>> 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=E2=80=99t define = anything yet for Quic, the working assumption for now should be that all = extension work will be fine in the Quic group. > >>>>=20 > >>>> Well, the IANA considerations for QUIC transport seem fairly = clear: > >>>>=20 > >>>> = https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4 > >>>>=20 > >>>> 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.. > >>>>=20 > >>>> -Ekr > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>>=20 > >>>> Mirja > >>>>=20 > >>>>=20 > >>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi = : > >>>>>=20 > >>>>> =EF=BB=BF > >>>>> Hi Mirja, > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> 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 > >>>>>=20 > >>>>> 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 > >>>>>=20 > >>>>> Additionally, MPTCP is an extension to TCP that was not > >>>>> defined in the TCPM WG. The list goes on. > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> David > >>>>>=20 > >>>>>=20 > >>>>> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind = wrote: > >>>>> Hi David, > >>>>>=20 > >>>>> One more comment below. > >>>>>=20 > >>>>>> On 6. Feb 2020, at 14:46, David Schinazi = wrote: > >>>>>>=20 > >>>>>> Hi Magnus, > >>>>>>=20 > >>>>>> I realized that some of our earlier replies were accidentally = not sent to > >>>>>> the IESG list, for which I apologize. > >>>>>>=20 > >>>>>> To summarize that discussion: > >>>>>>=20 > >>>>>> - 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 > >>>>>>=20 > >>>>>> - 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. > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> More generally deciding on processes for other protocols/groups = in this charter is not appropriate. I=E2=80=99m not sure what the = defined process is for HTTP and TLS but that should be specified in = their charter and not here. > >>>>>=20 > >>>>> For QUIC, I would like to rather see that extension or = modification are out of scope for this group. Of course that doesn=E2=80=99= 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. > >>>>>=20 > >>>>> 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=E2=80=A6? > >>>>>=20 > >>>>> Mirja > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>>=20 > >>>>>> Would that be an acceptable scope? > >>>>>>=20 > >>>>>> Thanks, > >>>>>> David > >>>>>>=20 > >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev = 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.. > >>>>>>=20 > >>>>>> On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via = Datatracker wrote: > >>>>>> Magnus Westerlund has entered the following ballot position for > >>>>>> charter-ietf-webtrans-00-00: Block > >>>>>>=20 > >>>>>> 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.) > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> The document, along with other ballot positions, can be found = here: > >>>>>> https://datatracker.ietf.org/doc/charter-ietf-webtrans/ > >>>>>>=20 > >>>>>>=20 > >>>>>>=20 > >>>>>> = ---------------------------------------------------------------------- > >>>>>> BLOCK: > >>>>>> = ---------------------------------------------------------------------- > >>>>>>=20 > >>>>>>=20 > >>>>>> [snip] > >>>>>>=20 > >>>>>> The group will also coordinate with related working groups = within the IETF, > >>>>>> such as QUIC and HTTPBIS, as appropriate. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> = ---------------------------------------------------------------------- > >>>>>> COMMENT: > >>>>>> = ---------------------------------------------------------------------- > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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.. > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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.... > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> 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: > >>>>>>=20 > >>>>>> """ > >>>>>> [QUIC] relies on receiving priority information from the = application that uses > >>>>>> QUIC. > >>>>>>=20 > >>>>>> 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. > >>>>>> """ > >>>>>>=20 > >>>>>> 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. > >>>>>>=20 > >>>>>> Thanks, > >>>>>> Victor. > >>>>>> -- > >>>>>> Webtransport mailing list > >>>>>> Webtransport@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/webtransport > >>>>>=20 > >>>> -- > >>>> Webtransport mailing list > >>>> Webtransport@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/webtransport > >>>=20 > >=20 > >=20 >=20 From nobody Wed Feb 12 07:21:59 2020 Return-Path: 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 E2EAF1200E7 for ; Wed, 12 Feb 2020 07:21:57 -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 69DzjpPMWNmX for ; Wed, 12 Feb 2020 07:21:54 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D4B5F1200A3 for ; Wed, 12 Feb 2020 07:21:53 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id z18so1894317lfe.2 for ; Wed, 12 Feb 2020 07:21:53 -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=WKyWXKacIWRklKE46cH+3N6JKgw+lrteB2ZPq+6YDnE=; b=0RG8tU3GBRcxRKa1d0muWkAfEcc6l6Z/2UgFlaJ46cYw0UTZI6a6ys9w+jp7Wm+10i upU1RRtlBTCtap7AVI06pXgoZ3XIEYNyYUjq31B5HBHypudXP9ojRq5GrTRzgx5h4bIg IwB80EGEgV5HXp7JkMeTRdmZegVJD7Cd6OzzIxeW5nxMNRVLgty9BIPlu5iLcmNM/ibZ vcDOw4QaDbOXs3YuLWbMCQypW+PqHQZcBbvoz82PIySPy/Yr9nRc/x4VOw7Ml5ZQ7bXN snV8GWoGLKnFTxUiTclDAZ+8qnJXZwMzSh5iSAYThgNuk6EMWlG7zMkmsTiMOW1c/Voq YE0Q== 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=WKyWXKacIWRklKE46cH+3N6JKgw+lrteB2ZPq+6YDnE=; b=s+J7YU1mmWDHCkmtiOChp46EYUpY3bosvt2yFfmEbh88jGEeBT2tonlXVX/OznhWn0 wS9ALUgVOW/lz9KwU2BZDPVQpNq+RS02SvCtUZ8Am9JYfNl70N1MAih9E80HNaUGubeu jcDiGrRtnZ8inmdG1JGk6wvf+8LF4OKwoDWlIPiLrkgDSUOU+CEbRr6DG6O5hET9UFGM lrRYPIzJQsIsSDfNer5eoukefFTykoVi3EVrT1lENskWCLyuRXIpCyN8BcdrmIPwZtGH vAr90ZHBsBAS1W8stuC6Pcz0RXaetQpAXJedX+RGk1w27IUYFyvM6nk9c1EYUjNUT4g7 OnyA== X-Gm-Message-State: APjAAAWFs/D8sI3M5b7D+f/yEdA4VwVy74b9cHv+9rZXvML+b5ZgxX1R ALknMrfSs7LtkrdV68IRtU55APceo4yoWyayX5zJNA== X-Google-Smtp-Source: APXvYqxSOqhrz8/Pgsd2wH5QLN1sE2YrrkJkiu3CpoHNSUJ6lDg0fwaTHGN6dHWUQ+jzBF9iIdZs9BWFrTk3keX3AHw= X-Received: by 2002:ac2:53b9:: with SMTP id j25mr6781219lfh.140.1581520911803; Wed, 12 Feb 2020 07:21:51 -0800 (PST) MIME-Version: 1.0 References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> <84F34F5C-DFD6-42F6-9B12-BD10F2B37DB5@kuehlewind.net> In-Reply-To: <84F34F5C-DFD6-42F6-9B12-BD10F2B37DB5@kuehlewind.net> From: Eric Rescorla Date: Wed, 12 Feb 2020 07:21:15 -0800 Message-ID: To: Mirja Kuehlewind Cc: Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev , Barry Leiba Content-Type: multipart/alternative; boundary="000000000000273b37059e62882f" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 15:21:58 -0000 --000000000000273b37059e62882f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, I don't really agree that this needs to be a live issue, but as you insist: Extensions to QUIC should be possible in WGs across the IETF, with proper coordination with the QUIC WG. This isn't really a decision for the QUIC WG, but rather for the IESG, In any case, this is precisely what is contemplated by the current draft. If you think this needs to go in some charter text, then it should go there now. -Ekr On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind wrote: > > > > On 12. Feb 2020, at 16:13, Eric Rescorla wrote: > > > > > > > > On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind > wrote: > > The whole point is that the QUIC protocol is not finished yet and the > respective registry doesn=E2=80=99t exists yet. > > > > And WebTransport will have a normative dependency on QUIC and therefore > will not be finished prior to that registry existing. > > But the charter will be finished before that and we need to decide now > what to write in there. That=E2=80=99s what we are discussing. > > > > > > > All I=E2=80=99m saying that we should not bake process in the the webtr= ansport > charter that might restrict a future discuss we want to have in the QUIC > group. > > > > What future discussion? As I said, the IANA considerations implicit > decide this matter. Is someone arguing to change those to Standards Track= ? > > As Magnus wrote several times in the resented re-chartering discussion: > > "A reason for the two step rechartering is that I think we will need to > have a > serious discussion of how to work on v2 and extensions more generally. I > think > going into these details now is premature. But we will need to come back > to this > later.=E2=80=9D > > Mirja > > > > > > > -Ekr > > > > > > > > > On 12. Feb 2020, at 15:26, Barry Leiba > 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 th= e > > > 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 wrote: > > >> > > >> > > >> > > >> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind > 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=E2=80=99m saying that the process how and where to define QUI= C > 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 wh= en > some WG wants to define a TLS extension there's a brief discussion betwee= n > 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=E2=80=99t mean that in future it will not be possi= ble for > other groups to define extension but we need to have that discussion firs= t. > > >>> > > >>> Mirja > > >>> > > >>> > > >>> > > >>>> On 11. Feb 2020, at 22:34, Eric Rescorla wrote: > > >>>> > > >>>> > > >>>> > > >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" < > ietf@kuehlewind.net> wrote: > > >>>> Hi David, > > >>>> > > >>>> I didn=E2=80=99t say that other groups cannot define extension. I = did say > that it=E2=80=99s the decision of the working group that maintains the pr= otocol how > to handle that and for Quic we didn=E2=80=99t have had that discussion ye= t. > > >>>> > > >>>> 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=E2=80=99t define a= nything > 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, s= o > I don't see why you would infer that all extensions happen within the QUI= C > WG.. > > >>>> > > >>>> -Ekr > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> Mirja > > >>>> > > >>>> > > >>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi < > dschinazi.ietf@gmail.com>: > > >>>>> > > >>>>> =EF=BB=BF > > >>>>> 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 group= s > > >>>>> cannot write extensions to that protocol. > > >>>>> > > >>>>> For example, the QUIC WG is defining the quic_transport_parameter= s > > >>>>> 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 no= t > 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 i= n > this charter is not appropriate. I=E2=80=99m not sure what the defined pr= ocess is > for HTTP and TLS but that should be specified in their charter and not he= re. > > >>>>> > > >>>>> For QUIC, I would like to rather see that extension or > modification are out of scope for this group. Of course that doesn=E2=80= =99t 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 canno= t > 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= =E2=80=A6? > > >>>>> > > >>>>> 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 Datatracke= r > 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 t= o > 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 withi= n > 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 mor= e > 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 (whic= h > 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 editor= s > 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 need= s > to happen in > > >>>>>> the IETF. > > >>>>>> > > >>>>>> I mostly agree with Bernard here. My plan was that the -overvie= w > 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 b= e > 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 writ= e > 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 applicatio= n > 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 schedulin= g > 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 > > >>> > > > > > > > > > > --000000000000273b37059e62882f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, I don't really agree that this needs to be = a live issue, but as you insist:
Extensions to QUIC should be pos= sible in WGs across the IETF, with proper coordination with the QUIC WG. Th= is isn't really a decision for the QUIC WG, but rather for the IESG, In= any case, this is precisely what is contemplated by the current draft. If = you think this needs to go in some charter text, then it should go there no= w.

-Ekr


On Wed, Feb 12, 2020= at 7:17 AM Mirja Kuehlewind <iet= f@kuehlewind.net> wrote:


> On 12. Feb 2020, at 16:13, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
>
> On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:<= br> > The whole point is that the QUIC protocol is not finished yet and the = respective registry doesn=E2=80=99t exists yet.
>
> And WebTransport will have a normative dependency on QUIC and therefor= e will not be finished prior to that registry existing.

But the charter will be finished before that and we need to decide now what= to write in there. That=E2=80=99s what we are discussing.

>
>
> All I=E2=80=99m saying that we should not bake process in the the webt= ransport charter that might restrict a future discuss we want to have in th= e QUIC group.
>
> What future discussion? As I said, the IANA considerations implicit de= cide this matter. Is someone arguing to change those to Standards Track?
As Magnus wrote several times in the resented re-chartering discussion:

"A reason for the two step rechartering is that I think we will need t= o have a
serious discussion of how to work on v2 and extensions more generally. I th= ink
going into these details now is premature. But we will need to come back to= this
later.=E2=80=9D

Mirja



>
> -Ekr
>
>
>
> > On 12. Feb 2020, at 15:26, Barry Leiba <barryleiba@computer.org> wrot= e:
> >
> > I have to agree with EKR here: I'm not aware of any other pro= tocols
> > that define Specification Required extension mechanisms where we = say
> > that the original working group should be in control of the
> > extensions.=C2=A0 I wouldn't want to start it here.
> >
> > The ADs will designate experts to review the extension specificat= ions,
> > and that is the mechanism for the working group to have its say i= n the
> > extensions.=C2=A0 And in this case, the charter explicitly says t= hat
> > webtrans will coordinate with quic.=C2=A0 I see no reason to be m= ore
> > 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&g= t; 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=E2=80=99m saying that the process how and where to = define QUIC extensions in the IETF needs to be decided by the QUIC group an= d a future QUIC charter and not by the charter of any other working group.<= br> > >>
> >>
> >> I don't understand what process you think requires this. = There was never any such formal discussion in the TLS WG AFAIK. In my exper= ience when some WG wants to define a TLS extension there's a brief disc= ussion 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=E2=80=99t mean that in future it will no= t 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=C3=BChl= ewind (IETF)" <ietf@kuehlewind.net> wrote:
> >>>> Hi David,
> >>>>
> >>>> I didn=E2=80=99t say that other groups cannot define = extension. I did say that it=E2=80=99s the decision of the working group th= at maintains the protocol how to handle that and for Quic we didn=E2=80=99t= have had that discussion yet.
> >>>>
> >>>> Examples for groups that explicitly define process fo= r extending the protocol in their charter are dhc and 6man. As you can see = different groups/protocols have different process and as we didn=E2=80=99t = 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 Specificatio= n Required, so I don't see why you would infer that all extensions happ= en within the QUIC WG..
> >>>>
> >>>> -Ekr
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Mirja
> >>>>
> >>>>
> >>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi <= ;dschinazi.ie= tf@gmail.com>:
> >>>>>
> >>>>> =EF=BB=BF
> >>>>> 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 oth= er working groups
> >>>>> cannot write extensions to that protocol.
> >>>>>
> >>>>> For example, the QUIC WG is defining the quic_tra= nsport_parameters
> >>>>> TLS extension. That extension is not defined in t= he TLS WG.
> >>>>> https://tool= s.ietf.org/html/draft-ietf-quic-tls-25#section-8.2
> >>>>>
> >>>>> Similarly, the ACME WG is defining the Cert-Not-B= efore HTTP
> >>>>> header, not the HTTP WG.
> >>>>> https://too= ls.ietf.org/html/draft-ietf-acme-star-11#section-6.7
> >>>>>
> >>>>> Additionally, MPTCP is an extension to TCP that w= as not
> >>>>> defined in the TCPM WG. The list goes on.
> >>>>>
> >>>>> We don't yet have examples for QUIC as the QU= IC IANA
> >>>>> registries haven't been created yet, but I do= n'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@kuehlewin= d.net> wrote:
> >>>>> Hi David,
> >>>>>
> >>>>> One more comment below.
> >>>>>
> >>>>>> On 6. Feb 2020, at 14:46, David Schinazi <= dschinazi.iet= f@gmail.com> wrote:
> >>>>>>
> >>>>>> Hi Magnus,
> >>>>>>
> >>>>>> I realized that some of our earlier replies w= ere accidentally not sent to
> >>>>>> the IESG list, for which I apologize.
> >>>>>>
> >>>>>> To summarize that discussion:
> >>>>>>
> >>>>>> - It is not our intention to build a new tran= sport protocol here.
> >>>>>> The WEBTRANS WG would build application proto= cols that
> >>>>>> run over QUIC, or TLS/TCP. This would ensure = we benefit
> >>>>>> from their security and congestion control pr= operties.
> >>>>>> Here is a PR to the charter that should clari= fy this:
> >>>>>> htt= ps://github.com/DavidSchinazi/webtrans-wg-materials/pull/6/files
> >>>>>>
> >>>>>> - The WEBTRANS WG would not modify QUIC or HT= TP.
> >>>>>> Any discussion of modifying those core protoc= ols would
> >>>>>> happen in their existing respective working g= roups..
> >>>>>> However, discussion of extensions to these pr= otocols could
> >>>>>> be allowed in this WG, as long as any documen= t 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 t= hink the assumption should be that all extensions will be done within the Q= UIC group. So just sending a WGLC there is not sufficient.
> >>>>>
> >>>>> More generally deciding on processes for other pr= otocols/groups in this charter is not appropriate. I=E2=80=99m not sure wha= t the defined process is for HTTP and TLS but that should be specified in t= heir charter and not here.
> >>>>>
> >>>>> For QUIC, I would like to rather see that extensi= on or modification are out of scope for this group. Of course that doesn=E2= =80=99t 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 i= s for TLS and HTTP. I assume for TLS it's the same but for HTTP it migh= t be different=E2=80=A6?
> >>>>>
> >>>>> Mirja
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Would that be an acceptable scope?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> David
> >>>>>>
> >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasili= ev <vasilvv@goog= le.com> wrote:
> >>>>>> I believe most of those have been addressed i= n David's PR, so I'll try to reply
> >>>>>> primarily to those that I have something to a= dd to..
> >>>>>>
> >>>>>> On Fri, Jan 31, 2020 at 5:39 PM Magnus Wester= lund via Datatracker <noreply@ietf..org> wrote:
> >>>>>> Magnus Westerlund has entered the following b= allot 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 lin= es. (Feel free to cut this
> >>>>>> introductory paragraph, however.)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The document, along with other ballot positio= ns, can be found here:
> >>>>>> https://datatra= cker.ietf.org/doc/charter-ietf-webtrans/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------= -------------------------
> >>>>>> BLOCK:
> >>>>>> ---------------------------------------------= -------------------------
> >>>>>>
> >>>>>>
> >>>>>> [snip]
> >>>>>>
> >>>>>> The group will also coordinate with related w= orking groups within the IETF,
> >>>>>> such as QUIC and HTTPBIS, as appropriate.
> >>>>>>
> >>>>>> With the current state of QUIC developement a= nd 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 ta= ke any requests for extensions of
> >>>>>> HTTP/3 and QUIC to the relevant WG.
> >>>>>>
> >>>>>> While there are no extensions to QUIC among t= he proposed WG documents, some of
> >>>>>> the drafts do extend HTTP using custom SETTIN= GS parameters (which is the
> >>>>>> intended HTTP extensibility mechanism).=C2=A0= I've hitherto assumed that webtrans
> >>>>>> would work with HTTP experts in httpbis/quic = to ensure that the proposed
> >>>>>> extensions are architecturally sound and foll= ow 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 clarif= y 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 ha= ve been a workshop on game
> >>>>>> communication where this was discussed and ra= ised in some discussions.
> >>>>>>
> >>>>>> It's a WICG draft, which basically means = no formal status..=C2=A0 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 fu= rther in the formal process.
> >>>>>>
> >>>>>> Having lived through the WebRTC / RTCWeb inte= ractions it would good to know
> >>>>>> more how the interaction between the bodies a= re intended to work. Especially as
> >>>>>> changes to the API can have significant impac= t on what work needs to happen in
> >>>>>> the IETF.
> >>>>>>
> >>>>>> I mostly agree with Bernard here.=C2=A0 My pl= an 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 di= scussion of priority. However
> >>>>>> draft-vvv-webtrans-overview does mention prio= rities. As this API appears to
> >>>>>> support multiple parallel transmissions and t= ransfers I think at a minimal a
> >>>>>> sender transport protocol scheduling or HTTP/= 3 priority=C2=A0 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 ex= ample DSCPs? If any such work is
> >>>>>> expected and intended I think that needs to b= e raised. Otherwise I would assume
> >>>>>> that at most what this work will be to use th= e undefined APIs to HTTP/3 and
> >>>>>> QUIC to influence those protocol to perform s= tream priorities..
> >>>>>>
> >>>>>> This is mostly a gap in the API spec.=C2=A0 I= 've been meaning to write this up
> >>>>>> further, but there's a lot of text to wri= te.
> >>>>>>
> >>>>>> Before I elaborate further, I would like to p= oint out that there are two types
> >>>>>> of priorities here, and those are often confu= sed:
> >>>>>> (1) Priorities that the application indicates= to the transport layer for the
> >>>>>>=C2=A0 =C2=A0 purpose of scheduling writes. > >>>>>> (2) Priorities that are communicated to the p= eer on the wire as a hint....
> >>>>>>
> >>>>>> Most of the discussion in HTTPBIS and QUIC WG= s was about #2.=C2=A0 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 firs= t.
> >>>>>>
> >>>>>> The priorities mentioned in -overview are of = the #1 kind.=C2=A0 Section 2.3 of
> >>>>>> draft-ietf-quic-transport-25 explicitly encou= rages implementations (that would
> >>>>>> include the proposed Web APIs) to provide tho= se:
> >>>>>>
> >>>>>> """
> >>>>>> [QUIC] relies on receiving priority informati= on from the application that uses
> >>>>>> QUIC.
> >>>>>>
> >>>>>> A QUIC implementation SHOULD provide ways in = which an application can indicate
> >>>>>> the relative priority of streams. When decidi= ng which streams to dedicate
> >>>>>> resources to, the implementation SHOULD use t= he information provided by the
> >>>>>> application.
> >>>>>> """
> >>>>>>
> >>>>>> Besides, I don't believe we can avoid def= ining a write scheduling mechanism in
> >>>>>> the API.=C2=A0 QUIC itself treats it as an im= plementation detail, but Web APIs
> >>>>>> generally try really hard to avoid implementa= tion-defined behavior.=C2=A0 If
> >>>>>> every browser had a completely different writ= e scheduling approach,
> >>>>>> that could make the job of writing performant= cross-browser code really
> >>>>>> difficult.
> >>>>>>
> >>>>>> Thanks,
> >>>>>>=C2=A0 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
> >>>
> >
> >
>

--000000000000273b37059e62882f-- From nobody Wed Feb 12 07:29:08 2020 Return-Path: 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 22C3C1200A3; Wed, 12 Feb 2020 07:29:07 -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 KfQ8ovd-CWq9; Wed, 12 Feb 2020 07:29:02 -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 75F08120013; Wed, 12 Feb 2020 07:29:02 -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 1j1twf-0002tb-Ry; Wed, 12 Feb 2020 16:28:57 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 12 Feb 2020 16:28:57 +0100 Cc: Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev , Barry Leiba Content-Transfer-Encoding: quoted-printable Message-Id: References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> <84F34F5C-DFD6-42F6-9B12-BD10F2B37DB5@kuehlewind.net> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581521342;05368423; X-HE-SMSGID: 1j1twf-0002tb-Ry Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 15:29:07 -0000 Yes, that is a decision by the IESG so we should not baked it into the = WebTransport charter at this point of time. What I=E2=80=99m requesting = is to rather remove the following sentence from the proposed new charter = text: "The WebTransport working group may define extensions to these = protocols, but any working group last call defining such extensions = shall also be sent to the mailing list of the respective working = group.=E2=80=9D And then the following sentence should probably also be change to remove = the word =E2=80=9Ccore=E2=80=9D or even replace =E2=80=9Cchanges to = these core protocols=E2=80=9D with =E2=80=9Cextension to the respective = protocols=E2=80=9D: "In particular, any changes to these core protocols shall be discussed = in their respective working groups.=E2=80=9D I think it is actually true for all three protocols (QUIC, HTTP, and = TLS) that changes to the _core_ protocol must be done in the = respectively working group.=20 Mirja > On 12. Feb 2020, at 16:21, Eric Rescorla wrote: >=20 > Well, I don't really agree that this needs to be a live issue, but as = you insist: > Extensions to QUIC should be possible in WGs across the IETF, with = proper coordination with the QUIC WG. This isn't really a decision for = the QUIC WG, but rather for the IESG, In any case, this is precisely = what is contemplated by the current draft. If you think this needs to go = in some charter text, then it should go there now. >=20 > -Ekr >=20 >=20 > On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind = wrote: >=20 >=20 > > On 12. Feb 2020, at 16:13, Eric Rescorla wrote: > >=20 > >=20 > >=20 > > On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind = wrote: > > The whole point is that the QUIC protocol is not finished yet and = the respective registry doesn=E2=80=99t exists yet. > >=20 > > And WebTransport will have a normative dependency on QUIC and = therefore will not be finished prior to that registry existing. >=20 > But the charter will be finished before that and we need to decide now = what to write in there. That=E2=80=99s what we are discussing. >=20 > >=20 > >=20 > > All I=E2=80=99m 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. > >=20 > > What future discussion? As I said, the IANA considerations implicit = decide this matter. Is someone arguing to change those to Standards = Track? >=20 > As Magnus wrote several times in the resented re-chartering = discussion: >=20 > "A reason for the two step rechartering is that I think we will need = to have a > serious discussion of how to work on v2 and extensions more generally. = I think > going into these details now is premature. But we will need to come = back to this > later.=E2=80=9D >=20 > Mirja >=20 >=20 >=20 > >=20 > > -Ekr > >=20 > >=20 > >=20 > > > On 12. Feb 2020, at 15:26, Barry Leiba = wrote: > > >=20 > > > 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. > > >=20 > > > 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. > > >=20 > > > Barry > > >=20 > > > On Wed, Feb 12, 2020 at 9:15 AM Eric Rescorla = wrote: > > >>=20 > > >>=20 > > >>=20 > > >> On Wed, Feb 12, 2020 at 2:49 AM Mirja Kuehlewind = wrote: > > >>>=20 > > >>> Hi Ekr, > > >>>=20 > > >>> 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. > > >>=20 > > >>=20 > > >> 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? > > >>=20 > > >>=20 > > >>>=20 > > >>> All I=E2=80=99m 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. > > >>=20 > > >>=20 > > >> 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. > > >>=20 > > >> -Ekr > > >>=20 > > >>> Again that doesn=E2=80=99t mean that in future it will not be = possible for other groups to define extension but we need to have that = discussion first. > > >>>=20 > > >>> Mirja > > >>>=20 > > >>>=20 > > >>>=20 > > >>>> On 11. Feb 2020, at 22:34, Eric Rescorla wrote: > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" = wrote: > > >>>> Hi David, > > >>>>=20 > > >>>> I didn=E2=80=99t say that other groups cannot define extension. = I did say that it=E2=80=99s the decision of the working group that = maintains the protocol how to handle that and for Quic we didn=E2=80=99t = have had that discussion yet. > > >>>>=20 > > >>>> 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=E2=80=99t= define anything yet for Quic, the working assumption for now should be = that all extension work will be fine in the Quic group. > > >>>>=20 > > >>>> Well, the IANA considerations for QUIC transport seem fairly = clear: > > >>>>=20 > > >>>> = https://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4 > > >>>>=20 > > >>>> 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.. > > >>>>=20 > > >>>> -Ekr > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>>=20 > > >>>> Mirja > > >>>>=20 > > >>>>=20 > > >>>>> Am 11.02.2020 um 21:47 schrieb David Schinazi = : > > >>>>>=20 > > >>>>> =EF=BB=BF > > >>>>> Hi Mirja, > > >>>>>=20 > > >>>>> 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. > > >>>>>=20 > > >>>>> 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 > > >>>>>=20 > > >>>>> 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 > > >>>>>=20 > > >>>>> Additionally, MPTCP is an extension to TCP that was not > > >>>>> defined in the TCPM WG. The list goes on. > > >>>>>=20 > > >>>>> 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. > > >>>>>=20 > > >>>>> David > > >>>>>=20 > > >>>>>=20 > > >>>>> On Tue, Feb 11, 2020 at 4:38 AM Mirja Kuehlewind = wrote: > > >>>>> Hi David, > > >>>>>=20 > > >>>>> One more comment below. > > >>>>>=20 > > >>>>>> On 6. Feb 2020, at 14:46, David Schinazi = wrote: > > >>>>>>=20 > > >>>>>> Hi Magnus, > > >>>>>>=20 > > >>>>>> I realized that some of our earlier replies were accidentally = not sent to > > >>>>>> the IESG list, for which I apologize. > > >>>>>>=20 > > >>>>>> To summarize that discussion: > > >>>>>>=20 > > >>>>>> - 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 > > >>>>>>=20 > > >>>>>> - 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. > > >>>>>=20 > > >>>>> 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. > > >>>>>=20 > > >>>>> More generally deciding on processes for other = protocols/groups in this charter is not appropriate. I=E2=80=99m not = sure what the defined process is for HTTP and TLS but that should be = specified in their charter and not here. > > >>>>>=20 > > >>>>> For QUIC, I would like to rather see that extension or = modification are out of scope for this group. Of course that doesn=E2=80=99= 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. > > >>>>>=20 > > >>>>> 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=E2=80=A6? > > >>>>>=20 > > >>>>> Mirja > > >>>>>=20 > > >>>>>=20 > > >>>>>=20 > > >>>>>>=20 > > >>>>>> Would that be an acceptable scope? > > >>>>>>=20 > > >>>>>> Thanks, > > >>>>>> David > > >>>>>>=20 > > >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor Vasiliev = 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.. > > >>>>>>=20 > > >>>>>> On Fri, Jan 31, 2020 at 5:39 PM Magnus Westerlund via = Datatracker wrote: > > >>>>>> Magnus Westerlund has entered the following ballot position = for > > >>>>>> charter-ietf-webtrans-00-00: Block > > >>>>>>=20 > > >>>>>> 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.) > > >>>>>>=20 > > >>>>>>=20 > > >>>>>>=20 > > >>>>>> The document, along with other ballot positions, can be found = here: > > >>>>>> https://datatracker.ietf.org/doc/charter-ietf-webtrans/ > > >>>>>>=20 > > >>>>>>=20 > > >>>>>>=20 > > >>>>>> = ---------------------------------------------------------------------- > > >>>>>> BLOCK: > > >>>>>> = ---------------------------------------------------------------------- > > >>>>>>=20 > > >>>>>>=20 > > >>>>>> [snip] > > >>>>>>=20 > > >>>>>> The group will also coordinate with related working groups = within the IETF, > > >>>>>> such as QUIC and HTTPBIS, as appropriate. > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> = ---------------------------------------------------------------------- > > >>>>>> COMMENT: > > >>>>>> = ---------------------------------------------------------------------- > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> 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.. > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> 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.... > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> 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: > > >>>>>>=20 > > >>>>>> """ > > >>>>>> [QUIC] relies on receiving priority information from the = application that uses > > >>>>>> QUIC. > > >>>>>>=20 > > >>>>>> 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. > > >>>>>> """ > > >>>>>>=20 > > >>>>>> 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. > > >>>>>>=20 > > >>>>>> Thanks, > > >>>>>> Victor. > > >>>>>> -- > > >>>>>> Webtransport mailing list > > >>>>>> Webtransport@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/webtransport > > >>>>>=20 > > >>>> -- > > >>>> Webtransport mailing list > > >>>> Webtransport@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/webtransport > > >>>=20 > > >=20 > > >=20 > >=20 >=20 > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Wed Feb 12 08:48:53 2020 Return-Path: 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 A43531201DC; Wed, 12 Feb 2020 08:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YYaWWeKV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=OhWpY3bv 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 ELWNA3OHraX1; Wed, 12 Feb 2020 08:48:47 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9A71207FF; Wed, 12 Feb 2020 08:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63596; q=dns/txt; s=iport; t=1581526127; x=1582735727; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=NZ2wIxlxzCxb2Iere2y7YP8GWB1O+IsTYOxwbusSFsQ=; b=YYaWWeKV20hQyqyhImuvmwZES7zAweJCWbUYGioXKGb4NyQbjT7LML61 ycSQgGLjMutp/L+bNoptq4GfrhXex+6zqeR2jfDjktADF2ocVI6qmPx5k cRzRxf3hmOvUHQVOCcstfZFCZzQVViAyLQ9Dc9tsYsdJ4uOONXvY1yALb M=; IronPort-PHdr: =?us-ascii?q?9a23=3ABvBmjx3FWRlTJBvcsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQE1L6KOLtaQQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAQAnLERe/49dJa1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF7gSUvJAUnBWxYIAQLKgqECoNGA4sCgl+JYo4?= =?us-ascii?q?vgUKBEANQBAkBAQEMAQEYAQoKAgQBAYN7RQIXgjIkOBMCAw0BAQUBAQECAQU?= =?us-ascii?q?EbYU3DIVmAQEBAQIBAQEQCAEIChMBASkDBgUBBAsCAQgOAwQBAQEgAQIEAwI?= =?us-ascii?q?CAh8GCxQJCAIEAQkEBQgagwWBfU0DDiABAgygcAKBOYhidYEygn8BAQWBQwE?= =?us-ascii?q?/AYMNDQuCDAMGgTiMJBqBQT+BEUeCTD6CG0kBAQIBAYEjCQESASMrCYJaMoI?= =?us-ascii?q?sjUISDgQHgjM7hWaYQzJECoI6h02KVASESIJIiBKQO45oiG6CKZAWAgQCBAU?= =?us-ascii?q?CDgEBBYFpIjcwcXAVO4JsUBgNjh0MFxVvAQMEgkSFFIU/dAIBgSaOBoEiAYE?= =?us-ascii?q?PAQE?= X-IronPort-AV: E=Sophos;i="5.70,433,1574121600"; d="scan'208,217";a="714455504" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Feb 2020 16:48:19 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 01CGmA7U007926 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Feb 2020 16:48:18 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 12 Feb 2020 10:48:17 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 12 Feb 2020 10:48:16 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 12 Feb 2020 10:48:16 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QWsmHturnH5ZZqj0afUYT25f9Sa6nIe8J4lX77u9xlr/1x91ShgMHIiYtraoRCkKH4l6MCKu9mnUZZCZZBa96gk8V8uCTH+PsGEZxJEH0EK3xJmkw1JdZXvxLdg4SQO5SdLlVGJ1zkowk8ZW0CybJGb3RaqcKc4mrGii1IJWOtpJojN5PHQEg5LEFthmqipUkdrKb/+BuE9ViXkM6453bSLYVJoFTnkY8G1UdWLZb/0u96youqn4a+RO8PPlHUEFrZ5LfWCFIE43IR/4oK00Rn3PWjEDBCd6r5/UoH3J2NcHVTcqSXPa+KhT0zw7JKla9qQcdRQdhNGynWj+BPyKzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NZ2wIxlxzCxb2Iere2y7YP8GWB1O+IsTYOxwbusSFsQ=; b=OtLN59H7GeSlW64XttpViofB86aO9WYAZQ54XIREPgAasjbSg7tuD5uannNI3TlT11U53it/NlP6KICY+rIuPl3/6xneJs49YeSddXXjA1k4z5z7zhQddzHbPf3l3EMEAmm+nth28oK2w+6aKRngZp7txBXqxMMHOM/jceV8ItHiE/EQhPx1f78OXqlKV8QWQh48nNH+w+Y7RiQuoFVLgH34jIPOBgY2YVsd29I3GY7ksZYCluOj1D6TVgxysFkWNUryKjV0gHwNRTa+I0xpv0uhSlpSsyB70o+zhwAX5KJ1dEDa2gTMwR7Pw1eMz0vHf748hlcmclEgBgQJVA5NRQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NZ2wIxlxzCxb2Iere2y7YP8GWB1O+IsTYOxwbusSFsQ=; b=OhWpY3bv+BHFgO8CxVDFUAb9X+/dSiEjLZKsK2XhwkTNLCOskvRSnxMiWuwr/MH8vVZXRhJF6506KbN65XioXVKE06VZdGRpya/Aivaoh0y+okJ3DEbcjE6ql5R7XbVBO6kS/cNPl6P6ygFU2jmGbMzau9NCcoaFxwcrzK6LkDQ= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (52.135.38.209) by MN2PR11MB3566.namprd11.prod.outlook.com (20.178.251.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 12 Feb 2020 16:48:14 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::b9ce:1058:5fa6:44a1%7]) with mapi id 15.20.2707.030; Wed, 12 Feb 2020 16:48:14 +0000 From: "Rob Wilton (rwilton)" To: Eric Rescorla , Mirja Kuehlewind CC: Magnus Westerlund , "webtrans-chairs@ietf.org" , WebTransport , The IESG , David Schinazi , Victor Vasiliev , Barry Leiba Thread-Topic: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT) Thread-Index: AQHV20T7tRKUiEKZEE6Xr21xW1qSLagOMSYAgAfIj4CAAIh4gIAADGCAgAABAQCAAN3eAIAAOZYAgAADMICAAAP5AIAACTeAgAABFgCAAAEfgIAABD6g Date: Wed, 12 Feb 2020 16:48:14 +0000 Message-ID: References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> <84F34F5C-DFD6-42F6-9B12-BD10F2B37DB5@kuehlewind.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com; x-originating-ip: [173.38.220.51] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4e954330-0a11-4aa6-d9ff-08d7afdb5a87 x-ms-traffictypediagnostic: MN2PR11MB3566: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0311124FA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(376002)(346002)(39860400002)(366004)(136003)(199004)(189003)(53546011)(8936002)(966005)(6506007)(81166006)(8676002)(2906002)(26005)(7696005)(81156014)(30864003)(186003)(55016002)(9686003)(5660300002)(110136005)(4326008)(33656002)(64756008)(66946007)(76116006)(66446008)(316002)(66556008)(66476007)(86362001)(71200400001)(478600001)(66574012)(52536014)(54906003)(219054002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3566; H:MN2PR11MB4366.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G2lnvJNo0FN87FcIsk2wUNlH/loDA2br3+dccJUXhpd2vk43X58alsszBOmZG9oCJLOD6wusvS3D1mU91hJW0QQudMGTeJ9kqUZ6G5UyMeBXDCSdxyZeMYP0759bdtSuOAtpzuHUWOmda93J/W71GTPQaQ3F8MDycDbPmSguxdT/+tLnIyJs01NVQi9PbG0uVXvqZkSXtfX3ZS8wus9rQgY3q01gpihhAPdKe+8xLp6xZ07CicMvpYhNloJNAC9te6LFA+wWZSDDNylZKFn5w69T4sLyrU8Y9NBC3x/7GKlUs6Jv1FX1mEsIvjZho47M2rVrwKo2M0Arq3GCN3ShZZBH3zVRhK5oTVZz42wD8dx9187U3dGlDCi0O9QZVIIHrOC2KHzoknLAFJvWJ6+Y5FV1jxIHFWXCP+5O7lw7vwXVtUPcfBsGqx8jl+Q1Deb2dnaX8DsTd/7V72QfPEmc3XKR2H4xIuPb6rFqiuejgSr5t/MBf0GhYtf+xqmO5wjTd9VbzGLgEsHeHTR2oNx8IwZ0JiPXInOssJHFER7EajQacbGwP8sJJActPnxSE91V x-ms-exchange-antispam-messagedata: 6HJFUrXAuBHysePpWKdh3gyiYpzhBhuN+LK2ITUfhur7RZarZxn5w7Bs4+y9+zrQjjSKDLnmAaCkz/uuEVOHBcY0lldk/fBUJfkPnmbK2NbJj9DHNfcaI9tXQ7zjhQYKvmB5ew/hChV3sNJcfRg+rw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366262FAE88B8CFF63A47CDB51B0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4e954330-0a11-4aa6-d9ff-08d7afdb5a87 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2020 16:48:14.5567 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KtAhGAcBz2FT03l9cPeGPyqdVAiNyLpYx2XhgfasiI1Jxf9QopSRnscOujhwCfx301nZfD/XNQI7HcoIOdcYvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3566 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 16:48:51 -0000 --_000_MN2PR11MB4366262FAE88B8CFF63A47CDB51B0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IHN1cmUgaG93IGxpa2VseSBRVUlDIGV4dGVuc2lvbnMgYXJlIGZvciBXZWJUcmFu c3BvcnQsIGJ1dCB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBkZWZlciB0aGUgZGVjaXNpb24gb2Yg ZXhhY3RseSB3aGVyZSBleHRlbnNpb25zIHdvcmsgaXMgZG9uZSwgaWYgcmVxdWlyZWQ/DQoNCkku ZS4sIHJhdGhlciB0aGFuOg0KDQpUaGUgV2ViVHJhbnNwb3J0IHdvcmtpbmcgZ3JvdXAgbWF5IGRl ZmluZSBleHRlbnNpb25zIHRvIHRoZXNlIHByb3RvY29scywNCmJ1dCBhbnkgd29ya2luZyBncm91 cCBsYXN0IGNhbGwgZGVmaW5pbmcgc3VjaCBleHRlbnNpb25zIHdpbGwgYWxzbyBiZSBzZW50DQp0 byB0aGUgbWFpbGluZyBsaXN0IG9mIHRoZSByZWxldmFudCB3b3JraW5nIGdyb3VwLg0KDQpwZXJo YXBzOg0KDQpUaGUgV2ViVHJhbnNwb3J0IHdvcmtpbmcgZ3JvdXAgbWF5IGNvbnNpZGVyIGV4dGVu c2lvbnMgdG8gdGhlc2UgcHJvdG9jb2xzLCBidXQgaWYgcmVxdWlyZWQsIHRoZSByZWxldmFudCB3 b3JraW5nIGdyb3VwcyBzaGFsbCBiZSBjb25zdWx0ZWQgdG8gYWdyZWUgdGhlIG1vc3QgYXBwcm9w cmlhdGUgd29ya2luZyBncm91cCB0byBwcm9ncmVzcyB0aGUgd29yaywgYW5kIGFsbCByZWxldmFu dCB3b3JraW5nIGdyb3VwcyBtdXN0IGJlIGludm9sdmVkIGluIFdHTEMgcmVxdWVzdHMuDQoNClJl Z2FyZHMsDQpSb2INCg0KDQpGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv Omllc2ctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50 OiAxMiBGZWJydWFyeSAyMDIwIDE1OjIxDQpUbzogTWlyamEgS3VlaGxld2luZCA8aWV0ZkBrdWVo bGV3aW5kLm5ldDxtYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5ldD4+DQpDYzogTWFnbnVzIFdlc3Rl cmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbTxtYWlsdG86bWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tPj47IHdlYnRyYW5zLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86d2Vi dHJhbnMtY2hhaXJzQGlldGYub3JnPjsgV2ViVHJhbnNwb3J0IDx3ZWJ0cmFuc3BvcnRAaWV0Zi5v cmc8bWFpbHRvOndlYnRyYW5zcG9ydEBpZXRmLm9yZz4+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y ZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4+OyBEYXZpZCBTY2hpbmF6aSA8ZHNjaGluYXppLmlldGZA Z21haWwuY29tPG1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFpbC5jb20+PjsgVmljdG9yIFZhc2ls aWV2IDx2YXNpbHZ2QGdvb2dsZS5jb208bWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNvbT4+OyBCYXJy eSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc8bWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0 ZXIub3JnPj4NClN1YmplY3Q6IFJlOiBbV2VidHJhbnNwb3J0XSBNYWdudXMgV2VzdGVybHVuZCdz IEJsb2NrIG9uIGNoYXJ0ZXItaWV0Zi13ZWJ0cmFucy0wMC0wMDogKHdpdGggQkxPQ0sgYW5kIENP TU1FTlQpDQoNCldlbGwsIEkgZG9uJ3QgcmVhbGx5IGFncmVlIHRoYXQgdGhpcyBuZWVkcyB0byBi ZSBhIGxpdmUgaXNzdWUsIGJ1dCBhcyB5b3UgaW5zaXN0Og0KRXh0ZW5zaW9ucyB0byBRVUlDIHNo b3VsZCBiZSBwb3NzaWJsZSBpbiBXR3MgYWNyb3NzIHRoZSBJRVRGLCB3aXRoIHByb3BlciBjb29y ZGluYXRpb24gd2l0aCB0aGUgUVVJQyBXRy4gVGhpcyBpc24ndCByZWFsbHkgYSBkZWNpc2lvbiBm b3IgdGhlIFFVSUMgV0csIGJ1dCByYXRoZXIgZm9yIHRoZSBJRVNHLCBJbiBhbnkgY2FzZSwgdGhp cyBpcyBwcmVjaXNlbHkgd2hhdCBpcyBjb250ZW1wbGF0ZWQgYnkgdGhlIGN1cnJlbnQgZHJhZnQu IElmIHlvdSB0aGluayB0aGlzIG5lZWRzIHRvIGdvIGluIHNvbWUgY2hhcnRlciB0ZXh0LCB0aGVu IGl0IHNob3VsZCBnbyB0aGVyZSBub3cuDQoNCi1Fa3INCg0KDQpPbiBXZWQsIEZlYiAxMiwgMjAy MCBhdCA3OjE3IEFNIE1pcmphIEt1ZWhsZXdpbmQgPGlldGZAa3VlaGxld2luZC5uZXQ8bWFpbHRv OmlldGZAa3VlaGxld2luZC5uZXQ+PiB3cm90ZToNCg0KDQo+IE9uIDEyLiBGZWIgMjAyMCwgYXQg MTY6MTMsIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4g d3JvdGU6DQo+DQo+DQo+DQo+IE9uIFdlZCwgRmViIDEyLCAyMDIwIGF0IDY6NDAgQU0gTWlyamEg S3VlaGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldDxtYWlsdG86aWV0ZkBrdWVobGV3aW5kLm5l dD4+IHdyb3RlOg0KPiBUaGUgd2hvbGUgcG9pbnQgaXMgdGhhdCB0aGUgUVVJQyBwcm90b2NvbCBp cyBub3QgZmluaXNoZWQgeWV0IGFuZCB0aGUgcmVzcGVjdGl2ZSByZWdpc3RyeSBkb2VzbuKAmXQg ZXhpc3RzIHlldC4NCj4NCj4gQW5kIFdlYlRyYW5zcG9ydCB3aWxsIGhhdmUgYSBub3JtYXRpdmUg ZGVwZW5kZW5jeSBvbiBRVUlDIGFuZCB0aGVyZWZvcmUgd2lsbCBub3QgYmUgZmluaXNoZWQgcHJp b3IgdG8gdGhhdCByZWdpc3RyeSBleGlzdGluZy4NCg0KQnV0IHRoZSBjaGFydGVyIHdpbGwgYmUg ZmluaXNoZWQgYmVmb3JlIHRoYXQgYW5kIHdlIG5lZWQgdG8gZGVjaWRlIG5vdyB3aGF0IHRvIHdy aXRlIGluIHRoZXJlLiBUaGF04oCZcyB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nLg0KDQo+DQo+DQo+ IEFsbCBJ4oCZbSBzYXlpbmcgdGhhdCB3ZSBzaG91bGQgbm90IGJha2UgcHJvY2VzcyBpbiB0aGUg dGhlIHdlYnRyYW5zcG9ydCBjaGFydGVyIHRoYXQgbWlnaHQgcmVzdHJpY3QgYSBmdXR1cmUgZGlz Y3VzcyB3ZSB3YW50IHRvIGhhdmUgaW4gdGhlIFFVSUMgZ3JvdXAuDQo+DQo+IFdoYXQgZnV0dXJl IGRpc2N1c3Npb24/IEFzIEkgc2FpZCwgdGhlIElBTkEgY29uc2lkZXJhdGlvbnMgaW1wbGljaXQg ZGVjaWRlIHRoaXMgbWF0dGVyLiBJcyBzb21lb25lIGFyZ3VpbmcgdG8gY2hhbmdlIHRob3NlIHRv IFN0YW5kYXJkcyBUcmFjaz8NCg0KQXMgTWFnbnVzIHdyb3RlIHNldmVyYWwgdGltZXMgaW4gdGhl IHJlc2VudGVkIHJlLWNoYXJ0ZXJpbmcgZGlzY3Vzc2lvbjoNCg0KIkEgcmVhc29uIGZvciB0aGUg dHdvIHN0ZXAgcmVjaGFydGVyaW5nIGlzIHRoYXQgSSB0aGluayB3ZSB3aWxsIG5lZWQgdG8gaGF2 ZSBhDQpzZXJpb3VzIGRpc2N1c3Npb24gb2YgaG93IHRvIHdvcmsgb24gdjIgYW5kIGV4dGVuc2lv bnMgbW9yZSBnZW5lcmFsbHkuIEkgdGhpbmsNCmdvaW5nIGludG8gdGhlc2UgZGV0YWlscyBub3cg aXMgcHJlbWF0dXJlLiBCdXQgd2Ugd2lsbCBuZWVkIHRvIGNvbWUgYmFjayB0byB0aGlzDQpsYXRl ci7igJ0NCg0KTWlyamENCg0KDQoNCj4NCj4gLUVrcg0KPg0KPg0KPg0KPiA+IE9uIDEyLiBGZWIg MjAyMCwgYXQgMTU6MjYsIEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZzxtYWls dG86YmFycnlsZWliYUBjb21wdXRlci5vcmc+PiB3cm90ZToNCj4gPg0KPiA+IEkgaGF2ZSB0byBh Z3JlZSB3aXRoIEVLUiBoZXJlOiBJJ20gbm90IGF3YXJlIG9mIGFueSBvdGhlciBwcm90b2NvbHMN Cj4gPiB0aGF0IGRlZmluZSBTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIGV4dGVuc2lvbiBtZWNoYW5p c21zIHdoZXJlIHdlIHNheQ0KPiA+IHRoYXQgdGhlIG9yaWdpbmFsIHdvcmtpbmcgZ3JvdXAgc2hv dWxkIGJlIGluIGNvbnRyb2wgb2YgdGhlDQo+ID4gZXh0ZW5zaW9ucy4gIEkgd291bGRuJ3Qgd2Fu dCB0byBzdGFydCBpdCBoZXJlLg0KPiA+DQo+ID4gVGhlIEFEcyB3aWxsIGRlc2lnbmF0ZSBleHBl cnRzIHRvIHJldmlldyB0aGUgZXh0ZW5zaW9uIHNwZWNpZmljYXRpb25zLA0KPiA+IGFuZCB0aGF0 IGlzIHRoZSBtZWNoYW5pc20gZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGhhdmUgaXRzIHNheSBp biB0aGUNCj4gPiBleHRlbnNpb25zLiAgQW5kIGluIHRoaXMgY2FzZSwgdGhlIGNoYXJ0ZXIgZXhw bGljaXRseSBzYXlzIHRoYXQNCj4gPiB3ZWJ0cmFucyB3aWxsIGNvb3JkaW5hdGUgd2l0aCBxdWlj LiAgSSBzZWUgbm8gcmVhc29uIHRvIGJlIG1vcmUNCj4gPiBzcGVjaWZpYyBoZXJlLCBub3IgdG8g cmVxdWlyZSBtb3JlLg0KPiA+DQo+ID4gQmFycnkNCj4gPg0KPiA+IE9uIFdlZCwgRmViIDEyLCAy MDIwIGF0IDk6MTUgQU0gRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRm bS5jb20+PiB3cm90ZToNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gV2VkLCBGZWIgMTIsIDIw MjAgYXQgMjo0OSBBTSBNaXJqYSBLdWVobGV3aW5kIDxpZXRmQGt1ZWhsZXdpbmQubmV0PG1haWx0 bzppZXRmQGt1ZWhsZXdpbmQubmV0Pj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGkgRWtyLA0KPiA+ Pj4NCj4gPj4+IFllcywgaXQgaXMgc3BlY2lmaWNhdGlvbiByZXF1aXJlZCwgaG93ZXZlciwgaWYg d2UgZGVjaWRlIHRvIHB1c2hpbmcgYW4gUkZDIHRoZW4gd2UgbmVlZCB0byBkZWNpZGUgd2hlcmUg dGhpcyB3b3JrIGluIHRoZSBJRVRGIGNhbiBiZSBkb24gYmVzdC4NCj4gPj4NCj4gPj4NCj4gPj4g VGhpcyBzZWVtcyBsaWtlIGEgdmVyeSBvZGQgcG9zaXRpb24uIEFzIHNvb24gYXMgdGhlIFFVSUMg UkZDIGlzIHB1Ymxpc2hlZCwgYW55b25lIGVsc2UgaW4gdGhlIHdvcmxkIGNhbiBhc3NpZ24gbmV3 IFFVSUMgY29kZSBwb2ludHMsIGJ1dCBpbnNpZGUgdGhlIElFVEYsIHVudGlsIHRoZXJlO3Mgc29t ZSBkaXNjdXNzaW9uIGluIHRoZSBRVUlDIHRoZXJlIHdvbid0IGJlIGFueSBwcm9jZXNzIG90aGVy IHRoYW4gYXNraW5nIHRoZSBRVUlDIFdHPw0KPiA+Pg0KPiA+Pg0KPiA+Pj4NCj4gPj4+IEFsbCBJ 4oCZbSBzYXlpbmcgdGhhdCB0aGUgcHJvY2VzcyBob3cgYW5kIHdoZXJlIHRvIGRlZmluZSBRVUlD IGV4dGVuc2lvbnMgaW4gdGhlIElFVEYgbmVlZHMgdG8gYmUgZGVjaWRlZCBieSB0aGUgUVVJQyBn cm91cCBhbmQgYSBmdXR1cmUgUVVJQyBjaGFydGVyIGFuZCBub3QgYnkgdGhlIGNoYXJ0ZXIgb2Yg YW55IG90aGVyIHdvcmtpbmcgZ3JvdXAuDQo+ID4+DQo+ID4+DQo+ID4+IEkgZG9uJ3QgdW5kZXJz dGFuZCB3aGF0IHByb2Nlc3MgeW91IHRoaW5rIHJlcXVpcmVzIHRoaXMuIFRoZXJlIHdhcyBuZXZl ciBhbnkgc3VjaCBmb3JtYWwgZGlzY3Vzc2lvbiBpbiB0aGUgVExTIFdHIEFGQUlLLiBJbiBteSBl eHBlcmllbmNlIHdoZW4gc29tZSBXRyB3YW50cyB0byBkZWZpbmUgYSBUTFMgZXh0ZW5zaW9uIHRo ZXJlJ3MgYSBicmllZiBkaXNjdXNzaW9uIGJldHdlZW4gdGhlIGNoYWlycyBhbmQgQURzIGFib3V0 IHdoZXRoZXIgaXQncyBvcnRob2dvbmFsIGVub3VnaCB0byBkbyBzZXBhcmF0ZWx5LiBJdCdzIG5v dCBpbiB0aGUgVExTIGNoYXJ0ZXIsIGZvciBpbnN0YW5jZSwgQUZBSUNULg0KPiA+Pg0KPiA+PiAt RWtyDQo+ID4+DQo+ID4+PiBBZ2FpbiB0aGF0IGRvZXNu4oCZdCBtZWFuIHRoYXQgaW4gZnV0dXJl IGl0IHdpbGwgbm90IGJlIHBvc3NpYmxlIGZvciBvdGhlciBncm91cHMgdG8gZGVmaW5lIGV4dGVu c2lvbiBidXQgd2UgbmVlZCB0byBoYXZlIHRoYXQgZGlzY3Vzc2lvbiBmaXJzdC4NCj4gPj4+DQo+ ID4+PiBNaXJqYQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IE9uIDExLiBGZWIgMjAyMCwg YXQgMjI6MzQsIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29t Pj4gd3JvdGU6DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gT24gVHVlLCBGZWIgMTEs IDIwMjAgYXQgMTozMSBQTSAiTWlyamEgS8O8aGxld2luZCAoSUVURikiIDxpZXRmQGt1ZWhsZXdp bmQubmV0PG1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Pj4gd3JvdGU6DQo+ID4+Pj4gSGkgRGF2 aWQsDQo+ID4+Pj4NCj4gPj4+PiBJIGRpZG7igJl0IHNheSB0aGF0IG90aGVyIGdyb3VwcyBjYW5u b3QgZGVmaW5lIGV4dGVuc2lvbi4gSSBkaWQgc2F5IHRoYXQgaXTigJlzIHRoZSBkZWNpc2lvbiBv ZiB0aGUgd29ya2luZyBncm91cCB0aGF0IG1haW50YWlucyB0aGUgcHJvdG9jb2wgaG93IHRvIGhh bmRsZSB0aGF0IGFuZCBmb3IgUXVpYyB3ZSBkaWRu4oCZdCBoYXZlIGhhZCB0aGF0IGRpc2N1c3Np b24geWV0Lg0KPiA+Pj4+DQo+ID4+Pj4gRXhhbXBsZXMgZm9yIGdyb3VwcyB0aGF0IGV4cGxpY2l0 bHkgZGVmaW5lIHByb2Nlc3MgZm9yIGV4dGVuZGluZyB0aGUgcHJvdG9jb2wgaW4gdGhlaXIgY2hh cnRlciBhcmUgZGhjIGFuZCA2bWFuLiBBcyB5b3UgY2FuIHNlZSBkaWZmZXJlbnQgZ3JvdXBzL3By b3RvY29scyBoYXZlIGRpZmZlcmVudCBwcm9jZXNzIGFuZCBhcyB3ZSBkaWRu4oCZdCBkZWZpbmUg YW55dGhpbmcgeWV0IGZvciBRdWljLCB0aGUgd29ya2luZyBhc3N1bXB0aW9uIGZvciBub3cgc2hv dWxkIGJlIHRoYXQgYWxsIGV4dGVuc2lvbiB3b3JrIHdpbGwgYmUgZmluZSBpbiB0aGUgUXVpYyBn cm91cC4NCj4gPj4+Pg0KPiA+Pj4+IFdlbGwsIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIGZvciBR VUlDIHRyYW5zcG9ydCBzZWVtIGZhaXJseSBjbGVhcjoNCj4gPj4+Pg0KPiA+Pj4+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTI1I3NlY3Rpb24t MjIuMS40DQo+ID4+Pj4NCj4gPj4+PiBNb3N0IG9mIHRoZSBjb2RlIHBvaW50cyBhcmUgYXNzaWdu ZWQgdmlhIFNwZWNpZmljYXRpb24gUmVxdWlyZWQsIHNvIEkgZG9uJ3Qgc2VlIHdoeSB5b3Ugd291 bGQgaW5mZXIgdGhhdCBhbGwgZXh0ZW5zaW9ucyBoYXBwZW4gd2l0aGluIHRoZSBRVUlDIFdHLi4N Cj4gPj4+Pg0KPiA+Pj4+IC1Fa3INCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+ Pj4+DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IE1pcmphDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ PiBBbSAxMS4wMi4yMDIwIHVtIDIxOjQ3IHNjaHJpZWIgRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6 aS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tPj46DQo+ID4+ Pj4+DQo+ID4+Pj4+IO+7vw0KPiA+Pj4+PiBIaSBNaXJqYSwNCj4gPj4+Pj4NCj4gPj4+Pj4gSSdt IG5vdCBzdXJlIEkgYWdyZWUgd2l0aCB5b3VyIGludGVycHJldGF0aW9uLi4gVGhlIGZhY3QgdGhh dCBhIFdHIGlzDQo+ID4+Pj4+IHJlc3BvbnNpYmxlIGZvciBhIHByb3RvY29sIGRvZXMgbm90IG1l YW4gdGhhdCBvdGhlciB3b3JraW5nIGdyb3Vwcw0KPiA+Pj4+PiBjYW5ub3Qgd3JpdGUgZXh0ZW5z aW9ucyB0byB0aGF0IHByb3RvY29sLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBGb3IgZXhhbXBsZSwgdGhl IFFVSUMgV0cgaXMgZGVmaW5pbmcgdGhlIHF1aWNfdHJhbnNwb3J0X3BhcmFtZXRlcnMNCj4gPj4+ Pj4gVExTIGV4dGVuc2lvbi4gVGhhdCBleHRlbnNpb24gaXMgbm90IGRlZmluZWQgaW4gdGhlIFRM UyBXRy4NCj4gPj4+Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcXVp Yy10bHMtMjUjc2VjdGlvbi04LjINCj4gPj4+Pj4NCj4gPj4+Pj4gU2ltaWxhcmx5LCB0aGUgQUNN RSBXRyBpcyBkZWZpbmluZyB0aGUgQ2VydC1Ob3QtQmVmb3JlIEhUVFANCj4gPj4+Pj4gaGVhZGVy LCBub3QgdGhlIEhUVFAgV0cuDQo+ID4+Pj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWFjbWUtc3Rhci0xMSNzZWN0aW9uLTYuNw0KPiA+Pj4+Pg0KPiA+Pj4+PiBBZGRp dGlvbmFsbHksIE1QVENQIGlzIGFuIGV4dGVuc2lvbiB0byBUQ1AgdGhhdCB3YXMgbm90DQo+ID4+ Pj4+IGRlZmluZWQgaW4gdGhlIFRDUE0gV0cuIFRoZSBsaXN0IGdvZXMgb24uDQo+ID4+Pj4+DQo+ ID4+Pj4+IFdlIGRvbid0IHlldCBoYXZlIGV4YW1wbGVzIGZvciBRVUlDIGFzIHRoZSBRVUlDIElB TkENCj4gPj4+Pj4gcmVnaXN0cmllcyBoYXZlbid0IGJlZW4gY3JlYXRlZCB5ZXQsIGJ1dCBJIGRv bid0IHNlZSB3aHkgUVVJQw0KPiA+Pj4+PiB3b3VsZCBiZSBkaWZmZXJlbnQgZnJvbSBUTFMsIEhU VFAsIG9yIFRDUC4NCj4gPj4+Pj4NCj4gPj4+Pj4gRGF2aWQNCj4gPj4+Pj4NCj4gPj4+Pj4NCj4g Pj4+Pj4gT24gVHVlLCBGZWIgMTEsIDIwMjAgYXQgNDozOCBBTSBNaXJqYSBLdWVobGV3aW5kIDxp ZXRmQGt1ZWhsZXdpbmQubmV0PG1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0Pj4gd3JvdGU6DQo+ ID4+Pj4+IEhpIERhdmlkLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbmUgbW9yZSBjb21tZW50IGJlbG93 Lg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gT24gNi4gRmViIDIwMjAsIGF0IDE0OjQ2LCBEYXZpZCBTY2hp bmF6aSA8ZHNjaGluYXppLmlldGZAZ21haWwuY29tPG1haWx0bzpkc2NoaW5hemkuaWV0ZkBnbWFp bC5jb20+PiB3cm90ZToNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBIaSBNYWdudXMsDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gSSByZWFsaXplZCB0aGF0IHNvbWUgb2Ygb3VyIGVhcmxpZXIgcmVwbGllcyB3ZXJl IGFjY2lkZW50YWxseSBub3Qgc2VudCB0bw0KPiA+Pj4+Pj4gdGhlIElFU0cgbGlzdCwgZm9yIHdo aWNoIEkgYXBvbG9naXplLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRvIHN1bW1hcml6ZSB0aGF0IGRp c2N1c3Npb246DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gLSBJdCBpcyBub3Qgb3VyIGludGVudGlvbiB0 byBidWlsZCBhIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2wgaGVyZS4NCj4gPj4+Pj4+IFRoZSBXRUJU UkFOUyBXRyB3b3VsZCBidWlsZCBhcHBsaWNhdGlvbiBwcm90b2NvbHMgdGhhdA0KPiA+Pj4+Pj4g cnVuIG92ZXIgUVVJQywgb3IgVExTL1RDUC4gVGhpcyB3b3VsZCBlbnN1cmUgd2UgYmVuZWZpdA0K PiA+Pj4+Pj4gZnJvbSB0aGVpciBzZWN1cml0eSBhbmQgY29uZ2VzdGlvbiBjb250cm9sIHByb3Bl cnRpZXMuDQo+ID4+Pj4+PiBIZXJlIGlzIGEgUFIgdG8gdGhlIGNoYXJ0ZXIgdGhhdCBzaG91bGQg Y2xhcmlmeSB0aGlzOg0KPiA+Pj4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL0RhdmlkU2NoaW5hemkv d2VidHJhbnMtd2ctbWF0ZXJpYWxzL3B1bGwvNi9maWxlcw0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IC0g VGhlIFdFQlRSQU5TIFdHIHdvdWxkIG5vdCBtb2RpZnkgUVVJQyBvciBIVFRQLg0KPiA+Pj4+Pj4g QW55IGRpc2N1c3Npb24gb2YgbW9kaWZ5aW5nIHRob3NlIGNvcmUgcHJvdG9jb2xzIHdvdWxkDQo+ ID4+Pj4+PiBoYXBwZW4gaW4gdGhlaXIgZXhpc3RpbmcgcmVzcGVjdGl2ZSB3b3JraW5nIGdyb3Vw cy4uDQo+ID4+Pj4+PiBIb3dldmVyLCBkaXNjdXNzaW9uIG9mIGV4dGVuc2lvbnMgdG8gdGhlc2Ug cHJvdG9jb2xzIGNvdWxkDQo+ID4+Pj4+PiBiZSBhbGxvd2VkIGluIHRoaXMgV0csIGFzIGxvbmcg YXMgYW55IGRvY3VtZW50IFdHTEMgaXMNCj4gPj4+Pj4+IGFsc28gc2VudCB0byB0aGUgbWFpbGlu ZyBsaXN0IHJlc3BvbnNpYmxlIGZvciB0aGF0IHByb3RvY29sLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJ IHRoaW5rIHRoaXMgaXMgbm90IHN1ZmZpY2llbnQsIGF0IGxlYXN0IG5vdCBmb3IgUVVJQy4gTW9y ZSBkaXNjdXNzaW9uIGlzIG5lZWRlZCBpbiB0aGUgUVVJQyBncm91cCBvbiB0aGlzIGJ1dCBjdXJy ZW50bHkgSSB0aGluayB0aGUgYXNzdW1wdGlvbiBzaG91bGQgYmUgdGhhdCBhbGwgZXh0ZW5zaW9u cyB3aWxsIGJlIGRvbmUgd2l0aGluIHRoZSBRVUlDIGdyb3VwLiBTbyBqdXN0IHNlbmRpbmcgYSBX R0xDIHRoZXJlIGlzIG5vdCBzdWZmaWNpZW50Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBNb3JlIGdlbmVy YWxseSBkZWNpZGluZyBvbiBwcm9jZXNzZXMgZm9yIG90aGVyIHByb3RvY29scy9ncm91cHMgaW4g dGhpcyBjaGFydGVyIGlzIG5vdCBhcHByb3ByaWF0ZS4gSeKAmW0gbm90IHN1cmUgd2hhdCB0aGUg ZGVmaW5lZCBwcm9jZXNzIGlzIGZvciBIVFRQIGFuZCBUTFMgYnV0IHRoYXQgc2hvdWxkIGJlIHNw ZWNpZmllZCBpbiB0aGVpciBjaGFydGVyIGFuZCBub3QgaGVyZS4NCj4gPj4+Pj4NCj4gPj4+Pj4g Rm9yIFFVSUMsIEkgd291bGQgbGlrZSB0byByYXRoZXIgc2VlIHRoYXQgZXh0ZW5zaW9uIG9yIG1v ZGlmaWNhdGlvbiBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlzIGdyb3VwLiBPZiBjb3Vyc2UgdGhh dCBkb2VzbuKAmXQgbWVhbiB0aGF0IHRoaXMgZ3JvdXAgY2Fubm90IHRhbGsgYWJvdXQgYW55IGV4 dGVuc2lvbiBidXQgYXMgc29vbiBhcyB0aGUgZ3JvdXAgdGhpbmtzIGFuIGV4dGVuc2lvbiBpcyBu ZWVkZWQsIGl0IG5lZWRzIHRvIGdvIHRvIHRoZSBRVUlDIGdyb3VwIGFuZCBjYW5ub3QganVzdCBh ZGFwdCBhbnl0aGluZyB3aXRoaW4gV2ViVHJhbnNwb3J0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBQbGVh c2UgYWxzbyBkb3VibGUtY2hlY2sgd2hhdCB0aGUgcmlnaHQgcHJvY2VzcyBpcyBmb3IgVExTIGFu ZCBIVFRQLiBJIGFzc3VtZSBmb3IgVExTIGl0J3MgdGhlIHNhbWUgYnV0IGZvciBIVFRQIGl0IG1p Z2h0IGJlIGRpZmZlcmVudOKApj8NCj4gPj4+Pj4NCj4gPj4+Pj4gTWlyamENCj4gPj4+Pj4NCj4g Pj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBXb3VsZCB0aGF0IGJlIGFuIGFjY2Vw dGFibGUgc2NvcGU/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmtzLA0KPiA+Pj4+Pj4gRGF2aWQN Cj4gPj4+Pj4+DQo+ID4+Pj4+PiBPbiBUdWUsIEZlYiA0LCAyMDIwIGF0IDExOjA3IEFNIFZpY3Rv ciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPG1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20+ PiB3cm90ZToNCj4gPj4+Pj4+IEkgYmVsaWV2ZSBtb3N0IG9mIHRob3NlIGhhdmUgYmVlbiBhZGRy ZXNzZWQgaW4gRGF2aWQncyBQUiwgc28gSSdsbCB0cnkgdG8gcmVwbHkNCj4gPj4+Pj4+IHByaW1h cmlseSB0byB0aG9zZSB0aGF0IEkgaGF2ZSBzb21ldGhpbmcgdG8gYWRkIHRvLi4NCj4gPj4+Pj4+ DQo+ID4+Pj4+PiBPbiBGcmksIEphbiAzMSwgMjAyMCBhdCA1OjM5IFBNIE1hZ251cyBXZXN0ZXJs dW5kIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0 Zi4ub3JnPj4gd3JvdGU6DQo+ID4+Pj4+PiBNYWdudXMgV2VzdGVybHVuZCBoYXMgZW50ZXJlZCB0 aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj4gPj4+Pj4+IGNoYXJ0ZXItaWV0Zi13 ZWJ0cmFucy0wMC0wMDogQmxvY2sNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBXaGVuIHJlc3BvbmRpbmcs IHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj4g Pj4+Pj4+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAo RmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+ID4+Pj4+PiBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBo b3dldmVyLikNCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZSBkb2N1 bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVy ZToNCj4gPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0 Zi13ZWJ0cmFucy8NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4+Pj4+IEJMT0NLOg0KPiA+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBbc25pcF0NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBUaGUgZ3Jv dXAgd2lsbCBhbHNvIGNvb3JkaW5hdGUgd2l0aCByZWxhdGVkIHdvcmtpbmcgZ3JvdXBzIHdpdGhp biB0aGUgSUVURiwNCj4gPj4+Pj4+IHN1Y2ggYXMgUVVJQyBhbmQgSFRUUEJJUywgYXMgYXBwcm9w cmlhdGUuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gV2l0aCB0aGUgY3VycmVudCBzdGF0ZSBvZiBRVUlD IGRldmVsb3BlbWVudCBhbmQgSFRUUC8zIG1hcHBpbmcgZGVmaW5pdGlvbiwgaS5lLg0KPiA+Pj4+ Pj4gc3RpbGwgd29ya2luZyBvbiB0aGUgaW5pdGlhbCB2ZXJzaW9uLCBJIHdvdWxkIGxpa2UgdG8g aGF2ZSBhIG1vcmUgZmlybSB3b3JkaW5nDQo+ID4+Pj4+PiB0aGF0IHRoZSBXZWJUcmFucyBXRyB3 aWxsIGFjdHVhbGx5IGhhdmUgdG8gdGFrZSBhbnkgcmVxdWVzdHMgZm9yIGV4dGVuc2lvbnMgb2YN Cj4gPj4+Pj4+IEhUVFAvMyBhbmQgUVVJQyB0byB0aGUgcmVsZXZhbnQgV0cuDQo+ID4+Pj4+Pg0K PiA+Pj4+Pj4gV2hpbGUgdGhlcmUgYXJlIG5vIGV4dGVuc2lvbnMgdG8gUVVJQyBhbW9uZyB0aGUg cHJvcG9zZWQgV0cgZG9jdW1lbnRzLCBzb21lIG9mDQo+ID4+Pj4+PiB0aGUgZHJhZnRzIGRvIGV4 dGVuZCBIVFRQIHVzaW5nIGN1c3RvbSBTRVRUSU5HUyBwYXJhbWV0ZXJzICh3aGljaCBpcyB0aGUN Cj4gPj4+Pj4+IGludGVuZGVkIEhUVFAgZXh0ZW5zaWJpbGl0eSBtZWNoYW5pc20pLiAgSSd2ZSBo aXRoZXJ0byBhc3N1bWVkIHRoYXQgd2VidHJhbnMNCj4gPj4+Pj4+IHdvdWxkIHdvcmsgd2l0aCBI VFRQIGV4cGVydHMgaW4gaHR0cGJpcy9xdWljIHRvIGVuc3VyZSB0aGF0IHRoZSBwcm9wb3NlZA0K PiA+Pj4+Pj4gZXh0ZW5zaW9ucyBhcmUgYXJjaGl0ZWN0dXJhbGx5IHNvdW5kIGFuZCBmb2xsb3cg YmVzdCBwcmFjdGljZXMsIGJ1dCB0aGUgbWFpbg0KPiA+Pj4+Pj4gYnVsayBvZiB3b3JrIHdvdWxk IGJlIGRvbmUgaW4gdGhlIG5ldyB3b3JraW5nIGdyb3VwIGl0c2VsZi4NCj4gPj4+Pj4+DQo+ID4+ Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+PiBDT01NRU5UOg0KPiA+Pj4+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkgYWxzbyB3b3VsZCBhcHByZWNpYXRlIGlmIHNvbWVv bmUgY2FuIGNsYXJpZnkgd2hhdCBzdGFnZSBvZiBmb3JtYWxpdHkgdGhlDQo+ID4+Pj4+PiBXZWIt VHJhbnNwb3J0IEFQSSBoYXMgYmVlbiBhZG9wdGVkIGluIFczQyBhbmQgaXMgYmVpbmcgd29ya2Vk IG9uLiBUcnlpbmcgdG8NCj4gPj4+Pj4+IGZpbmQgYW55dGhpbmcgYWJvdXQgd2hpY2ggZ3JvdXAg aXQgYmVsb25ncyB0byBvbiB0aGUgVzNDIHBhZ2UgZGlkbid0IGdpdmUgbWUNCj4gPj4+Pj4+IGFu eSBpbmZvcm1hdGlvbi4gQWxsIEkgZm91bmQgaXMgdGhhdCB0aGVyZSBoYXZlIGJlZW4gYSB3b3Jr c2hvcCBvbiBnYW1lDQo+ID4+Pj4+PiBjb21tdW5pY2F0aW9uIHdoZXJlIHRoaXMgd2FzIGRpc2N1 c3NlZCBhbmQgcmFpc2VkIGluIHNvbWUgZGlzY3Vzc2lvbnMuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g SXQncyBhIFdJQ0cgZHJhZnQsIHdoaWNoIGJhc2ljYWxseSBtZWFucyBubyBmb3JtYWwgc3RhdHVz Li4gIFdlIGhhZCBhIGRpc2N1c3Npb24NCj4gPj4+Pj4+IHNlc3Npb24gYXQgVFBBQyBsYXN0IHll YXIsIGFuZCBJIGJlbGlldmUgbW9zdCBwZW9wbGUgd2hvJ2QgYmUgbm9ybWFsbHkgaW52b2x2ZWQN Cj4gPj4+Pj4+IGFyZSBhd2FyZSBvZiBpdCwgYnV0IG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZyBp cyB0aGF0IHRoZSBlZGl0b3JzIG9mIHRoZSBXM0MNCj4gPj4+Pj4+IHNwZWMgY3VycmVudGx5IGRv IG5vdCBiZWxpZXZlIHdlIGhhdmUgZW5vdWdoIHJlYWwtd29ybGQgaW1wbGVtZW50YXRpb24NCj4g Pj4+Pj4+IGV4cGVyaWVuY2Ugd2l0aCB0aGUgcHJvcG9zYWwgdG8gYWR2YW5jZSBpdCBmdXJ0aGVy IGluIHRoZSBmb3JtYWwgcHJvY2Vzcy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBIYXZpbmcgbGl2ZWQg dGhyb3VnaCB0aGUgV2ViUlRDIC8gUlRDV2ViIGludGVyYWN0aW9ucyBpdCB3b3VsZCBnb29kIHRv IGtub3cNCj4gPj4+Pj4+IG1vcmUgaG93IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBib2Rp ZXMgYXJlIGludGVuZGVkIHRvIHdvcmsuIEVzcGVjaWFsbHkgYXMNCj4gPj4+Pj4+IGNoYW5nZXMg dG8gdGhlIEFQSSBjYW4gaGF2ZSBzaWduaWZpY2FudCBpbXBhY3Qgb24gd2hhdCB3b3JrIG5lZWRz IHRvIGhhcHBlbiBpbg0KPiA+Pj4+Pj4gdGhlIElFVEYuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gSSBt b3N0bHkgYWdyZWUgd2l0aCBCZXJuYXJkIGhlcmUuICBNeSBwbGFuIHdhcyB0aGF0IHRoZSAtb3Zl cnZpZXcgZG9jIHdvdWxkDQo+ID4+Pj4+PiBsaXN0IGFsbCBvZiB0aGUgcHJvdG9jb2wgcmVxdWly ZW1lbnRzIGFuZCBBUEkgZXhwZWN0YXRpb25zLCBhY3RpbmcgYXMNCj4gPj4+Pj4+IGludGVncmF0 aW9uIHBvaW50IGJldHdlZW4gVzNDIGFuZCBJRVRGIHNwZWNzLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+ IFRoZSBjdXJyZW50IEFQSSBkcmFmdCBkb2VzIG5vdCBpbmNsdWRlIGFueSBkaXNjdXNzaW9uIG9m IHByaW9yaXR5LiBIb3dldmVyDQo+ID4+Pj4+PiBkcmFmdC12dnYtd2VidHJhbnMtb3ZlcnZpZXcg ZG9lcyBtZW50aW9uIHByaW9yaXRpZXMuIEFzIHRoaXMgQVBJIGFwcGVhcnMgdG8NCj4gPj4+Pj4+ IHN1cHBvcnQgbXVsdGlwbGUgcGFyYWxsZWwgdHJhbnNtaXNzaW9ucyBhbmQgdHJhbnNmZXJzIEkg dGhpbmsgYXQgYSBtaW5pbWFsIGENCj4gPj4+Pj4+IHNlbmRlciB0cmFuc3BvcnQgcHJvdG9jb2wg c2NoZWR1bGluZyBvciBIVFRQLzMgcHJpb3JpdHkgIHdvdWxkIGJlIGxpa2VseSB0byBiZQ0KPiA+ Pj4+Pj4gcGFydCBvZiB0aGUgd29yay4gSSBhbHNvIGhhdmUgdG8gYXNrIGlmIHRoaXMgaXMgbGlr ZWx5IHRvIGF0dGVtcHRlZCB0byBiZQ0KPiA+Pj4+Pj4gbWFwcGVkIGFsc28gdG93YXJkcyB0aGUg bmV0d29yayBsZXZlbCwgZm9yIGV4YW1wbGUgRFNDUHM/IElmIGFueSBzdWNoIHdvcmsgaXMNCj4g Pj4+Pj4+IGV4cGVjdGVkIGFuZCBpbnRlbmRlZCBJIHRoaW5rIHRoYXQgbmVlZHMgdG8gYmUgcmFp c2VkLiBPdGhlcndpc2UgSSB3b3VsZCBhc3N1bWUNCj4gPj4+Pj4+IHRoYXQgYXQgbW9zdCB3aGF0 IHRoaXMgd29yayB3aWxsIGJlIHRvIHVzZSB0aGUgdW5kZWZpbmVkIEFQSXMgdG8gSFRUUC8zIGFu ZA0KPiA+Pj4+Pj4gUVVJQyB0byBpbmZsdWVuY2UgdGhvc2UgcHJvdG9jb2wgdG8gcGVyZm9ybSBz dHJlYW0gcHJpb3JpdGllcy4uDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhpcyBpcyBtb3N0bHkgYSBn YXAgaW4gdGhlIEFQSSBzcGVjLiAgSSd2ZSBiZWVuIG1lYW5pbmcgdG8gd3JpdGUgdGhpcyB1cA0K PiA+Pj4+Pj4gZnVydGhlciwgYnV0IHRoZXJlJ3MgYSBsb3Qgb2YgdGV4dCB0byB3cml0ZS4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiBCZWZvcmUgSSBlbGFib3JhdGUgZnVydGhlciwgSSB3b3VsZCBsaWtl IHRvIHBvaW50IG91dCB0aGF0IHRoZXJlIGFyZSB0d28gdHlwZXMNCj4gPj4+Pj4+IG9mIHByaW9y aXRpZXMgaGVyZSwgYW5kIHRob3NlIGFyZSBvZnRlbiBjb25mdXNlZDoNCj4gPj4+Pj4+ICgxKSBQ cmlvcml0aWVzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGluZGljYXRlcyB0byB0aGUgdHJhbnNwb3J0 IGxheWVyIGZvciB0aGUNCj4gPj4+Pj4+ICAgIHB1cnBvc2Ugb2Ygc2NoZWR1bGluZyB3cml0ZXMu DQo+ID4+Pj4+PiAoMikgUHJpb3JpdGllcyB0aGF0IGFyZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHBl ZXIgb24gdGhlIHdpcmUgYXMgYSBoaW50Li4uLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IE1vc3Qgb2Yg dGhlIGRpc2N1c3Npb24gaW4gSFRUUEJJUyBhbmQgUVVJQyBXR3Mgd2FzIGFib3V0ICMyLiAgSSBk b24ndCBiZWxpZXZlDQo+ID4+Pj4+PiBhbnkgb2YgdGhlIHByb3Bvc2VkIGRyYWZ0cyBjb3ZlciB0 aGF0IHRvcGljLCBhbmQgSSdkIHJhdGhlciB3YWl0IGZvcg0KPiA+Pj4+Pj4gcXVpYy9odHRwYmlz IHRvIGNvbWUgdXAgd2l0aCBhIG1lY2hhbmlzbSBmaXJzdC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiBU aGUgcHJpb3JpdGllcyBtZW50aW9uZWQgaW4gLW92ZXJ2aWV3IGFyZSBvZiB0aGUgIzEga2luZC4g IFNlY3Rpb24gMi4zIG9mDQo+ID4+Pj4+PiBkcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTI1IGV4 cGxpY2l0bHkgZW5jb3VyYWdlcyBpbXBsZW1lbnRhdGlvbnMgKHRoYXQgd291bGQNCj4gPj4+Pj4+ IGluY2x1ZGUgdGhlIHByb3Bvc2VkIFdlYiBBUElzKSB0byBwcm92aWRlIHRob3NlOg0KPiA+Pj4+ Pj4NCj4gPj4+Pj4+ICIiIg0KPiA+Pj4+Pj4gW1FVSUNdIHJlbGllcyBvbiByZWNlaXZpbmcgcHJp b3JpdHkgaW5mb3JtYXRpb24gZnJvbSB0aGUgYXBwbGljYXRpb24gdGhhdCB1c2VzDQo+ID4+Pj4+ PiBRVUlDLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEEgUVVJQyBpbXBsZW1lbnRhdGlvbiBTSE9VTEQg cHJvdmlkZSB3YXlzIGluIHdoaWNoIGFuIGFwcGxpY2F0aW9uIGNhbiBpbmRpY2F0ZQ0KPiA+Pj4+ Pj4gdGhlIHJlbGF0aXZlIHByaW9yaXR5IG9mIHN0cmVhbXMuIFdoZW4gZGVjaWRpbmcgd2hpY2gg c3RyZWFtcyB0byBkZWRpY2F0ZQ0KPiA+Pj4+Pj4gcmVzb3VyY2VzIHRvLCB0aGUgaW1wbGVtZW50 YXRpb24gU0hPVUxEIHVzZSB0aGUgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhlDQo+ID4+Pj4+ PiBhcHBsaWNhdGlvbi4NCj4gPj4+Pj4+ICIiIg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEJlc2lkZXMs IEkgZG9uJ3QgYmVsaWV2ZSB3ZSBjYW4gYXZvaWQgZGVmaW5pbmcgYSB3cml0ZSBzY2hlZHVsaW5n IG1lY2hhbmlzbSBpbg0KPiA+Pj4+Pj4gdGhlIEFQSS4gIFFVSUMgaXRzZWxmIHRyZWF0cyBpdCBh cyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsIGJ1dCBXZWIgQVBJcw0KPiA+Pj4+Pj4gZ2VuZXJh bGx5IHRyeSByZWFsbHkgaGFyZCB0byBhdm9pZCBpbXBsZW1lbnRhdGlvbi1kZWZpbmVkIGJlaGF2 aW9yLiAgSWYNCj4gPj4+Pj4+IGV2ZXJ5IGJyb3dzZXIgaGFkIGEgY29tcGxldGVseSBkaWZmZXJl bnQgd3JpdGUgc2NoZWR1bGluZyBhcHByb2FjaCwNCj4gPj4+Pj4+IHRoYXQgY291bGQgbWFrZSB0 aGUgam9iIG9mIHdyaXRpbmcgcGVyZm9ybWFudCBjcm9zcy1icm93c2VyIGNvZGUgcmVhbGx5DQo+ ID4+Pj4+PiBkaWZmaWN1bHQuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhhbmtzLA0KPiA+Pj4+Pj4g IFZpY3Rvci4NCj4gPj4+Pj4+IC0tDQo+ID4+Pj4+PiBXZWJ0cmFuc3BvcnQgbWFpbGluZyBsaXN0 DQo+ID4+Pj4+PiBXZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8bWFpbHRvOldlYnRyYW5zcG9ydEBpZXRm Lm9yZz4NCj4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2Vi dHJhbnNwb3J0DQo+ID4+Pj4+DQo+ID4+Pj4gLS0NCj4gPj4+PiBXZWJ0cmFuc3BvcnQgbWFpbGlu ZyBsaXN0DQo+ID4+Pj4gV2VidHJhbnNwb3J0QGlldGYub3JnPG1haWx0bzpXZWJ0cmFuc3BvcnRA aWV0Zi5vcmc+DQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby93 ZWJ0cmFuc3BvcnQNCj4gPj4+DQo+ID4NCj4gPg0KPg0K --_000_MN2PR11MB4366262FAE88B8CFF63A47CDB51B0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPknigJltIG5vdCBzdXJlIGhvdyBsaWtlbHkgUVVJQyBleHRlbnNpb25zIGFyZSBmb3IgV2Vi VHJhbnNwb3J0LCBidXQgd291bGQgaXQgYmUgcG9zc2libGUgdG8gZGVmZXIgdGhlIGRlY2lzaW9u IG9mIGV4YWN0bHkgd2hlcmUgZXh0ZW5zaW9ucyB3b3JrIGlzIGRvbmUsIGlmIHJlcXVpcmVkPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5JLmUuLCByYXRoZXIgdGhhbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIFdlYlRyYW5zcG9ydCB3b3JraW5nIGdy b3VwIG1heSBkZWZpbmUgZXh0ZW5zaW9ucyB0byB0aGVzZSBwcm90b2NvbHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5idXQgYW55IHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGRlZmluaW5n IHN1Y2ggZXh0ZW5zaW9ucyB3aWxsIGFsc28gYmUgc2VudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+dG8gdGhlIG1haWxpbmcgbGlzdCBvZiB0aGUgcmVsZXZhbnQgd29ya2luZyBncm91cC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+cGVyaGFwczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIFdlYlRyYW5zcG9ydCB3b3JraW5nIGdyb3VwIG1heSBj b25zaWRlciBleHRlbnNpb25zIHRvIHRoZXNlIHByb3RvY29scywgYnV0IGlmIHJlcXVpcmVkLCB0 aGUgcmVsZXZhbnQgd29ya2luZyBncm91cHMgc2hhbGwgYmUgY29uc3VsdGVkIHRvIGFncmVlIHRo ZSBtb3N0IGFwcHJvcHJpYXRlIHdvcmtpbmcgZ3JvdXAgdG8gcHJvZ3Jlc3MNCiB0aGUgd29yaywg YW5kIGFsbCByZWxldmFudCB3b3JraW5nIGdyb3VwcyBtdXN0IGJlIGludm9sdmVkIGluIFdHTEMg cmVxdWVzdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPGJyPg0KUm9iPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IGllc2cgJmx0OzxhIGhyZWY9Im1h aWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmciPmllc2ctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7 DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gMTIg RmVicnVhcnkgMjAyMCAxNToyMTxicj4NCjxiPlRvOjwvYj4gTWlyamEgS3VlaGxld2luZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQiPmlldGZAa3VlaGxld2luZC5uZXQ8 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFnbnVzIFdlc3Rlcmx1bmQgJmx0OzxhIGhyZWY9Im1h aWx0bzptYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20iPm1hZ251cy53ZXN0ZXJsdW5kQGVy aWNzc29uLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOndlYnRyYW5zLWNoYWlyc0BpZXRm Lm9yZyI+d2VidHJhbnMtY2hhaXJzQGlldGYub3JnPC9hPjsgV2ViVHJhbnNwb3J0ICZsdDs8YSBo cmVmPSJtYWlsdG86d2VidHJhbnNwb3J0QGlldGYub3JnIj53ZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8 L2E+Jmd0OzsgVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIj5pZXNn QGlldGYub3JnPC9hPiZndDs7IERhdmlkIFNjaGluYXppICZsdDs8YSBocmVmPSJtYWlsdG86ZHNj aGluYXppLmlldGZAZ21haWwuY29tIj5kc2NoaW5hemkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OzsN CiBWaWN0b3IgVmFzaWxpZXYgJmx0OzxhIGhyZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20i PnZhc2lsdnZAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBCYXJyeSBMZWliYSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1dGVyLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbV2VidHJhbnNwb3J0XSBNYWdudXMgV2VzdGVy bHVuZCdzIEJsb2NrIG9uIGNoYXJ0ZXItaWV0Zi13ZWJ0cmFucy0wMC0wMDogKHdpdGggQkxPQ0sg YW5kIENPTU1FTlQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XZWxsLCBJIGRvbid0IHJlYWxseSBhZ3JlZSB0aGF0IHRoaXMgbmVl ZHMgdG8gYmUgYSBsaXZlIGlzc3VlLCBidXQgYXMgeW91IGluc2lzdDo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV4dGVuc2lvbnMgdG8gUVVJQyBz aG91bGQgYmUgcG9zc2libGUgaW4gV0dzIGFjcm9zcyB0aGUgSUVURiwgd2l0aCBwcm9wZXIgY29v cmRpbmF0aW9uIHdpdGggdGhlIFFVSUMgV0cuIFRoaXMgaXNuJ3QgcmVhbGx5IGEgZGVjaXNpb24g Zm9yIHRoZSBRVUlDIFdHLCBidXQgcmF0aGVyIGZvciB0aGUgSUVTRywgSW4gYW55IGNhc2UsIHRo aXMgaXMgcHJlY2lzZWx5IHdoYXQgaXMgY29udGVtcGxhdGVkIGJ5IHRoZSBjdXJyZW50DQogZHJh ZnQuIElmIHlvdSB0aGluayB0aGlzIG5lZWRzIHRvIGdvIGluIHNvbWUgY2hhcnRlciB0ZXh0LCB0 aGVuIGl0IHNob3VsZCBnbyB0aGVyZSBub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxMiwgMjAyMCBhdCA3OjE3 IEFNIE1pcmphIEt1ZWhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQu bmV0Ij5pZXRmQGt1ZWhsZXdpbmQubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8 YnI+DQomZ3Q7IE9uIDEyLiBGZWIgMjAyMCwgYXQgMTY6MTMsIEVyaWMgUmVzY29ybGEgJmx0Ozxh IGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IE9uIFdlZCwgRmViIDEyLCAyMDIwIGF0IDY6NDAgQU0gTWlyamEgS3VlaGxld2luZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlldGZAa3VlaGxld2luZC5uZXQiIHRhcmdldD0iX2JsYW5rIj5pZXRmQGt1 ZWhsZXdpbmQubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBUaGUgd2hvbGUgcG9pbnQgaXMg dGhhdCB0aGUgUVVJQyBwcm90b2NvbCBpcyBub3QgZmluaXNoZWQgeWV0IGFuZCB0aGUgcmVzcGVj dGl2ZSByZWdpc3RyeSBkb2VzbuKAmXQgZXhpc3RzIHlldC48YnI+DQomZ3Q7IDxicj4NCiZndDsg QW5kIFdlYlRyYW5zcG9ydCB3aWxsIGhhdmUgYSBub3JtYXRpdmUgZGVwZW5kZW5jeSBvbiBRVUlD IGFuZCB0aGVyZWZvcmUgd2lsbCBub3QgYmUgZmluaXNoZWQgcHJpb3IgdG8gdGhhdCByZWdpc3Ry eSBleGlzdGluZy48YnI+DQo8YnI+DQpCdXQgdGhlIGNoYXJ0ZXIgd2lsbCBiZSBmaW5pc2hlZCBi ZWZvcmUgdGhhdCBhbmQgd2UgbmVlZCB0byBkZWNpZGUgbm93IHdoYXQgdG8gd3JpdGUgaW4gdGhl cmUuIFRoYXTigJlzIHdoYXQgd2UgYXJlIGRpc2N1c3NpbmcuPGJyPg0KPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgQWxsIEnigJltIHNheWluZyB0aGF0IHdlIHNob3VsZCBub3QgYmFr ZSBwcm9jZXNzIGluIHRoZSB0aGUgd2VidHJhbnNwb3J0IGNoYXJ0ZXIgdGhhdCBtaWdodCByZXN0 cmljdCBhIGZ1dHVyZSBkaXNjdXNzIHdlIHdhbnQgdG8gaGF2ZSBpbiB0aGUgUVVJQyBncm91cC48 YnI+DQomZ3Q7IDxicj4NCiZndDsgV2hhdCBmdXR1cmUgZGlzY3Vzc2lvbj8gQXMgSSBzYWlkLCB0 aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBpbXBsaWNpdCBkZWNpZGUgdGhpcyBtYXR0ZXIuIElzIHNv bWVvbmUgYXJndWluZyB0byBjaGFuZ2UgdGhvc2UgdG8gU3RhbmRhcmRzIFRyYWNrPzxicj4NCjxi cj4NCkFzIE1hZ251cyB3cm90ZSBzZXZlcmFsIHRpbWVzIGluIHRoZSByZXNlbnRlZCByZS1jaGFy dGVyaW5nIGRpc2N1c3Npb246PGJyPg0KPGJyPg0KJnF1b3Q7QSByZWFzb24gZm9yIHRoZSB0d28g c3RlcCByZWNoYXJ0ZXJpbmcgaXMgdGhhdCBJIHRoaW5rIHdlIHdpbGwgbmVlZCB0byBoYXZlIGE8 YnI+DQpzZXJpb3VzIGRpc2N1c3Npb24gb2YgaG93IHRvIHdvcmsgb24gdjIgYW5kIGV4dGVuc2lv bnMgbW9yZSBnZW5lcmFsbHkuIEkgdGhpbms8YnI+DQpnb2luZyBpbnRvIHRoZXNlIGRldGFpbHMg bm93IGlzIHByZW1hdHVyZS4gQnV0IHdlIHdpbGwgbmVlZCB0byBjb21lIGJhY2sgdG8gdGhpczxi cj4NCmxhdGVyLuKAnTxicj4NCjxicj4NCk1pcmphPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IC1Fa3I8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7ICZndDsgT24gMTIuIEZlYiAyMDIwLCBhdCAxNToyNiwgQmFycnkgTGVpYmEgJmx0OzxhIGhy ZWY9Im1haWx0bzpiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJhcnJ5 bGVpYmFAY29tcHV0ZXIub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBJIGhhdmUgdG8gYWdyZWUgd2l0aCBFS1IgaGVyZTogSSdtIG5vdCBhd2FyZSBvZiBh bnkgb3RoZXIgcHJvdG9jb2xzPGJyPg0KJmd0OyAmZ3Q7IHRoYXQgZGVmaW5lIFNwZWNpZmljYXRp b24gUmVxdWlyZWQgZXh0ZW5zaW9uIG1lY2hhbmlzbXMgd2hlcmUgd2Ugc2F5PGJyPg0KJmd0OyAm Z3Q7IHRoYXQgdGhlIG9yaWdpbmFsIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGJlIGluIGNvbnRyb2wg b2YgdGhlPGJyPg0KJmd0OyAmZ3Q7IGV4dGVuc2lvbnMuJm5ic3A7IEkgd291bGRuJ3Qgd2FudCB0 byBzdGFydCBpdCBoZXJlLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIEFEcyB3 aWxsIGRlc2lnbmF0ZSBleHBlcnRzIHRvIHJldmlldyB0aGUgZXh0ZW5zaW9uIHNwZWNpZmljYXRp b25zLDxicj4NCiZndDsgJmd0OyBhbmQgdGhhdCBpcyB0aGUgbWVjaGFuaXNtIGZvciB0aGUgd29y a2luZyBncm91cCB0byBoYXZlIGl0cyBzYXkgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7IGV4dGVuc2lv bnMuJm5ic3A7IEFuZCBpbiB0aGlzIGNhc2UsIHRoZSBjaGFydGVyIGV4cGxpY2l0bHkgc2F5cyB0 aGF0PGJyPg0KJmd0OyAmZ3Q7IHdlYnRyYW5zIHdpbGwgY29vcmRpbmF0ZSB3aXRoIHF1aWMuJm5i c3A7IEkgc2VlIG5vIHJlYXNvbiB0byBiZSBtb3JlPGJyPg0KJmd0OyAmZ3Q7IHNwZWNpZmljIGhl cmUsIG5vciB0byByZXF1aXJlIG1vcmUuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBC YXJyeTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gV2VkLCBGZWIgMTIsIDIwMjAg YXQgOToxNSBBTSBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29t IiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBPbiBXZWQsIEZlYiAxMiwgMjAyMCBhdCAyOjQ5IEFNIE1pcmphIEt1ZWhsZXdp bmQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0IiB0YXJnZXQ9Il9ibGFu ayI+aWV0ZkBrdWVobGV3aW5kLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEhpIEVrciw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBZZXMsIGl0IGlzIHNwZWNpZmljYXRpb24gcmVxdWly ZWQsIGhvd2V2ZXIsIGlmIHdlIGRlY2lkZSB0byBwdXNoaW5nIGFuIFJGQyB0aGVuIHdlIG5lZWQg dG8gZGVjaWRlIHdoZXJlIHRoaXMgd29yayBpbiB0aGUgSUVURiBjYW4gYmUgZG9uIGJlc3QuPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsg VGhpcyBzZWVtcyBsaWtlIGEgdmVyeSBvZGQgcG9zaXRpb24uIEFzIHNvb24gYXMgdGhlIFFVSUMg UkZDIGlzIHB1Ymxpc2hlZCwgYW55b25lIGVsc2UgaW4gdGhlIHdvcmxkIGNhbiBhc3NpZ24gbmV3 IFFVSUMgY29kZSBwb2ludHMsIGJ1dCBpbnNpZGUgdGhlIElFVEYsIHVudGlsIHRoZXJlO3Mgc29t ZSBkaXNjdXNzaW9uIGluIHRoZSBRVUlDIHRoZXJlIHdvbid0IGJlIGFueSBwcm9jZXNzIG90aGVy IHRoYW4gYXNraW5nIHRoZSBRVUlDIFdHPzxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBB bGwgSeKAmW0gc2F5aW5nIHRoYXQgdGhlIHByb2Nlc3MgaG93IGFuZCB3aGVyZSB0byBkZWZpbmUg UVVJQyBleHRlbnNpb25zIGluIHRoZSBJRVRGIG5lZWRzIHRvIGJlIGRlY2lkZWQgYnkgdGhlIFFV SUMgZ3JvdXAgYW5kIGEgZnV0dXJlIFFVSUMgY2hhcnRlciBhbmQgbm90IGJ5IHRoZSBjaGFydGVy IG9mIGFueSBvdGhlciB3b3JraW5nIGdyb3VwLjxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHBy b2Nlc3MgeW91IHRoaW5rIHJlcXVpcmVzIHRoaXMuIFRoZXJlIHdhcyBuZXZlciBhbnkgc3VjaCBm b3JtYWwgZGlzY3Vzc2lvbiBpbiB0aGUgVExTIFdHIEFGQUlLLiBJbiBteSBleHBlcmllbmNlIHdo ZW4gc29tZSBXRyB3YW50cyB0byBkZWZpbmUgYSBUTFMgZXh0ZW5zaW9uIHRoZXJlJ3MgYSBicmll ZiBkaXNjdXNzaW9uIGJldHdlZW4gdGhlIGNoYWlycyBhbmQgQURzIGFib3V0IHdoZXRoZXIgaXQn cw0KIG9ydGhvZ29uYWwgZW5vdWdoIHRvIGRvIHNlcGFyYXRlbHkuIEl0J3Mgbm90IGluIHRoZSBU TFMgY2hhcnRlciwgZm9yIGluc3RhbmNlLCBBRkFJQ1QuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7ICZndDsmZ3Q7IC1Fa3I8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IEFnYWluIHRoYXQgZG9lc27igJl0IG1lYW4gdGhhdCBpbiBmdXR1cmUgaXQgd2lsbCBu b3QgYmUgcG9zc2libGUgZm9yIG90aGVyIGdyb3VwcyB0byBkZWZpbmUgZXh0ZW5zaW9uIGJ1dCB3 ZSBuZWVkIHRvIGhhdmUgdGhhdCBkaXNjdXNzaW9uIGZpcnN0Ljxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IE1pcmphPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDExLiBGZWIgMjAyMCwgYXQgMjI6MzQsIEVyaWMgUmVzY29y bGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JA cnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgT24gVHVlLCBGZWIgMTEsIDIwMjAgYXQgMTozMSBQTSAmcXVv dDtNaXJqYSBLw7xobGV3aW5kIChJRVRGKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZA a3VlaGxld2luZC5uZXQiIHRhcmdldD0iX2JsYW5rIj5pZXRmQGt1ZWhsZXdpbmQubmV0PC9hPiZn dDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIERhdmlkLDxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSSBkaWRu4oCZdCBz YXkgdGhhdCBvdGhlciBncm91cHMgY2Fubm90IGRlZmluZSBleHRlbnNpb24uIEkgZGlkIHNheSB0 aGF0IGl04oCZcyB0aGUgZGVjaXNpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgdGhhdCBtYWludGFp bnMgdGhlIHByb3RvY29sIGhvdyB0byBoYW5kbGUgdGhhdCBhbmQgZm9yIFF1aWMgd2UgZGlkbuKA mXQgaGF2ZSBoYWQgdGhhdCBkaXNjdXNzaW9uIHlldC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IEV4YW1wbGVzIGZvciBncm91cHMgdGhhdCBl eHBsaWNpdGx5IGRlZmluZSBwcm9jZXNzIGZvciBleHRlbmRpbmcgdGhlIHByb3RvY29sIGluIHRo ZWlyIGNoYXJ0ZXIgYXJlIGRoYyBhbmQgNm1hbi4gQXMgeW91IGNhbiBzZWUgZGlmZmVyZW50IGdy b3Vwcy9wcm90b2NvbHMgaGF2ZSBkaWZmZXJlbnQgcHJvY2VzcyBhbmQgYXMgd2UgZGlkbuKAmXQg ZGVmaW5lIGFueXRoaW5nIHlldCBmb3IgUXVpYywgdGhlIHdvcmtpbmcgYXNzdW1wdGlvbiBmb3IN CiBub3cgc2hvdWxkIGJlIHRoYXQgYWxsIGV4dGVuc2lvbiB3b3JrIHdpbGwgYmUgZmluZSBpbiB0 aGUgUXVpYyBncm91cC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IFdlbGwsIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIGZvciBRVUlDIHRyYW5z cG9ydCBzZWVtIGZhaXJseSBjbGVhcjo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0LTI1I3NlY3Rpb24tMjIuMS40IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLXRyYW5z cG9ydC0yNSNzZWN0aW9uLTIyLjEuNDwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IE1vc3Qgb2YgdGhlIGNvZGUgcG9pbnRzIGFyZSBhc3Np Z25lZCB2aWEgU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCwgc28gSSBkb24ndCBzZWUgd2h5IHlvdSB3 b3VsZCBpbmZlciB0aGF0IGFsbCBleHRlbnNpb25zIGhhcHBlbiB3aXRoaW4gdGhlIFFVSUMgV0cu Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg LUVrcjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsg TWlyamE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW0gMTEuMDIuMjAyMCB1bSAyMTo0 NyBzY2hyaWViIERhdmlkIFNjaGluYXppICZsdDs8YSBocmVmPSJtYWlsdG86ZHNjaGluYXppLmll dGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNjaGluYXppLmlldGZAZ21haWwuY29tPC9h PiZndDs6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IO+7vzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgTWlyamEs PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IEknbSBub3Qgc3VyZSBJIGFncmVlIHdpdGggeW91ciBpbnRlcnByZXRhdGlvbi4uIFRo ZSBmYWN0IHRoYXQgYSBXRyBpczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVzcG9u c2libGUgZm9yIGEgcHJvdG9jb2wgZG9lcyBub3QgbWVhbiB0aGF0IG90aGVyIHdvcmtpbmcgZ3Jv dXBzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjYW5ub3Qgd3JpdGUgZXh0ZW5zaW9u cyB0byB0aGF0IHByb3RvY29sLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGb3IgZXhhbXBsZSwgdGhlIFFVSUMgV0cgaXMgZGVm aW5pbmcgdGhlIHF1aWNfdHJhbnNwb3J0X3BhcmFtZXRlcnM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRMUyBleHRlbnNpb24uIFRoYXQgZXh0ZW5zaW9uIGlzIG5vdCBkZWZpbmVkIGlu IHRoZSBUTFMgV0cuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1xdWljLXRscy0yNSNzZWN0aW9uLTgu MiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtcXVpYy10bHMtMjUjc2VjdGlvbi04LjI8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNpbWlsYXJseSwgdGhlIEFDTUUg V0cgaXMgZGVmaW5pbmcgdGhlIENlcnQtTm90LUJlZm9yZSBIVFRQPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBoZWFkZXIsIG5vdCB0aGUgSFRUUCBXRy48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWFjbWUtc3Rhci0xMSNzZWN0aW9uLTYuNyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNtZS1zdGFyLTExI3NlY3Rpb24tNi43PC9h Pjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBBZGRpdGlvbmFsbHksIE1QVENQIGlzIGFuIGV4dGVuc2lvbiB0byBUQ1AgdGhhdCB3 YXMgbm90PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkZWZpbmVkIGluIHRoZSBUQ1BN IFdHLiBUaGUgbGlzdCBnb2VzIG9uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBXZSBkb24ndCB5ZXQgaGF2ZSBleGFtcGxlcyBm b3IgUVVJQyBhcyB0aGUgUVVJQyBJQU5BPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBy ZWdpc3RyaWVzIGhhdmVuJ3QgYmVlbiBjcmVhdGVkIHlldCwgYnV0IEkgZG9uJ3Qgc2VlIHdoeSBR VUlDPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3VsZCBiZSBkaWZmZXJlbnQgZnJv bSBUTFMsIEhUVFAsIG9yIFRDUC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgRGF2aWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBPbiBUdWUsIEZlYiAxMSwgMjAyMCBhdCA0OjM4IEFNIE1pcmphIEt1ZWhs ZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGt1ZWhsZXdpbmQubmV0IiB0YXJnZXQ9Il9i bGFuayI+aWV0ZkBrdWVobGV3aW5kLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSGkgRGF2aWQsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uZSBtb3JlIGNvbW1lbnQgYmVsb3cuPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBPbiA2LiBGZWIgMjAyMCwgYXQgMTQ6NDYsIERhdmlkIFNjaGluYXppICZsdDs8YSBo cmVmPSJtYWlsdG86ZHNjaGluYXppLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHNj aGluYXppLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgTWFn bnVzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgcmVhbGl6ZWQgdGhhdCBzb21lIG9mIG91ciBlYXJsaWVyIHJl cGxpZXMgd2VyZSBhY2NpZGVudGFsbHkgbm90IHNlbnQgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGUgSUVTRyBsaXN0LCBmb3Igd2hpY2ggSSBhcG9sb2dpemUuPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVG8gc3VtbWFyaXplIHRoYXQgZGlzY3Vzc2lvbjo8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtIEl0 IGlzIG5vdCBvdXIgaW50ZW50aW9uIHRvIGJ1aWxkIGEgbmV3IHRyYW5zcG9ydCBwcm90b2NvbCBo ZXJlLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBXRUJUUkFOUyBXRyB3 b3VsZCBidWlsZCBhcHBsaWNhdGlvbiBwcm90b2NvbHMgdGhhdDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHJ1biBvdmVyIFFVSUMsIG9yIFRMUy9UQ1AuIFRoaXMgd291bGQgZW5z dXJlIHdlIGJlbmVmaXQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmcm9tIHRo ZWlyIHNlY3VyaXR5IGFuZCBjb25nZXN0aW9uIGNvbnRyb2wgcHJvcGVydGllcy48YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIZXJlIGlzIGEgUFIgdG8gdGhlIGNoYXJ0ZXIgdGhh dCBzaG91bGQgY2xhcmlmeSB0aGlzOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9EYXZpZFNjaGluYXppL3dlYnRyYW5zLXdnLW1h dGVyaWFscy9wdWxsLzYvZmlsZXMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNv bS9EYXZpZFNjaGluYXppL3dlYnRyYW5zLXdnLW1hdGVyaWFscy9wdWxsLzYvZmlsZXM8L2E+PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgLSBUaGUgV0VCVFJBTlMgV0cgd291bGQgbm90IG1vZGlmeSBRVUlDIG9yIEhU VFAuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW55IGRpc2N1c3Npb24gb2Yg bW9kaWZ5aW5nIHRob3NlIGNvcmUgcHJvdG9jb2xzIHdvdWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgaGFwcGVuIGluIHRoZWlyIGV4aXN0aW5nIHJlc3BlY3RpdmUgd29ya2lu ZyBncm91cHMuLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhvd2V2ZXIsIGRp c2N1c3Npb24gb2YgZXh0ZW5zaW9ucyB0byB0aGVzZSBwcm90b2NvbHMgY291bGQ8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBhbGxvd2VkIGluIHRoaXMgV0csIGFzIGxvbmcg YXMgYW55IGRvY3VtZW50IFdHTEMgaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBhbHNvIHNlbnQgdG8gdGhlIG1haWxpbmcgbGlzdCByZXNwb25zaWJsZSBmb3IgdGhhdCBwcm90 b2NvbC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsgSSB0aGluayB0aGlzIGlzIG5vdCBzdWZmaWNpZW50LCBhdCBsZWFzdCBub3Qg Zm9yIFFVSUMuIE1vcmUgZGlzY3Vzc2lvbiBpcyBuZWVkZWQgaW4gdGhlIFFVSUMgZ3JvdXAgb24g dGhpcyBidXQgY3VycmVudGx5IEkgdGhpbmsgdGhlIGFzc3VtcHRpb24gc2hvdWxkIGJlIHRoYXQg YWxsIGV4dGVuc2lvbnMgd2lsbCBiZSBkb25lIHdpdGhpbiB0aGUgUVVJQyBncm91cC4gU28ganVz dCBzZW5kaW5nIGEgV0dMQyB0aGVyZSBpcyBub3Qgc3VmZmljaWVudC48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTW9yZSBnZW5l cmFsbHkgZGVjaWRpbmcgb24gcHJvY2Vzc2VzIGZvciBvdGhlciBwcm90b2NvbHMvZ3JvdXBzIGlu IHRoaXMgY2hhcnRlciBpcyBub3QgYXBwcm9wcmlhdGUuIEnigJltIG5vdCBzdXJlIHdoYXQgdGhl IGRlZmluZWQgcHJvY2VzcyBpcyBmb3IgSFRUUCBhbmQgVExTIGJ1dCB0aGF0IHNob3VsZCBiZSBz cGVjaWZpZWQgaW4gdGhlaXIgY2hhcnRlciBhbmQgbm90IGhlcmUuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZvciBRVUlDLCBJ IHdvdWxkIGxpa2UgdG8gcmF0aGVyIHNlZSB0aGF0IGV4dGVuc2lvbiBvciBtb2RpZmljYXRpb24g YXJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBncm91cC4gT2YgY291cnNlIHRoYXQgZG9lc27igJl0 IG1lYW4gdGhhdCB0aGlzIGdyb3VwIGNhbm5vdCB0YWxrIGFib3V0IGFueSBleHRlbnNpb24gYnV0 IGFzIHNvb24gYXMgdGhlIGdyb3VwIHRoaW5rcyBhbiBleHRlbnNpb24gaXMgbmVlZGVkLCBpdCBu ZWVkcyB0byBnbyB0bw0KIHRoZSBRVUlDIGdyb3VwIGFuZCBjYW5ub3QganVzdCBhZGFwdCBhbnl0 aGluZyB3aXRoaW4gV2ViVHJhbnNwb3J0Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQbGVhc2UgYWxzbyBkb3VibGUtY2hlY2sg d2hhdCB0aGUgcmlnaHQgcHJvY2VzcyBpcyBmb3IgVExTIGFuZCBIVFRQLiBJIGFzc3VtZSBmb3Ig VExTIGl0J3MgdGhlIHNhbWUgYnV0IGZvciBIVFRQIGl0IG1pZ2h0IGJlIGRpZmZlcmVudOKApj88 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgTWlyamE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBXb3VsZCB0aGF0IGJlIGFuIGFjY2VwdGFibGUgc2NvcGU/PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg VGhhbmtzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IERhdmlkPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgT24gVHVlLCBGZWIgNCwgMjAyMCBhdCAxMTowNyBBTSBWaWN0b3IgVmFzaWxpZXYgJmx0 OzxhIGhyZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj52YXNp bHZ2QGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBJIGJlbGlldmUgbW9zdCBvZiB0aG9zZSBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIERh dmlkJ3MgUFIsIHNvIEknbGwgdHJ5IHRvIHJlcGx5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgcHJpbWFyaWx5IHRvIHRob3NlIHRoYXQgSSBoYXZlIHNvbWV0aGluZyB0byBhZGQg dG8uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIEZyaSwgSmFuIDMxLCAyMDIwIGF0IDU6MzkgUE0gTWFnbnVz IFdlc3Rlcmx1bmQgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBp ZXRmLi5vcmciPm5vcmVwbHlAaWV0Zi4ub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWFnbnVzIFdlc3Rlcmx1bmQgaGFzIGVudGVyZWQgdGhlIGZv bGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgY2hhcnRlci1pZXRmLXdlYnRyYW5zLTAwLTAwOiBCbG9jazxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdo ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl cGx5IHRvIGFsbDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi13ZWJ0cmFucy8iIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi13ZWJ0cmFu cy88L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEJMT0NLOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbc25pcF08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZ3JvdXAgd2lsbCBh bHNvIGNvb3JkaW5hdGUgd2l0aCByZWxhdGVkIHdvcmtpbmcgZ3JvdXBzIHdpdGhpbiB0aGUgSUVU Riw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdWNoIGFzIFFVSUMgYW5kIEhU VFBCSVMsIGFzIGFwcHJvcHJpYXRlLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdpdGggdGhlIGN1cnJlbnQgc3Rh dGUgb2YgUVVJQyBkZXZlbG9wZW1lbnQgYW5kIEhUVFAvMyBtYXBwaW5nIGRlZmluaXRpb24sIGku ZS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdGlsbCB3b3JraW5nIG9uIHRo ZSBpbml0aWFsIHZlcnNpb24sIEkgd291bGQgbGlrZSB0byBoYXZlIGEgbW9yZSBmaXJtIHdvcmRp bmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IHRoZSBXZWJUcmFucyBX RyB3aWxsIGFjdHVhbGx5IGhhdmUgdG8gdGFrZSBhbnkgcmVxdWVzdHMgZm9yIGV4dGVuc2lvbnMg b2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIVFRQLzMgYW5kIFFVSUMgdG8g dGhlIHJlbGV2YW50IFdHLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdoaWxlIHRoZXJlIGFyZSBubyBleHRlbnNp b25zIHRvIFFVSUMgYW1vbmcgdGhlIHByb3Bvc2VkIFdHIGRvY3VtZW50cywgc29tZSBvZjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBkcmFmdHMgZG8gZXh0ZW5kIEhUVFAg dXNpbmcgY3VzdG9tIFNFVFRJTkdTIHBhcmFtZXRlcnMgKHdoaWNoIGlzIHRoZTxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVuZGVkIEhUVFAgZXh0ZW5zaWJpbGl0eSBtZWNo YW5pc20pLiZuYnNwOyBJJ3ZlIGhpdGhlcnRvIGFzc3VtZWQgdGhhdCB3ZWJ0cmFuczxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdvdWxkIHdvcmsgd2l0aCBIVFRQIGV4cGVydHMg aW4gaHR0cGJpcy9xdWljIHRvIGVuc3VyZSB0aGF0IHRoZSBwcm9wb3NlZDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4dGVuc2lvbnMgYXJlIGFyY2hpdGVjdHVyYWxseSBzb3Vu ZCBhbmQgZm9sbG93IGJlc3QgcHJhY3RpY2VzLCBidXQgdGhlIG1haW48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBidWxrIG9mIHdvcmsgd291bGQgYmUgZG9uZSBpbiB0aGUgbmV3 IHdvcmtpbmcgZ3JvdXAgaXRzZWxmLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDT01NRU5UOjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGFsc28gd291bGQg YXBwcmVjaWF0ZSBpZiBzb21lb25lIGNhbiBjbGFyaWZ5IHdoYXQgc3RhZ2Ugb2YgZm9ybWFsaXR5 IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFdlYi1UcmFuc3BvcnQgQVBJ IGhhcyBiZWVuIGFkb3B0ZWQgaW4gVzNDIGFuZCBpcyBiZWluZyB3b3JrZWQgb24uIFRyeWluZyB0 bzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZpbmQgYW55dGhpbmcgYWJvdXQg d2hpY2ggZ3JvdXAgaXQgYmVsb25ncyB0byBvbiB0aGUgVzNDIHBhZ2UgZGlkbid0IGdpdmUgbWU8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbnkgaW5mb3JtYXRpb24uIEFsbCBJ IGZvdW5kIGlzIHRoYXQgdGhlcmUgaGF2ZSBiZWVuIGEgd29ya3Nob3Agb24gZ2FtZTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbW11bmljYXRpb24gd2hlcmUgdGhpcyB3YXMg ZGlzY3Vzc2VkIGFuZCByYWlzZWQgaW4gc29tZSBkaXNjdXNzaW9ucy48YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJ dCdzIGEgV0lDRyBkcmFmdCwgd2hpY2ggYmFzaWNhbGx5IG1lYW5zIG5vIGZvcm1hbCBzdGF0dXMu LiZuYnNwOyBXZSBoYWQgYSBkaXNjdXNzaW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgc2Vzc2lvbiBhdCBUUEFDIGxhc3QgeWVhciwgYW5kIEkgYmVsaWV2ZSBtb3N0IHBlb3Bs ZSB3aG8nZCBiZSBub3JtYWxseSBpbnZvbHZlZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGFyZSBhd2FyZSBvZiBpdCwgYnV0IG15IGN1cnJlbnQgdW5kZXJzdGFuZGluZyBpcyB0 aGF0IHRoZSBlZGl0b3JzIG9mIHRoZSBXM0M8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzcGVjIGN1cnJlbnRseSBkbyBub3QgYmVsaWV2ZSB3ZSBoYXZlIGVub3VnaCByZWFsLXdv cmxkIGltcGxlbWVudGF0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhw ZXJpZW5jZSB3aXRoIHRoZSBwcm9wb3NhbCB0byBhZHZhbmNlIGl0IGZ1cnRoZXIgaW4gdGhlIGZv cm1hbCBwcm9jZXNzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhhdmluZyBsaXZlZCB0aHJvdWdoIHRoZSBXZWJS VEMgLyBSVENXZWIgaW50ZXJhY3Rpb25zIGl0IHdvdWxkIGdvb2QgdG8ga25vdzxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1vcmUgaG93IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVu IHRoZSBib2RpZXMgYXJlIGludGVuZGVkIHRvIHdvcmsuIEVzcGVjaWFsbHkgYXM8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFuZ2VzIHRvIHRoZSBBUEkgY2FuIGhhdmUgc2ln bmlmaWNhbnQgaW1wYWN0IG9uIHdoYXQgd29yayBuZWVkcyB0byBoYXBwZW4gaW48YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgSUVURi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIG1vc3Rs eSBhZ3JlZSB3aXRoIEJlcm5hcmQgaGVyZS4mbmJzcDsgTXkgcGxhbiB3YXMgdGhhdCB0aGUgLW92 ZXJ2aWV3IGRvYyB3b3VsZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3Qg YWxsIG9mIHRoZSBwcm90b2NvbCByZXF1aXJlbWVudHMgYW5kIEFQSSBleHBlY3RhdGlvbnMsIGFj dGluZyBhczxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGludGVncmF0aW9uIHBv aW50IGJldHdlZW4gVzNDIGFuZCBJRVRGIHNwZWNzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBjdXJyZW50 IEFQSSBkcmFmdCBkb2VzIG5vdCBpbmNsdWRlIGFueSBkaXNjdXNzaW9uIG9mIHByaW9yaXR5LiBI b3dldmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtdnZ2LXdlYnRy YW5zLW92ZXJ2aWV3IGRvZXMgbWVudGlvbiBwcmlvcml0aWVzLiBBcyB0aGlzIEFQSSBhcHBlYXJz IHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc3VwcG9ydCBtdWx0aXBsZSBw YXJhbGxlbCB0cmFuc21pc3Npb25zIGFuZCB0cmFuc2ZlcnMgSSB0aGluayBhdCBhIG1pbmltYWwg YTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNlbmRlciB0cmFuc3BvcnQgcHJv dG9jb2wgc2NoZWR1bGluZyBvciBIVFRQLzMgcHJpb3JpdHkmbmJzcDsgd291bGQgYmUgbGlrZWx5 IHRvIGJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFydCBvZiB0aGUgd29y ay4gSSBhbHNvIGhhdmUgdG8gYXNrIGlmIHRoaXMgaXMgbGlrZWx5IHRvIGF0dGVtcHRlZCB0byBi ZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1hcHBlZCBhbHNvIHRvd2FyZHMg dGhlIG5ldHdvcmsgbGV2ZWwsIGZvciBleGFtcGxlIERTQ1BzPyBJZiBhbnkgc3VjaCB3b3JrIGlz PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhwZWN0ZWQgYW5kIGludGVuZGVk IEkgdGhpbmsgdGhhdCBuZWVkcyB0byBiZSByYWlzZWQuIE90aGVyd2lzZSBJIHdvdWxkIGFzc3Vt ZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgYXQgbW9zdCB3aGF0IHRo aXMgd29yayB3aWxsIGJlIHRvIHVzZSB0aGUgdW5kZWZpbmVkIEFQSXMgdG8gSFRUUC8zIGFuZDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFFVSUMgdG8gaW5mbHVlbmNlIHRob3Nl IHByb3RvY29sIHRvIHBlcmZvcm0gc3RyZWFtIHByaW9yaXRpZXMuLjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRo aXMgaXMgbW9zdGx5IGEgZ2FwIGluIHRoZSBBUEkgc3BlYy4mbmJzcDsgSSd2ZSBiZWVuIG1lYW5p bmcgdG8gd3JpdGUgdGhpcyB1cDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1 cnRoZXIsIGJ1dCB0aGVyZSdzIGEgbG90IG9mIHRleHQgdG8gd3JpdGUuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg QmVmb3JlIEkgZWxhYm9yYXRlIGZ1cnRoZXIsIEkgd291bGQgbGlrZSB0byBwb2ludCBvdXQgdGhh dCB0aGVyZSBhcmUgdHdvIHR5cGVzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg b2YgcHJpb3JpdGllcyBoZXJlLCBhbmQgdGhvc2UgYXJlIG9mdGVuIGNvbmZ1c2VkOjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICgxKSBQcmlvcml0aWVzIHRoYXQgdGhlIGFwcGxp Y2F0aW9uIGluZGljYXRlcyB0byB0aGUgdHJhbnNwb3J0IGxheWVyIGZvciB0aGU8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgcHVycG9zZSBvZiBzY2hlZHVs aW5nIHdyaXRlcy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoMikgUHJpb3Jp dGllcyB0aGF0IGFyZSBjb21tdW5pY2F0ZWQgdG8gdGhlIHBlZXIgb24gdGhlIHdpcmUgYXMgYSBo aW50Li4uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1vc3Qgb2YgdGhlIGRpc2N1c3Npb24gaW4gSFRUUEJJUyBh bmQgUVVJQyBXR3Mgd2FzIGFib3V0ICMyLiZuYnNwOyBJIGRvbid0IGJlbGlldmU8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbnkgb2YgdGhlIHByb3Bvc2VkIGRyYWZ0cyBjb3Zl ciB0aGF0IHRvcGljLCBhbmQgSSdkIHJhdGhlciB3YWl0IGZvcjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHF1aWMvaHR0cGJpcyB0byBjb21lIHVwIHdpdGggYSBtZWNoYW5pc20g Zmlyc3QuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIHByaW9yaXRpZXMgbWVudGlvbmVkIGluIC1vdmVydmll dyBhcmUgb2YgdGhlICMxIGtpbmQuJm5ic3A7IFNlY3Rpb24gMi4zIG9mPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC0yNSBleHBsaWNp dGx5IGVuY291cmFnZXMgaW1wbGVtZW50YXRpb25zICh0aGF0IHdvdWxkPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW5jbHVkZSB0aGUgcHJvcG9zZWQgV2ViIEFQSXMpIHRvIHBy b3ZpZGUgdGhvc2U6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW1FVSUNdIHJlbGllcyBvbiByZWNlaXZpbmcgcHJpb3Jp dHkgaW5mb3JtYXRpb24gZnJvbSB0aGUgYXBwbGljYXRpb24gdGhhdCB1c2VzPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgUVVJQy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBIFFVSUMgaW1wbGVt ZW50YXRpb24gU0hPVUxEIHByb3ZpZGUgd2F5cyBpbiB3aGljaCBhbiBhcHBsaWNhdGlvbiBjYW4g aW5kaWNhdGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUgcmVsYXRpdmUg cHJpb3JpdHkgb2Ygc3RyZWFtcy4gV2hlbiBkZWNpZGluZyB3aGljaCBzdHJlYW1zIHRvIGRlZGlj YXRlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVzb3VyY2VzIHRvLCB0aGUg aW1wbGVtZW50YXRpb24gU0hPVUxEIHVzZSB0aGUgaW5mb3JtYXRpb24gcHJvdmlkZWQgYnkgdGhl PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwbGljYXRpb24uPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7JnF1b3Q7JnF1b3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgQmVzaWRlcywgSSBkb24ndCBiZWxpZXZlIHdlIGNhbiBhdm9pZCBkZWZpbmluZyBhIHdyaXRl IHNjaGVkdWxpbmcgbWVjaGFuaXNtIGluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgdGhlIEFQSS4mbmJzcDsgUVVJQyBpdHNlbGYgdHJlYXRzIGl0IGFzIGFuIGltcGxlbWVudGF0 aW9uIGRldGFpbCwgYnV0IFdlYiBBUElzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgZ2VuZXJhbGx5IHRyeSByZWFsbHkgaGFyZCB0byBhdm9pZCBpbXBsZW1lbnRhdGlvbi1kZWZp bmVkIGJlaGF2aW9yLiZuYnNwOyBJZjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGV2ZXJ5IGJyb3dzZXIgaGFkIGEgY29tcGxldGVseSBkaWZmZXJlbnQgd3JpdGUgc2NoZWR1bGlu ZyBhcHByb2FjaCw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGNvdWxk IG1ha2UgdGhlIGpvYiBvZiB3cml0aW5nIHBlcmZvcm1hbnQgY3Jvc3MtYnJvd3NlciBjb2RlIHJl YWxseTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRpZmZpY3VsdC48YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg VmljdG9yLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2VidHJhbnNwb3J0IG1haWxpbmcgbGlzdDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpXZWJ0cmFuc3BvcnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5XZWJ0cmFuc3BvcnRAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby93ZWJ0cmFuc3BvcnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VidHJhbnNwb3J0PC9hPjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IC0tPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFdlYnRyYW5zcG9ydCBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOldlYnRyYW5zcG9ydEBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPldlYnRyYW5zcG9ydEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby93ZWJ0cmFuc3BvcnQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vd2VidHJhbnNwb3J0PC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_MN2PR11MB4366262FAE88B8CFF63A47CDB51B0MN2PR11MB4366namp_-- From nobody Wed Feb 12 08:56:58 2020 Return-Path: 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 562E7120813 for ; Wed, 12 Feb 2020 08:56:56 -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=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 cnyDovYN-2PT for ; Wed, 12 Feb 2020 08:56:52 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 B808D120289 for ; Wed, 12 Feb 2020 08:56:51 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id q8so3156279ljb.2 for ; Wed, 12 Feb 2020 08:56:51 -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=LT5gJLkRls2O6sZSIQWmbBBO09STMLG6TZ8VY8tZM+k=; b=LLe2ZHfoPpYwNxBNnloj1hEBaxWUgG6iXJHg5nHRr9NB9KBNJPti6ALV2W4HZaPZ6z 82Ao4v3ihibTO3lSwT5+YlZr/oeLzMWwr+Mxe4SRTReRWCplvN/b3mrJmYknykwsE1aW egutKRpLQRrogUkrkFGxw5p47sGIQSxbY2VkwLD0KS2OFV1KKrJWEH/4pSsFxKiV8FFF SryUZkLvMzuDMsy9BmoBBpzujOq0nPlplkPZfwcKWobKj64y71smDhE5bWmgZb5MYS3H Xgb7Jr1wpQRicVlGZcCarclxBXIGDAfwQAyuW+/4FpiOm/3A+qcTgfuzCgLDpmIw73oI H+CA== 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=LT5gJLkRls2O6sZSIQWmbBBO09STMLG6TZ8VY8tZM+k=; b=bp1YYg4PYkaA8h1Ix7dtfLTapwXe+6cG6MRQdAef+VKUehIKcDjbbFCOL602pakxvV Lsgli/DLklxh6kuki+pawQSloIN5zD46bIYZ9QxZC5rtnz1ObA005gaViqQCHBKEfG5E Cl2qQDpW0mf6PXMo4waGzrfs95K+nPYP08VCrwlqQzPmnwj6VxhWods6YgbCUYaaVTq2 u8pFrsJ8H2kpPotG0r+WHAEBjkotHbLZhRvQzwiaCvklzbOW5YkDA7ak2RCXsf2a7E6i dgzcr9vi/KLAhw6o7iB168x4JyiFuC5z9wJqKjIbkxXHsYOTPeDAeGZK8+6rOSneXcHI ai7g== X-Gm-Message-State: APjAAAVmfM4pT0aHSbdYkic6VYOuXFUV41qnAcfWkCTx+3Kih62GOq7b jN5VMVR+LoS1M/KLzF3A8gYiUwYj/h1xhLnoW1UOQQ== X-Google-Smtp-Source: APXvYqwtoPR2U2qmXPOi4v2Jrx3NM9HZWMovb3VPjC9K/r7shwI+tJoVexnF4j72SZR3801W4kJuOqYsRHUOg6quskQ= X-Received: by 2002:a2e:b0c4:: with SMTP id g4mr8427286ljl.83.1581526609823; Wed, 12 Feb 2020 08:56:49 -0800 (PST) MIME-Version: 1.0 References: <2ECF370B-F30B-4B0E-AAE7-0FF75F340802@kuehlewind.net> <78EDC63C-F8FE-466E-AA3A-A086A90127A8@kuehlewind.net> <84F34F5C-DFD6-42F6-9B12-BD10F2B37DB5@kuehlewind.net> In-Reply-To: From: Eric Rescorla Date: Wed, 12 Feb 2020 08:56:13 -0800 Message-ID: To: Mirja Kuehlewind Cc: Magnus Westerlund , webtrans-chairs@ietf.org, WebTransport , The IESG , David Schinazi , Victor Vasiliev , Barry Leiba Content-Type: multipart/alternative; boundary="000000000000c83810059e63dbd6" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 16:56:57 -0000 --000000000000c83810059e63dbd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think there is anything new to say here, other than that I am not in favor of these changes to the charter, which I believe would be unwise. -Ekr On Wed, Feb 12, 2020 at 7:29 AM Mirja Kuehlewind wrote: > Yes, that is a decision by the IESG so we should not baked it into the > WebTransport charter at this point of time. What I=E2=80=99m requesting i= s to > rather remove the following sentence from the proposed new charter text: > > "The WebTransport working group may define extensions to these protocols, > but any working group last call defining such extensions shall also be se= nt > to the mailing list of the respective working group.=E2=80=9D > > And then the following sentence should probably also be change to remove > the word =E2=80=9Ccore=E2=80=9D or even replace =E2=80=9Cchanges to these= core protocols=E2=80=9D with > =E2=80=9Cextension to the respective protocols=E2=80=9D: > > "In particular, any changes to these core protocols shall be discussed in > their respective working groups.=E2=80=9D > > I think it is actually true for all three protocols (QUIC, HTTP, and TLS) > that changes to the _core_ protocol must be done in the respectively > working group. > > Mirja > > > > > On 12. Feb 2020, at 16:21, Eric Rescorla wrote: > > > > Well, I don't really agree that this needs to be a live issue, but as > you insist: > > Extensions to QUIC should be possible in WGs across the IETF, with > proper coordination with the QUIC WG. This isn't really a decision for th= e > QUIC WG, but rather for the IESG, In any case, this is precisely what is > contemplated by the current draft. If you think this needs to go in some > charter text, then it should go there now. > > > > -Ekr > > > > > > On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind > wrote: > > > > > > > On 12. Feb 2020, at 16:13, Eric Rescorla wrote: > > > > > > > > > > > > On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind > wrote: > > > The whole point is that the QUIC protocol is not finished yet and the > respective registry doesn=E2=80=99t exists yet. > > > > > > And WebTransport will have a normative dependency on QUIC and > therefore will not be finished prior to that registry existing. > > > > But the charter will be finished before that and we need to decide now > what to write in there. That=E2=80=99s what we are discussing. > > > > > > > > > > > All I=E2=80=99m saying that we should not bake process in the the web= transport > charter that might restrict a future discuss we want to have in the QUIC > group. > > > > > > What future discussion? As I said, the IANA considerations implicit > decide this matter. Is someone arguing to change those to Standards Track= ? > > > > As Magnus wrote several times in the resented re-chartering discussion: > > > > "A reason for the two step rechartering is that I think we will need to > have a > > serious discussion of how to work on v2 and extensions more generally. = I > think > > going into these details now is premature. But we will need to come bac= k > to this > > later.=E2=80=9D > > > > Mirja > > > > > > > > > > > > -Ekr > > > > > > > > > > > > > On 12. Feb 2020, at 15:26, Barry Leiba > wrote: > > > > > > > > I have to agree with EKR here: I'm not aware of any other protocols > > > > that define Specification Required extension mechanisms where we sa= y > > > > 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 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=E2=80=99m saying that the process how and where to define Q= UIC > 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 wh= en > some WG wants to define a TLS extension there's a brief discussion betwee= n > 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=E2=80=99t mean that in future it will not be pos= sible for > other groups to define extension but we need to have that discussion firs= t. > > > >>> > > > >>> Mirja > > > >>> > > > >>> > > > >>> > > > >>>> On 11. Feb 2020, at 22:34, Eric Rescorla wrote: > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3=BChlewind (IETF)" < > ietf@kuehlewind.net> wrote: > > > >>>> Hi David, > > > >>>> > > > >>>> I didn=E2=80=99t say that other groups cannot define extension. = I did say > that it=E2=80=99s the decision of the working group that maintains the pr= otocol how > to handle that and for Quic we didn=E2=80=99t have had that discussion ye= t. > > > >>>> > > > >>>> 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=E2=80=99t define a= nything > 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>: > > > >>>>> > > > >>>>> =EF=BB=BF > > > >>>>> 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=E2=80=99m 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=E2=80= =99t 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 canno= t > 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= =E2=80=A6? > > > >>>>> > > > >>>>> 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 wrote: > > > >>>>>> Magnus Westerlund has entered the following ballot position fo= r > > > >>>>>> 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 th= e > 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 worksho= p > on game > > > >>>>>> communication where this was discussed and raised in some > discussions. > > > >>>>>> > > > >>>>>> It's a WICG draft, which basically means no formal status.. W= e > 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 a= s > 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 mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > --000000000000c83810059e63dbd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think there is anything new to say here, = other than that I am not in favor of these changes to the charter, which I = believe would be unwise.

-Ekr

=

= On Wed, Feb 12, 2020 at 7:29 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
Yes, that is a decision by the IESG so = we should not baked it into the WebTransport charter at this point of time.= What I=E2=80=99m requesting is to rather remove the following sentence fro= m the proposed new charter text:

"The WebTransport working group may define extensions to these protoco= ls, but any working group last call defining such extensions shall also be = sent to the mailing list of the respective working group.=E2=80=9D

And then the following sentence should probably also be change to remove th= e word =E2=80=9Ccore=E2=80=9D or even replace =E2=80=9Cchanges to these cor= e protocols=E2=80=9D with =E2=80=9Cextension to the respective protocols=E2= =80=9D:

"In particular, any changes to these core protocols shall be discussed= in their respective working groups.=E2=80=9D

I think it is actually true for all three protocols (QUIC, HTTP, and TLS) t= hat changes to the _core_ protocol must be done in the respectively working= group.

Mirja



> On 12. Feb 2020, at 16:21, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Well, I don't really agree that this needs to be a live issue, but= as you insist:
> Extensions to QUIC should be possible in WGs across the IETF, with pro= per coordination with the QUIC WG. This isn't really a decision for the= QUIC WG, but rather for the IESG, In any case, this is precisely what is c= ontemplated by the current draft. If you think this needs to go in some cha= rter text, then it should go there now.
>
> -Ekr
>
>
> On Wed, Feb 12, 2020 at 7:17 AM Mirja Kuehlewind <ietf@kuehlewind.net> wrote:<= br> >
>
> > On 12. Feb 2020, at 16:13, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Wed, Feb 12, 2020 at 6:40 AM Mirja Kuehlewind <ietf@kuehlewind.net> wr= ote:
> > The whole point is that the QUIC protocol is not finished yet and= the respective registry doesn=E2=80=99t exists yet.
> >
> > And WebTransport will have a normative dependency on QUIC and the= refore will not be finished prior to that registry existing.
>
> But the charter will be finished before that and we need to decide now= what to write in there. That=E2=80=99s what we are discussing.
>
> >
> >
> > All I=E2=80=99m 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.
> >
> > What future discussion? As I said, the IANA considerations implic= it decide this matter. Is someone arguing to change those to Standards Trac= k?
>
> As Magnus wrote several times in the resented re-chartering discussion= :
>
> "A reason for the two step rechartering is that I think we will n= eed to have a
> serious discussion of how to work on v2 and extensions more generally.= I think
> going into these details now is premature. But we will need to come ba= ck to this
> later.=E2=80=9D
>
> Mirja
>
>
>
> >
> > -Ekr
> >
> >
> >
> > > 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 othe= r protocols
> > > that define Specification Required extension mechanisms wher= e we say
> > > that the original working group should be in control of the<= br> > > > extensions.=C2=A0 I wouldn't want to start it here.
> > >
> > > The ADs will designate experts to review the extension speci= fications,
> > > and that is the mechanism for the working group to have its = say in the
> > > extensions.=C2=A0 And in this case, the charter explicitly s= ays that
> > > webtrans will coordinate with quic.=C2=A0 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 de= cide to pushing an RFC then we need to decide where this work in the IETF c= an 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&= #39;t be any process other than asking the QUIC WG?
> > >>
> > >>
> > >>>
> > >>> All I=E2=80=99m saying that the process how and wher= e to define QUIC extensions in the IETF needs to be decided by the QUIC gro= up and a future QUIC charter and not by the charter of any other working gr= oup.
> > >>
> > >>
> > >> I don't understand what process you think requires t= his. 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 en= ough to do separately. It's not in the TLS charter, for instance, AFAIC= T.
> > >>
> > >> -Ekr
> > >>
> > >>> Again that doesn=E2=80=99t mean that in future it wi= ll 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:<= br> > > >>>>
> > >>>>
> > >>>>
> > >>>> On Tue, Feb 11, 2020 at 1:31 PM "Mirja K=C3= =BChlewind (IETF)" <ietf@kuehlewind.net> wrote:
> > >>>> Hi David,
> > >>>>
> > >>>> I didn=E2=80=99t say that other groups cannot de= fine extension. I did say that it=E2=80=99s the decision of the working gro= up that maintains the protocol how to handle that and for Quic we didn=E2= =80=99t have had that discussion yet.
> > >>>>
> > >>>> Examples for groups that explicitly define proce= ss 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=E2=80= =99t 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:
> > >>>>
> > >>>> ht= tps://tools.ietf.org/html/draft-ietf-quic-transport-25#section-22.1.4 > > >>>>
> > >>>> Most of the code points are assigned via Specifi= cation 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 Schinaz= i <dschina= zi.ietf@gmail.com>:
> > >>>>>
> > >>>>> =EF=BB=BF
> > >>>>> Hi Mirja,
> > >>>>>
> > >>>>> I'm not sure I agree with your interpret= ation.. The fact that a WG is
> > >>>>> responsible for a protocol does not mean tha= t other working groups
> > >>>>> cannot write extensions to that protocol. > > >>>>>
> > >>>>> For example, the QUIC WG is defining the qui= c_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 t= hat was not
> > >>>>> defined in the TCPM WG. The list goes on. > > >>>>>
> > >>>>> We don't yet have examples for QUIC as t= he 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 Kuehle= wind <ietf@kueh= lewind.net> wrote:
> > >>>>> Hi David,
> > >>>>>
> > >>>>> One more comment below.
> > >>>>>
> > >>>>>> On 6. Feb 2020, at 14:46, David Schinazi= <dschinaz= i.ietf@gmail.com> wrote:
> > >>>>>>
> > >>>>>> Hi Magnus,
> > >>>>>>
> > >>>>>> I realized that some of our earlier repl= ies 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 en= sure we benefit
> > >>>>>> from their security and congestion contr= ol 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 p= rotocols would
> > >>>>>> happen in their existing respective work= ing groups..
> > >>>>>> However, discussion of extensions to the= se protocols could
> > >>>>>> be allowed in this WG, as long as any do= cument WGLC is
> > >>>>>> also sent to the mailing list responsibl= e 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 currentl= y 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 oth= er protocols/groups in this charter is not appropriate. I=E2=80=99m not sur= e 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 ex= tension or modification are out of scope for this group. Of course that doe= sn=E2=80=99t mean that this group cannot talk about any extension but as so= on as the group thinks an extension is needed, it needs to go to the QUIC g= roup and cannot just adapt anything within WebTransport.
> > >>>>>
> > >>>>> Please also double-check what the right proc= ess is for TLS and HTTP. I assume for TLS it's the same but for HTTP it= might be different=E2=80=A6?
> > >>>>>
> > >>>>> Mirja
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Would that be an acceptable scope?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> David
> > >>>>>>
> > >>>>>> On Tue, Feb 4, 2020 at 11:07 AM Victor V= asiliev <vasilvv= @google.com> wrote:
> > >>>>>> I believe most of those have been addres= sed 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 W= esterlund via Datatracker <noreply@ietf..org> wrote:
> > >>>>>> Magnus Westerlund has entered the follow= ing 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 C= C lines. (Feel free to cut this
> > >>>>>> introductory paragraph, however.)
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> The document, along with other ballot po= sitions, can be found here:
> > >>>>>> https://da= tatracker.ietf.org/doc/charter-ietf-webtrans/
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> ----------------------------------------= ------------------------------
> > >>>>>> BLOCK:
> > >>>>>> ----------------------------------------= ------------------------------
> > >>>>>>
> > >>>>>>
> > >>>>>> [snip]
> > >>>>>>
> > >>>>>> The group will also coordinate with rela= ted working groups within the IETF,
> > >>>>>> such as QUIC and HTTPBIS, as appropriate= .
> > >>>>>>
> > >>>>>> With the current state of QUIC developem= ent 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 am= ong the proposed WG documents, some of
> > >>>>>> the drafts do extend HTTP using custom S= ETTINGS parameters (which is the
> > >>>>>> intended HTTP extensibility mechanism).= =C2=A0 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 wo= rking group itself.
> > >>>>>>
> > >>>>>> ----------------------------------------= ------------------------------
> > >>>>>> COMMENT:
> > >>>>>> ----------------------------------------= ------------------------------
> > >>>>>>
> > >>>>>> I also would appreciate if someone can c= larify what stage of formality the
> > >>>>>> Web-Transport API has been adopted in W3= C and is being worked on. Trying to
> > >>>>>> find anything about which group it belon= gs to on the W3C page didn't give me
> > >>>>>> any information. All I found is that the= re have been a workshop on game
> > >>>>>> communication where this was discussed a= nd raised in some discussions.
> > >>>>>>
> > >>>>>> It's a WICG draft, which basically m= eans no formal status..=C2=A0 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 understa= nding is that the editors of the W3C
> > >>>>>> spec currently do not believe we have en= ough 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 bod= ies 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.=C2=A0 = My plan was that the -overview doc would
> > >>>>>> list all of the protocol requirements an= d API expectations, acting as
> > >>>>>> integration point between W3C and IETF s= pecs.
> > >>>>>>
> > >>>>>> The current API draft does not include a= ny 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=C2=A0 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, f= or 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 u= se the undefined APIs to HTTP/3 and
> > >>>>>> QUIC to influence those protocol to perf= orm stream priorities..
> > >>>>>>
> > >>>>>> This is mostly a gap in the API spec.=C2= =A0 I've been meaning to write this up
> > >>>>>> further, but there's a lot of text t= o 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 indi= cates to the transport layer for the
> > >>>>>>=C2=A0 =C2=A0 purpose of scheduling write= s.
> > >>>>>> (2) Priorities that are communicated to = the peer on the wire as a hint....
> > >>>>>>
> > >>>>>> Most of the discussion in HTTPBIS and QU= IC WGs was about #2.=C2=A0 I don't believe
> > >>>>>> any of the proposed drafts cover that to= pic, and I'd rather wait for
> > >>>>>> quic/httpbis to come up with a mechanism= first.
> > >>>>>>
> > >>>>>> The priorities mentioned in -overview ar= e of the #1 kind.=C2=A0 Section 2.3 of
> > >>>>>> draft-ietf-quic-transport-25 explicitly = encourages implementations (that would
> > >>>>>> include the proposed Web APIs) to provid= e those:
> > >>>>>>
> > >>>>>> """
> > >>>>>> [QUIC] relies on receiving priority info= rmation from the application that uses
> > >>>>>> QUIC.
> > >>>>>>
> > >>>>>> A QUIC implementation SHOULD provide way= s in which an application can indicate
> > >>>>>> the relative priority of streams. When d= eciding which streams to dedicate
> > >>>>>> resources to, the implementation SHOULD = use the information provided by the
> > >>>>>> application.
> > >>>>>> """
> > >>>>>>
> > >>>>>> Besides, I don't believe we can avoi= d defining a write scheduling mechanism in
> > >>>>>> the API.=C2=A0 QUIC itself treats it as = an implementation detail, but Web APIs
> > >>>>>> generally try really hard to avoid imple= mentation-defined behavior.=C2=A0 If
> > >>>>>> every browser had a completely different= write scheduling approach,
> > >>>>>> that could make the job of writing perfo= rmant cross-browser code really
> > >>>>>> difficult.
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>>=C2=A0 Victor.
> > >>>>>> --
> > >>>>>> Webtransport mailing list
> > >>>>>> Webtransport@ietf.org
> > >>>>>> https://www.iet= f.org/mailman/listinfo/webtransport
> > >>>>>
> > >>>> --
> > >>>> Webtransport mailing list
> > >>>> Webtransport@ietf.org
> > >>>> https://www.ietf.org/ma= ilman/listinfo/webtransport
> > >>>
> > >
> > >
> >
>
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--000000000000c83810059e63dbd6-- From nobody Thu Feb 13 08:22:30 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 976FB12016E; Thu, 13 Feb 2020 08:22:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: webtransport@ietf.org, webtrans-chairs@ietf.org, webtransport@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <158161094358.20528.563737434555848558.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2020 08:22:23 -0800 Archived-At: Subject: [Webtransport] Magnus Westerlund's No Objection on charter-ietf-webtrans-00-01: (with COMMENT) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 16:22:24 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-webtrans-00-01: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks, this new charter do address the blocking points I have. The coordination with the API development still is unclear on this level. I do understand the challenge to be clear on it. So just leaving this as a comment. From nobody Thu Feb 13 10:51:53 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CA81201AA; Thu, 13 Feb 2020 10:51:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avezza@amsl.com, webtrans-chairs@ietf.org, webtransport@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158161991154.20597.10962463485995069167.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2020 10:51:51 -0800 Archived-At: Subject: [Webtransport] webtrans - New Meeting Session Request for IETF 107 X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 18:51:52 -0000 A new meeting session request has just been submitted by Amy K. Vezza, on behalf of the webtrans working group. --------------------------------------------------------- Working Group Name: WebTransport Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: core dnssd httpbis quic taps tls tsvarea avtcore mmusic emu People who must be present: Dr. Bernard D. Aboba Ph.D. Barry Leiba David Schinazi Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 14 07:20:10 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF9112018D; Fri, 14 Feb 2020 07:20:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Cc: webtransport@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2020 07:20:04 -0800 Archived-At: Subject: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 15:20:05 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. WebTransport (webtrans) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Bernard Aboba David Schinazi Assigned Area Director: Barry Leiba Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: webtransport@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/webtransport Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ Group page: https://datatracker.ietf.org/group/webtrans/ Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ Description of Working Group The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport API https://wicg.github.io/web-transport. The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of reliable messages. Attention will be paid to the performance of the protocol, with particular attention to the protocol’s overhead and the potential for head-of-line blocking; its ability to be deployed and used reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new transport protocols but will instead use existing protocols such as QUIC and TLS/TCP. The group will pay attention to security issues arising from the above scenarios so as to protect against creation of new modes of attack. To assist in the coordination with owners of the WebTransport API, the group will initially develop an overview document containing use cases and requirements in order to clarify the goals of the effort. The requirements will include those arising from the WebTransport API. Feedback will also be solicited at various points along the way in order to ensure the best possible match between the protocol extensions and the needs of the WebTransport API. The group will also coordinate with related working groups within the IETF, such as QUIC and HTTPBIS, as appropriate. In particular, if the working group needs any changes to or extensions of the core protocols, those issues will be raised with the relevant working groups for decisions on how best to handle them. If those decisions result in work in WebTrans, the working group last calls for that work will again be sent to the relevant working groups. Milestones: Mar 2020 - Adopt a WebTransport Overview draft as a WG work item Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG work item Oct 2020 - Issue WG last call of the WebTransport Overview document. Jan 2021 - Issue WG last call on the first WebTransport protocol document From nobody Fri Feb 14 09:21:37 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11A12091B; Fri, 14 Feb 2020 09:21:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158170089456.16251.8544267255422592973.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2020 09:21:34 -0800 From: IETF Secretariat Archived-At: Subject: [Webtransport] Datatracker State Update Notice: X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 17:21:35 -0000 State changed to External Review (Message to Community, Selected by Secretariat). Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ From nobody Fri Feb 14 09:21:57 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BECF1208F8; Fri, 14 Feb 2020 09:21:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158170091250.16139.14591593446706197154.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2020 09:21:52 -0800 From: IETF Secretariat Archived-At: Subject: [Webtransport] Telechat update notice: X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 17:21:52 -0000 Telechat date has been changed to 2020-03-05 from 2020-02-06 Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ From nobody Fri Feb 14 12:16:03 2020 Return-Path: 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 B7425120B6C; Fri, 14 Feb 2020 12:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 S90cwuHT7S-C; Fri, 14 Feb 2020 12:15:11 -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 86113120A99; Fri, 14 Feb 2020 12:15:05 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id w1so12073453ljh.5; Fri, 14 Feb 2020 12:15:05 -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=xpVj6JduPcpthIO6jMlnqVrljm2ZiUFLOUEcl0uACpo=; b=DzaHOlu2No6K3mq6xYXqy+VVBLNCDK2sjRcIS2zK5G855FfBj6s0FtZso6n8h01snB fflG6NXmYyoNl2ZB+XcSXW4+MCJ1NpSuPFk6WIpizH84j8pdFpCpkeZ9rqsD1Vqt1e+u R0IoHuWym8NbghLDaiWH/sAfB77NnxuJBZ9l9gXrQbS+NC4em+XzKbRtxBC47TEx9E4s 9WKeRJw1ORPqp8X4/L+8qazLSlPjQmXvMS8J5DKmwWamwzQEnD3VibHlOVau9l1fzRSH xSteiK3S7Bk37FCwA5WrVLDoaHGmNequWmmwdjc9xO+p4YLllvIi5MOElT6GkksZM+JG /+tw== 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=xpVj6JduPcpthIO6jMlnqVrljm2ZiUFLOUEcl0uACpo=; b=teO70HFY+QlN3gIFMD9VM2E1qegjOqm5a/s1lHeT6XBlmy8QBBaCKZPfVt5paQwxyd u1dezBp70PUkHRDk/7z/VqBZnJkw845WpoImQMFi28DqXPtLP1I1OPswSWknNIdosl+U 5800yXVeaKxvEFIqPAXBtr30SUzGMYoa81NRWMfbZH9jl1mcx/BmotG4Gvb6V4mDe0EO PpZTVaSMUXmqcm0xkVcXAGiqqRO16uC+5zRjq2jz8fy+ccRxHLaBzazi0lFMZbVWy7s3 D/4ZvSeCxNNCVusSK20x9i4QAtRwKvQvMAbBUYJSm7X9V+hgABKuBcIwhZEAh9g9N+Si j7/w== X-Gm-Message-State: APjAAAVfiI3Z/yCSTZmtIALZjdLoTQV7HLggHE9jjEE9YYe/8Vi/4E75 Aehc1Qy/wcN61IJfK/gMxlbX1GBi55hn7LZjTZ1bUsnL X-Google-Smtp-Source: APXvYqyQNdGZHLKyHtaNp1MMU9mMjXUfJJjS+sygbPAL/FFVCRB8PFoIXl0AmPcW6dsdAQzYusZ6oZCuXnXzhobmdlQ= X-Received: by 2002:a2e:9c85:: with SMTP id x5mr3164936lji.50.1581711303484; Fri, 14 Feb 2020 12:15:03 -0800 (PST) MIME-Version: 1.0 References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> In-Reply-To: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> From: Spencer Dawkins at IETF Date: Fri, 14 Feb 2020 14:14:37 -0600 Message-ID: To: IESG Cc: webtransport@ietf.org Content-Type: multipart/alternative; boundary="00000000000061a7d4059e8edc3d" Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 20:15:21 -0000 --00000000000061a7d4059e8edc3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As usual, I'm reading this, and not just looking at the words (as previously). Most of it looks fine, except for the part where I fell off the edge of the cliff. On Fri, Feb 14, 2020 at 9:20 AM The IESG wrote: > A new IETF WG has been proposed in the Applications and Real-Time Area. T= he > IESG has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your > comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. > > WebTransport (webtrans) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > Bernard Aboba > David Schinazi > > Assigned Area Director: > Barry Leiba > > Applications and Real-Time Area Directors: > Adam Roach > Alexey Melnikov > Barry Leiba > > Mailing list: > Address: webtransport@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/webtransport > Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ > > Group page: https://datatracker.ietf.org/group/webtrans/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ > > Description of Working Group > > The WebTransport working group will define new client-server protocols or > protocol extensions in order to support the development of the WebTranspo= rt > API https://wicg.github.io/web-transport. > > The WebTransport working group will define an application-layer protocol > or suite of application-layer protocols that support a range of simple > communication methods. These must include unreliable messages (that might > be limited by the path MTU), reliable messages, and ordered streams of > reliable messages. Attention will be paid to the performance of the > protocol, with particular attention to the protocol=E2=80=99s overhead an= d the > potential for head-of-line blocking; its ability to be deployed and used > Speaking of "head of line blocking" ... > reliably under different network conditions; and its ability to integrate > into the Web security model. The working group will not define new > transport protocols but will instead use existing protocols such as QUIC > and TLS/TCP. > Is the intention here to allow applications using WebTransport to do something like what applications using HTTP/3-QUIC do today, and failover to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited? If "Yes", that might be said more clearly. If "No" - how badly does the world need WebTransport for TLS/TCP? I ask this especially because the charter raises head of line blocking as a consideration - as it should, in 2020 - but TLS/TCP hasn't changed about that since QUIC was chartered in 2016, with avoiding TCP head of line blocking as a key goal. So listing QUIC and TLS/TCP as apparently equally legit existing protocols seems odd. Could someone clue me in about this? Best, Spencer, who is also curious about possible coordination between WebTransport and TAPS, but let's ignore that for now. The group will pay attention to security issues arising from the above > scenarios so as to protect against creation of new modes of attack. > > To assist in the coordination with owners of the WebTransport API, the > group will initially develop an overview document containing use cases > and requirements in order to clarify the goals of the effort. The > requirements will include those arising from the WebTransport API. > Feedback will also be solicited at various points along the way in order > to ensure the best possible match between the protocol extensions and the > needs of the WebTransport API. > > The group will also coordinate with related working groups within the IET= F, > such as QUIC and HTTPBIS, as appropriate. In particular, if the working > group needs any changes to or extensions of the core protocols, those > issues will be raised with the relevant working groups for decisions on h= ow > best to handle them. If those decisions result in work in WebTrans, the > working group last calls for that work will again be sent to the relevant > working groups. > > Milestones: > > Mar 2020 - Adopt a WebTransport Overview draft as a WG work item > > Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG work > item > > Oct 2020 - Issue WG last call of the WebTransport Overview document. > > Jan 2021 - Issue WG last call on the first WebTransport protocol docume= nt > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --00000000000061a7d4059e8edc3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As usual, I'm reading this, and not just looking = at the words (as previously).

Most of it looks fin= e, except for the part where I fell off the edge of the cliff.

On Fri, Feb 1= 4, 2020 at 9:20 AM The IESG <= iesg-secretary@ietf.org> wrote:
A new IETF WG has been proposed in the Applications = and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send you= r
comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24.

WebTransport (webtrans)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
=C2=A0 Bernard Aboba <bernard.aboba@gmail.com>
=C2=A0 David Schinazi <dschinazi.ietf@gmail.com>

Assigned Area Director:
=C2=A0 Barry Leiba <barryleiba@computer.org>

Applications and Real-Time Area Directors:
=C2=A0 Adam Roach <adam@nostrum.com>
=C2=A0 Alexey Melnikov <aamelnikov@fastmail.fm>
=C2=A0 Barry Leiba <barryleiba@computer.org>

Mailing list:
=C2=A0 Address: = webtransport@ietf.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/= listinfo/webtransport
=C2=A0 Archive: https://mailarchive.ietf.org/a= rch/browse/webtransport/

Group page: https://datatracker.ietf.org/group/webtrans/=

Charter: https://datatracker.ietf.org/doc/cha= rter-ietf-webtrans/

Description of Working Group

The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport=
API https://wicg.github.io/web-transport.

The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple
communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of
reliable messages. Attention will be paid to the performance of the
protocol, with particular attention to the protocol=E2=80=99s overhead and = the
potential for head-of-line blocking; its ability to be deployed and used

Speaking of "head of line blocking&q= uot; ...=C2=A0
=C2=A0
reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new
transport protocols but will instead use existing protocols such as QUIC and TLS/TCP.

=C2=A0Is the intention her= e to allow applications using WebTransport to do something like what applic= ations using HTTP/3-QUIC do today, and failover to HTTP/2-TLS-TCP if QUIC i= s blocked or significantly rate-limited?

If "= Yes", that might be said more clearly.=C2=A0

= If "No" - how badly does the world need WebTransport for TLS/TCP?=

I ask this especially because the charter raises = head of line blocking as a consideration - as it should, in 2020 - but TLS/= TCP hasn't changed about that since QUIC was chartered in 2016, with av= oiding TCP head of line blocking as a key goal. So listing QUIC and TLS/TCP= as apparently equally legit existing protocols seems odd.

Could someone clue me in about this?

Best= ,

Spencer, who is also curious about possible coor= dination between WebTransport and TAPS, but let's ignore that for now.= =C2=A0

IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--00000000000061a7d4059e8edc3d-- From nobody Fri Feb 14 12:51:02 2020 Return-Path: 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 215091201DE; Fri, 14 Feb 2020 12:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5j107viUXp-q; Fri, 14 Feb 2020 12:50:50 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 9E7BF1201DC; Fri, 14 Feb 2020 12:50:49 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id b15so7646755lfc.4; Fri, 14 Feb 2020 12:50:49 -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=bp68WLX1lxTCcCNxzyE5lB5pwxJiLn2vXn/kKEYRKto=; b=lFQzaAChMngzVZJYkO/T6GM4q0LoAfTA6wiWXdeJfyYM7AYQLgawgri+eQNWFvPNzz /trL5rw+j1cJzkovhRmU4znY7rY4xAyd9KUhqObRM5TjLf8CUmMOadSNpziM6/CCO7Dp c1f8DxYqz79xHtYcljK/kj7GAJoY6Es2tE4ZDZ+0ZUbmjyXf1LfhZLe4FITTqFcFMAa9 d+Xm872pPEus9TJmEXNvEYMwZ1H3fkaOrOvy42R/LDgiaXWz5IZ1Jeml5DPbm7iTBa+a sbyiEfD7lfk/WRBMJsVeaQfNG8rZza3lYXnNBCgFzmOgC9zEU2rnlWpJP/jjhd3dwntm JOrA== 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=bp68WLX1lxTCcCNxzyE5lB5pwxJiLn2vXn/kKEYRKto=; b=LHmdLRavo77RoUAjHChSXTwwF3MVU+XyFWpDIp+rj9jHTJTv/+aNdFZI9IhlWkO+FB 4GsHnvJWFejrWDTrJUxI0GabgDXsn1kz3K0iQocSRjVSjbALPtlhwBJGNi4xH3shG9k+ 7ZctSkLf/KF5x638PXdYyZEQal3xJ5L4hUa4RtMovZ4YvDC/xobcpPfYk2M1GYxB5IvR PMl0JF9hXQL0+j4bkqkQGhVcyig6+k7NuDbVNv7kG5I0RBFW5v6H7SS7U3IdkkerYaa0 cJ3meb827DsQcnCMgyyxTdRG0gHdwHCFGeY3X9hie1AB9rggirdRO3nfBxVSnEw/gJEP lNYg== X-Gm-Message-State: APjAAAVidmhwgv0fuwWs4P9ltI4UL1WkzWTw2Pe2Km7BFrWsLqd1KXoE 825Q1iexoun1cRUbQrYpO/embWunDe7ucsQWUhb1sw== X-Google-Smtp-Source: APXvYqzQFwzRyrC1WEStFOKIzR2ZeaOHIS85y2VJGMReihXtT16QfCkVuP3muodXXNXClL0fyjXGwB9fT46wc7jfnLE= X-Received: by 2002:ac2:53b3:: with SMTP id j19mr2571357lfh.127.1581713447835; Fri, 14 Feb 2020 12:50:47 -0800 (PST) MIME-Version: 1.0 References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Fri, 14 Feb 2020 12:50:36 -0800 Message-ID: To: Spencer Dawkins at IETF Cc: IESG , WebTransport Content-Type: multipart/alternative; boundary="00000000000031dc96059e8f5ce7" Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 20:50:57 -0000 --00000000000031dc96059e8f5ce7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Spencer, The main goal is for WebTransport to use QUIC and benefit from QUIC features such as reduced head-of-line blocking. However, on networks where QUIC is blocked, the WG will most likely define a fallback version over TLS/TCP. That version will obviously not see QUIC features. I think this fits into the proposed charter, as it requires paying attention to these concerns. We explicitly chose not to specify which exact protocols WebTransport will be built on in the charter, because we have not reached consensus on that yet, and this will be discussed in the newly formed WG. Thanks, David On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > As usual, I'm reading this, and not just looking at the words (as > previously). > > Most of it looks fine, except for the part where I fell off the edge of > the cliff. > > On Fri, Feb 14, 2020 at 9:20 AM The IESG wrote: > >> A new IETF WG has been proposed in the Applications and Real-Time Area. >> The >> IESG has not made any determination yet. The following draft charter was >> submitted, and is provided for informational purposes only. Please send >> your >> comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. >> >> WebTransport (webtrans) >> ----------------------------------------------------------------------- >> Current status: Proposed WG >> >> Chairs: >> Bernard Aboba >> David Schinazi >> >> Assigned Area Director: >> Barry Leiba >> >> Applications and Real-Time Area Directors: >> Adam Roach >> Alexey Melnikov >> Barry Leiba >> >> Mailing list: >> Address: webtransport@ietf.org >> To subscribe: https://www.ietf.org/mailman/listinfo/webtransport >> Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ >> >> Group page: https://datatracker.ietf.org/group/webtrans/ >> >> Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >> >> Description of Working Group >> >> The WebTransport working group will define new client-server protocols o= r >> protocol extensions in order to support the development of the >> WebTransport >> API https://wicg.github.io/web-transport. >> >> The WebTransport working group will define an application-layer protocol >> or suite of application-layer protocols that support a range of simple >> communication methods. These must include unreliable messages (that migh= t >> be limited by the path MTU), reliable messages, and ordered streams of >> reliable messages. Attention will be paid to the performance of the >> protocol, with particular attention to the protocol=E2=80=99s overhead a= nd the >> potential for head-of-line blocking; its ability to be deployed and used >> > > Speaking of "head of line blocking" ... > > >> reliably under different network conditions; and its ability to integrat= e >> into the Web security model. The working group will not define new >> transport protocols but will instead use existing protocols such as QUIC >> and TLS/TCP. >> > > Is the intention here to allow applications using WebTransport to do > something like what applications using HTTP/3-QUIC do today, and failover > to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited? > > If "Yes", that might be said more clearly. > > If "No" - how badly does the world need WebTransport for TLS/TCP? > > I ask this especially because the charter raises head of line blocking as > a consideration - as it should, in 2020 - but TLS/TCP hasn't changed abou= t > that since QUIC was chartered in 2016, with avoiding TCP head of line > blocking as a key goal. So listing QUIC and TLS/TCP as apparently equally > legit existing protocols seems odd. > > Could someone clue me in about this? > > Best, > > Spencer, who is also curious about possible coordination between > WebTransport and TAPS, but let's ignore that for now. > > The group will pay attention to security issues arising from the above >> scenarios so as to protect against creation of new modes of attack. >> >> To assist in the coordination with owners of the WebTransport API, the >> group will initially develop an overview document containing use cases >> and requirements in order to clarify the goals of the effort. The >> requirements will include those arising from the WebTransport API. >> Feedback will also be solicited at various points along the way in order >> to ensure the best possible match between the protocol extensions and th= e >> needs of the WebTransport API. >> >> The group will also coordinate with related working groups within the >> IETF, >> such as QUIC and HTTPBIS, as appropriate. In particular, if the working >> group needs any changes to or extensions of the core protocols, those >> issues will be raised with the relevant working groups for decisions on >> how >> best to handle them. If those decisions result in work in WebTrans, the >> working group last calls for that work will again be sent to the relevan= t >> working groups. >> >> Milestones: >> >> Mar 2020 - Adopt a WebTransport Overview draft as a WG work item >> >> Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG work >> item >> >> Oct 2020 - Issue WG last call of the WebTransport Overview document. >> >> Jan 2021 - Issue WG last call on the first WebTransport protocol >> document >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --00000000000031dc96059e8f5ce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Spencer,

The main goal is for WebTra= nsport to use QUIC and benefit
from QUIC features such as reduced= head-of-line blocking.
However, on networks where QUIC is blocke= d, the WG will
most likely define a fallback version over TLS/TCP= . That
version will obviously not see QUIC features. I think this= fits
into the proposed charter, as it requires paying attention = to
these concerns.

We explicitly chose n= ot to specify which exact protocols
WebTransport will be built on= in the charter, because we
have not reached consensus on that ye= t, and this will be
discussed in the newly formed WG.
<= br>
Thanks,
David

On Fri, Feb 14, 2020 at 12:15 PM= Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
As usual, I'm re= ading this, and not just looking at the words (as previously).
Most of it looks fine, except for the part where I fell off th= e edge of the cliff.

On Fri, Feb 14, 2020 at 9:20 AM The IESG <iesg-secretary@ietf.org<= /a>> wrote:
A= new IETF WG has been proposed in the Applications and Real-Time Area. The<= br> IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send you= r
comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24.

WebTransport (webtrans)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
=C2=A0 Bernard Aboba <bernard.aboba@gmail.com>
=C2=A0 David Schinazi <dschinazi.ietf@gmail.com>

Assigned Area Director:
=C2=A0 Barry Leiba <barryleiba@computer.org>

Applications and Real-Time Area Directors:
=C2=A0 Adam Roach <adam@nostrum.com>
=C2=A0 Alexey Melnikov <aamelnikov@fastmail.fm>
=C2=A0 Barry Leiba <barryleiba@computer.org>

Mailing list:
=C2=A0 Address: = webtransport@ietf.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/= listinfo/webtransport
=C2=A0 Archive: https://mailarchive.ietf.org/a= rch/browse/webtransport/

Group page: https://datatracker.ietf.org/group/webtrans/=

Charter: https://datatracker.ietf.org/doc/cha= rter-ietf-webtrans/

Description of Working Group

The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport=
API https://wicg.github.io/web-transport.

The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple
communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of
reliable messages. Attention will be paid to the performance of the
protocol, with particular attention to the protocol=E2=80=99s overhead and = the
potential for head-of-line blocking; its ability to be deployed and used

Speaking of "head of line blocking&q= uot; ...=C2=A0
=C2=A0
reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new
transport protocols but will instead use existing protocols such as QUIC and TLS/TCP.

=C2=A0Is the intention her= e to allow applications using WebTransport to do something like what applic= ations using HTTP/3-QUIC do today, and failover to HTTP/2-TLS-TCP if QUIC i= s blocked or significantly rate-limited?

If "= Yes", that might be said more clearly.=C2=A0

= If "No" - how badly does the world need WebTransport for TLS/TCP?=

I ask this especially because the charter raises = head of line blocking as a consideration - as it should, in 2020 - but TLS/= TCP hasn't changed about that since QUIC was chartered in 2016, with av= oiding TCP head of line blocking as a key goal. So listing QUIC and TLS/TCP= as apparently equally legit existing protocols seems odd.

Could someone clue me in about this?

Best= ,

Spencer, who is also curious about possible coor= dination between WebTransport and TAPS, but let's ignore that for now.= =C2=A0

IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--00000000000031dc96059e8f5ce7-- From nobody Fri Feb 14 15:42:31 2020 Return-Path: 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 7E70F12006F; Fri, 14 Feb 2020 15:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vM9I-Wgu-7kh; Fri, 14 Feb 2020 15:42:12 -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 64F42120013; Fri, 14 Feb 2020 15:42:11 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id q8so12486529ljj.11; Fri, 14 Feb 2020 15:42:11 -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=kvMJoqMg6poV8WvcZJw9Rord2BCsH2hr2Fat1tAZ5NI=; b=ehO4WhjDwKRaet3i4oTq2ieuVAq5dugNtc1Vs49eDpjty4/qL5H5fFGIWLiTiK9hym 8r2mZDr+ZlXZu73p4obRC1flwaVTWJlwc4UfFYfU8lYaboZDZHq2oQ6bvU8TkM8gFRmr SQBW54/hFdupAP11whW8LwLBFxFLwqH62lSnqwyidMVymOt/NpxheTSqccBIMIR5eOOp CkaH5St6cQRktTM/2HOFd93hRCORaTzRTj+L/qe7vxbjriNGJRD6LceemCQeS9Y21re/ ygA+Kx6PN4eEKDVJ/ggd8R4efpRuB6yMO9K6PRu04rrrpQ5qBcyn/QjLzv0SfraYXhtF 2Rsw== 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=kvMJoqMg6poV8WvcZJw9Rord2BCsH2hr2Fat1tAZ5NI=; b=OY02sycQ4LBUQ04UF62oDNnbQDh7FgPVxfADgogCpfNUPinOj+GX9H39ax8/paVyM8 QoMu4kXVjwnb3gf+ueXUG/0an0NlLO2ySrQZ0hOWxdU2LllYSH9xHBUxF3e7ATYHRGbt J+lpM871XAXDX+dtDCi/6nE2AmUi3uX7p2VB07dymWx+K55sNVfMCKA/i7Wk9Qkd8oGY fpky3JqxYsPygvtSt5i2l0NqU/LSJXMm1Q+8QjNJaO3LKckbKSextv5v4wr7B8WCAFxx l63h6dtvKYk9FC6K8uhiDNTDzgpAzPcNARXt9uLr96LM2tQbe2YVidTpHkBvuAn52V4i iRNw== X-Gm-Message-State: APjAAAWy7HSRBwwPN96kAhDm8m6vfF6u2FZnS9tboHMxiXAhI6Jojf1U 4HwN30MnEA8m83phvsPwM7dH0bW1tFCJkaLAepo= X-Google-Smtp-Source: APXvYqz3nnchszPvEuxZ4TbgkLApH5U+wuqVt0DmpWZTDfePk0wadTX0MmGbokZklo4ao4cE4hliNRxIAXTUSmexEtE= X-Received: by 2002:a2e:b5b4:: with SMTP id f20mr3550461ljn.112.1581723728749; Fri, 14 Feb 2020 15:42:08 -0800 (PST) MIME-Version: 1.0 References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 14 Feb 2020 17:41:42 -0600 Message-ID: To: David Schinazi Cc: IESG , WebTransport Content-Type: multipart/alternative; boundary="000000000000fc2966059e91c0f1" Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 23:42:21 -0000 --000000000000fc2966059e91c0f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, David, On Fri, Feb 14, 2020 at 2:50 PM David Schinazi wrote: > Hi Spencer, > > The main goal is for WebTransport to use QUIC and benefit > from QUIC features such as reduced head-of-line blocking. > However, on networks where QUIC is blocked, the WG will > most likely define a fallback version over TLS/TCP. That > version will obviously not see QUIC features. I think this fits > into the proposed charter, as it requires paying attention to > these concerns. > > We explicitly chose not to specify which exact protocols > WebTransport will be built on in the charter, because we > have not reached consensus on that yet, and this will be > discussed in the newly formed WG. > That's all fine, but I'd suggest dropping QUIC and TLS/TCP as examples, if you're deferring the decision to the working group. Just saying "The working group will not define new transport protocols but will instead use existing protocols." would have avoided my confusion. Best, and enjoy your working group. Spencer > Thanks, > David > > On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> As usual, I'm reading this, and not just looking at the words (as >> previously). >> >> Most of it looks fine, except for the part where I fell off the edge of >> the cliff. >> >> On Fri, Feb 14, 2020 at 9:20 AM The IESG wrote= : >> >>> A new IETF WG has been proposed in the Applications and Real-Time Area. >>> The >>> IESG has not made any determination yet. The following draft charter wa= s >>> submitted, and is provided for informational purposes only. Please send >>> your >>> comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. >>> >>> WebTransport (webtrans) >>> ----------------------------------------------------------------------- >>> Current status: Proposed WG >>> >>> Chairs: >>> Bernard Aboba >>> David Schinazi >>> >>> Assigned Area Director: >>> Barry Leiba >>> >>> Applications and Real-Time Area Directors: >>> Adam Roach >>> Alexey Melnikov >>> Barry Leiba >>> >>> Mailing list: >>> Address: webtransport@ietf.org >>> To subscribe: https://www.ietf.org/mailman/listinfo/webtransport >>> Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ >>> >>> Group page: https://datatracker.ietf.org/group/webtrans/ >>> >>> Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >>> >>> Description of Working Group >>> >>> The WebTransport working group will define new client-server protocols = or >>> protocol extensions in order to support the development of the >>> WebTransport >>> API https://wicg.github.io/web-transport. >>> >>> The WebTransport working group will define an application-layer protoco= l >>> or suite of application-layer protocols that support a range of simple >>> communication methods. These must include unreliable messages (that mig= ht >>> be limited by the path MTU), reliable messages, and ordered streams of >>> reliable messages. Attention will be paid to the performance of the >>> protocol, with particular attention to the protocol=E2=80=99s overhead = and the >>> potential for head-of-line blocking; its ability to be deployed and use= d >>> >> >> Speaking of "head of line blocking" ... >> >> >>> reliably under different network conditions; and its ability to integra= te >>> into the Web security model. The working group will not define new >>> transport protocols but will instead use existing protocols such as QUI= C >>> and TLS/TCP. >>> >> >> Is the intention here to allow applications using WebTransport to do >> something like what applications using HTTP/3-QUIC do today, and failove= r >> to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited? >> >> If "Yes", that might be said more clearly. >> >> If "No" - how badly does the world need WebTransport for TLS/TCP? >> >> I ask this especially because the charter raises head of line blocking a= s >> a consideration - as it should, in 2020 - but TLS/TCP hasn't changed abo= ut >> that since QUIC was chartered in 2016, with avoiding TCP head of line >> blocking as a key goal. So listing QUIC and TLS/TCP as apparently equall= y >> legit existing protocols seems odd. >> >> Could someone clue me in about this? >> >> Best, >> >> Spencer, who is also curious about possible coordination between >> WebTransport and TAPS, but let's ignore that for now. >> >> The group will pay attention to security issues arising from the above >>> scenarios so as to protect against creation of new modes of attack. >>> >>> To assist in the coordination with owners of the WebTransport API, the >>> group will initially develop an overview document containing use cases >>> and requirements in order to clarify the goals of the effort. The >>> requirements will include those arising from the WebTransport API. >>> Feedback will also be solicited at various points along the way in orde= r >>> to ensure the best possible match between the protocol extensions and t= he >>> needs of the WebTransport API. >>> >>> The group will also coordinate with related working groups within the >>> IETF, >>> such as QUIC and HTTPBIS, as appropriate. In particular, if the workin= g >>> group needs any changes to or extensions of the core protocols, those >>> issues will be raised with the relevant working groups for decisions on >>> how >>> best to handle them. If those decisions result in work in WebTrans, th= e >>> working group last calls for that work will again be sent to the releva= nt >>> working groups. >>> >>> Milestones: >>> >>> Mar 2020 - Adopt a WebTransport Overview draft as a WG work item >>> >>> Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG wor= k >>> item >>> >>> Oct 2020 - Issue WG last call of the WebTransport Overview document. >>> >>> Jan 2021 - Issue WG last call on the first WebTransport protocol >>> document >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> >> -- >> Webtransport mailing list >> Webtransport@ietf.org >> https://www.ietf.org/mailman/listinfo/webtransport >> > --000000000000fc2966059e91c0f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,=C2=A0

=
On Fri, Feb 14, 2020 at 2:50 PM David= Schinazi <dschinazi.ietf@gm= ail.com> wrote:
Hi Spencer,

The main goal is for= WebTransport to use QUIC and benefit
from QUIC features such as = reduced head-of-line blocking.
However, on networks where QUIC is= blocked, the WG will
most likely define a fallback version over = TLS/TCP. That
version will obviously not see QUIC features. I thi= nk this fits
into the proposed charter, as it requires paying att= ention to
these concerns.

We explicitly = chose not to specify which exact protocols
WebTransport will be b= uilt on in the charter, because we
have not reached consensus on = that yet, and this will be
discussed in the newly formed WG.

That's all fine, but I'd su= ggest dropping QUIC and TLS/TCP as examples, if you're deferring the de= cision to the working group. Just saying "The working group will not d= efine new
transport protocols but will instead use existing protocols.= " would have avoided my confusion.
Best, and enjoy your working group.
=

Spencer
=
=C2=A0
Thanks,
David

On Fri, Feb 14, 2020 at 12:1= 5 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
As usual, I'm reading this, and not just looking at the words (as prev= iously).

Most of it looks fine, except for the par= t where I fell off the edge of the cliff.

On Fri, Feb 14, 2020 at 9:20 AM Th= e IESG <ies= g-secretary@ietf.org> wrote:
A new IETF WG has been proposed in the Applications and= Real-Time Area. The
IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send you= r
comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24.

WebTransport (webtrans)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
=C2=A0 Bernard Aboba <bernard.aboba@gmail.com>
=C2=A0 David Schinazi <dschinazi.ietf@gmail.com>

Assigned Area Director:
=C2=A0 Barry Leiba <barryleiba@computer.org>

Applications and Real-Time Area Directors:
=C2=A0 Adam Roach <adam@nostrum.com>
=C2=A0 Alexey Melnikov <aamelnikov@fastmail.fm>
=C2=A0 Barry Leiba <barryleiba@computer.org>

Mailing list:
=C2=A0 Address: = webtransport@ietf.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/= listinfo/webtransport
=C2=A0 Archive: https://mailarchive.ietf.org/a= rch/browse/webtransport/

Group page: https://datatracker.ietf.org/group/webtrans/=

Charter: https://datatracker.ietf.org/doc/cha= rter-ietf-webtrans/

Description of Working Group

The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport=
API https://wicg.github.io/web-transport.

The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple
communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of
reliable messages. Attention will be paid to the performance of the
protocol, with particular attention to the protocol=E2=80=99s overhead and = the
potential for head-of-line blocking; its ability to be deployed and used

Speaking of "head of line blocking&q= uot; ...=C2=A0
=C2=A0
reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new
transport protocols but will instead use existing protocols such as QUIC and TLS/TCP.

=C2=A0Is the intention her= e to allow applications using WebTransport to do something like what applic= ations using HTTP/3-QUIC do today, and failover to HTTP/2-TLS-TCP if QUIC i= s blocked or significantly rate-limited?

If "= Yes", that might be said more clearly.=C2=A0

= If "No" - how badly does the world need WebTransport for TLS/TCP?=

I ask this especially because the charter raises = head of line blocking as a consideration - as it should, in 2020 - but TLS/= TCP hasn't changed about that since QUIC was chartered in 2016, with av= oiding TCP head of line blocking as a key goal. So listing QUIC and TLS/TCP= as apparently equally legit existing protocols seems odd.

Could someone clue me in about this?

Best= ,

Spencer, who is also curious about possible coor= dination between WebTransport and TAPS, but let's ignore that for now.= =C2=A0

IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000fc2966059e91c0f1-- From nobody Fri Feb 14 15:54:51 2020 Return-Path: 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 035381201CE; Fri, 14 Feb 2020 15:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hHYOu6rDicJC; Fri, 14 Feb 2020 15:54:46 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 3408412002E; Fri, 14 Feb 2020 15:54:46 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id v201so7858296lfa.11; Fri, 14 Feb 2020 15:54:45 -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=0Q6vgZnLxrV+5pmpobVjSXVgY2GDwXh6d8YBYFMRwPg=; b=j2OsExGipRzfgrFuZDEKM6FY8W2nwz9sECiurAo6G2WGnRrBnVKwso/NSo2eKNEA/L RFnCJ9l5SirqAadE7cE1BXDTQgPMC5RL8llhcg2IsxbBNP06pjUByR3dtKX5rJUb9Mdr yfT2s4lgoO1HPJx9A7EyF5+pBH0lznrKrCCo8vt7OHLDqE8eA6WzGpRHjz/vowC/hcC5 ZmYuKuGkT1lQWZMJDUxahh+RaaYJ8/syKjZDF+5kJKmDALjIZtUCeBs+R//+zdYQuUUg nD8tPKYawd47Gj8YDcODuxBXDx3xbTauyImimGZwReI1FCsQJKkVZb2lUoPhJa/Qn5Gc XQiQ== 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=0Q6vgZnLxrV+5pmpobVjSXVgY2GDwXh6d8YBYFMRwPg=; b=Ft3ksb/DyMYx+KYFETAIV400yRQwhvTZeYtFvDyoGcbloppk/5sVR05dQ+wpVLAuEg 3k2NTDjE5dQjplapKXm2cJU9qWcapSbsUfoM7wf2g76f2FQm+Su+YaRT5rEKzyxZ89+D lNpqjf0uRxeCz8Cm9p434jCKDbUWXx8mkxBKQxiA71BNceOeFI+WjUGVeNn5WdOAhXpd wgpn5y405t/ThGEG35ZXnoXsKQ/Yzv6TVf64fpKYajzONt0erIGHJEU5HvpUTqujv6Ry UrE7oDwukC1VFxpZp0EwolPL0kG1xZlURV32EdjQ3UNfYBtF9M0C95JngKfpHkyI5QIu NwiA== X-Gm-Message-State: APjAAAVdsOLWmM6CmkUpodtodHPtc0SzqAsTI5FMteYDgssS1GlijGYb A+VOkxp/osaRvZ/rGWKbAAXbLTmz30vA+kXz5t3cjw== X-Google-Smtp-Source: APXvYqzdj9hU8Yw/l0yZwBVJeCGC2mINHwlTUQ/D72i+SGLPg6OU4HmZnJWAAZcsM2Kc3Ykf9Voj8ETFn+0Q1qTHUx0= X-Received: by 2002:ac2:5979:: with SMTP id h25mr2911634lfp.203.1581724484036; Fri, 14 Feb 2020 15:54:44 -0800 (PST) MIME-Version: 1.0 References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> In-Reply-To: From: David Schinazi Date: Fri, 14 Feb 2020 15:54:33 -0800 Message-ID: To: Spencer Dawkins at IETF Cc: IESG , WebTransport Content-Type: multipart/alternative; boundary="00000000000000ebc4059e91eef1" Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 23:54:50 -0000 --00000000000000ebc4059e91eef1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Spencer! We added those specific protocols at the request of the transport ADs, so I think we'll leave them in for now if that's OK. David On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, David, > > On Fri, Feb 14, 2020 at 2:50 PM David Schinazi > wrote: > >> Hi Spencer, >> >> The main goal is for WebTransport to use QUIC and benefit >> from QUIC features such as reduced head-of-line blocking. >> However, on networks where QUIC is blocked, the WG will >> most likely define a fallback version over TLS/TCP. That >> version will obviously not see QUIC features. I think this fits >> into the proposed charter, as it requires paying attention to >> these concerns. >> >> We explicitly chose not to specify which exact protocols >> WebTransport will be built on in the charter, because we >> have not reached consensus on that yet, and this will be >> discussed in the newly formed WG. >> > > That's all fine, but I'd suggest dropping QUIC and TLS/TCP as examples, i= f > you're deferring the decision to the working group. Just saying "The > working group will not define new > transport protocols but will instead use existing protocols." would have > avoided my confusion. > > Best, and enjoy your working group. > > Spencer > > >> Thanks, >> David >> >> On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF < >> spencerdawkins.ietf@gmail.com> wrote: >> >>> As usual, I'm reading this, and not just looking at the words (as >>> previously). >>> >>> Most of it looks fine, except for the part where I fell off the edge of >>> the cliff. >>> >>> On Fri, Feb 14, 2020 at 9:20 AM The IESG >>> wrote: >>> >>>> A new IETF WG has been proposed in the Applications and Real-Time Area= . >>>> The >>>> IESG has not made any determination yet. The following draft charter w= as >>>> submitted, and is provided for informational purposes only. Please sen= d >>>> your >>>> comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. >>>> >>>> WebTransport (webtrans) >>>> ----------------------------------------------------------------------= - >>>> Current status: Proposed WG >>>> >>>> Chairs: >>>> Bernard Aboba >>>> David Schinazi >>>> >>>> Assigned Area Director: >>>> Barry Leiba >>>> >>>> Applications and Real-Time Area Directors: >>>> Adam Roach >>>> Alexey Melnikov >>>> Barry Leiba >>>> >>>> Mailing list: >>>> Address: webtransport@ietf.org >>>> To subscribe: https://www.ietf.org/mailman/listinfo/webtransport >>>> Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ >>>> >>>> Group page: https://datatracker.ietf.org/group/webtrans/ >>>> >>>> Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >>>> >>>> Description of Working Group >>>> >>>> The WebTransport working group will define new client-server protocols >>>> or >>>> protocol extensions in order to support the development of the >>>> WebTransport >>>> API https://wicg.github.io/web-transport. >>>> >>>> The WebTransport working group will define an application-layer protoc= ol >>>> or suite of application-layer protocols that support a range of simple >>>> communication methods. These must include unreliable messages (that >>>> might >>>> be limited by the path MTU), reliable messages, and ordered streams of >>>> reliable messages. Attention will be paid to the performance of the >>>> protocol, with particular attention to the protocol=E2=80=99s overhead= and the >>>> potential for head-of-line blocking; its ability to be deployed and us= ed >>>> >>> >>> Speaking of "head of line blocking" ... >>> >>> >>>> reliably under different network conditions; and its ability to >>>> integrate >>>> into the Web security model. The working group will not define new >>>> transport protocols but will instead use existing protocols such as QU= IC >>>> and TLS/TCP. >>>> >>> >>> Is the intention here to allow applications using WebTransport to do >>> something like what applications using HTTP/3-QUIC do today, and failov= er >>> to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited? >>> >>> If "Yes", that might be said more clearly. >>> >>> If "No" - how badly does the world need WebTransport for TLS/TCP? >>> >>> I ask this especially because the charter raises head of line blocking >>> as a consideration - as it should, in 2020 - but TLS/TCP hasn't changed >>> about that since QUIC was chartered in 2016, with avoiding TCP head of = line >>> blocking as a key goal. So listing QUIC and TLS/TCP as apparently equal= ly >>> legit existing protocols seems odd. >>> >>> Could someone clue me in about this? >>> >>> Best, >>> >>> Spencer, who is also curious about possible coordination between >>> WebTransport and TAPS, but let's ignore that for now. >>> >>> The group will pay attention to security issues arising from the above >>>> scenarios so as to protect against creation of new modes of attack. >>>> >>>> To assist in the coordination with owners of the WebTransport API, the >>>> group will initially develop an overview document containing use cases >>>> and requirements in order to clarify the goals of the effort. The >>>> requirements will include those arising from the WebTransport API. >>>> Feedback will also be solicited at various points along the way in ord= er >>>> to ensure the best possible match between the protocol extensions and >>>> the >>>> needs of the WebTransport API. >>>> >>>> The group will also coordinate with related working groups within the >>>> IETF, >>>> such as QUIC and HTTPBIS, as appropriate. In particular, if the worki= ng >>>> group needs any changes to or extensions of the core protocols, those >>>> issues will be raised with the relevant working groups for decisions o= n >>>> how >>>> best to handle them. If those decisions result in work in WebTrans, t= he >>>> working group last calls for that work will again be sent to the >>>> relevant >>>> working groups. >>>> >>>> Milestones: >>>> >>>> Mar 2020 - Adopt a WebTransport Overview draft as a WG work item >>>> >>>> Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG >>>> work item >>>> >>>> Oct 2020 - Issue WG last call of the WebTransport Overview document. >>>> >>>> Jan 2021 - Issue WG last call on the first WebTransport protocol >>>> document >>>> >>>> >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>> >>> -- >>> Webtransport mailing list >>> Webtransport@ietf.org >>> https://www.ietf.org/mailman/listinfo/webtransport >>> >> --00000000000000ebc4059e91eef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Spencer! We added those specific p= rotocols
at the request of the transport ADs, so I think=C2=A0we'll=
leave them in for now if that's OK.

David

On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com= > wrote:
=
Hi, David,=C2=A0

=
On Fri, Feb 14, 2020 at 2:50 PM David= Schinazi <dschinazi.ietf@gmail.com> wrote:
Hi Spencer,

Th= e main goal is for WebTransport to use QUIC and benefit
from QUIC= features such as reduced head-of-line blocking.
However, on netw= orks where QUIC is blocked, the WG will
most likely define a fall= back version over TLS/TCP. That
version will obviously not see QU= IC features. I think this fits
into the proposed charter, as it r= equires paying attention to
these concerns.

<= div>We explicitly chose not to specify which exact protocols
WebT= ransport will be built on in the charter, because we
have not rea= ched consensus on that yet, and this will be
discussed in the new= ly formed WG.

That's all fi= ne, but I'd suggest dropping QUIC and TLS/TCP as examples, if you'r= e deferring the decision to the working group. Just saying "The workin= g group will not define new
transport protocols but will instead use e= xisting protocols." would have avoided my confusion.

Best, and enjoy your = working group.

Spencer
=C2=A0
Thanks,
David
On Fri, = Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">
As usual, I'm reading this, and not just looking a= t the words (as previously).

Most of it looks fine= , except for the part where I fell off the edge of the cliff.

On Fri, Feb 14= , 2020 at 9:20 AM The IESG <iesg-secretary@ietf.org> wrote:
A new IETF WG has been proposed in = the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send you= r
comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24.

WebTransport (webtrans)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
=C2=A0 Bernard Aboba <bernard.aboba@gmail.com>
=C2=A0 David Schinazi <dschinazi.ietf@gmail.com>

Assigned Area Director:
=C2=A0 Barry Leiba <barryleiba@computer.org>

Applications and Real-Time Area Directors:
=C2=A0 Adam Roach <adam@nostrum.com>
=C2=A0 Alexey Melnikov <aamelnikov@fastmail.fm>
=C2=A0 Barry Leiba <barryleiba@computer.org>

Mailing list:
=C2=A0 Address: = webtransport@ietf.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/= listinfo/webtransport
=C2=A0 Archive: https://mailarchive.ietf.org/a= rch/browse/webtransport/

Group page: https://datatracker.ietf.org/group/webtrans/=

Charter: https://datatracker.ietf.org/doc/cha= rter-ietf-webtrans/

Description of Working Group

The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport=
API https://wicg.github.io/web-transport.

The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple
communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of
reliable messages. Attention will be paid to the performance of the
protocol, with particular attention to the protocol=E2=80=99s overhead and = the
potential for head-of-line blocking; its ability to be deployed and used

Speaking of "head of line blocking&q= uot; ...=C2=A0
=C2=A0
reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new
transport protocols but will instead use existing protocols such as QUIC and TLS/TCP.

=C2=A0Is the intention her= e to allow applications using WebTransport to do something like what applic= ations using HTTP/3-QUIC do today, and failover to HTTP/2-TLS-TCP if QUIC i= s blocked or significantly rate-limited?

If "= Yes", that might be said more clearly.=C2=A0

= If "No" - how badly does the world need WebTransport for TLS/TCP?=

I ask this especially because the charter raises = head of line blocking as a consideration - as it should, in 2020 - but TLS/= TCP hasn't changed about that since QUIC was chartered in 2016, with av= oiding TCP head of line blocking as a key goal. So listing QUIC and TLS/TCP= as apparently equally legit existing protocols seems odd.

Could someone clue me in about this?

Best= ,

Spencer, who is also curious about possible coor= dination between WebTransport and TAPS, but let's ignore that for now.= =C2=A0

IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--00000000000000ebc4059e91eef1-- From nobody Fri Feb 14 15:57:37 2020 Return-Path: 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 3103D1201DC; Fri, 14 Feb 2020 15:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 gcXrS0umJJTj; Fri, 14 Feb 2020 15:57:28 -0800 (PST) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 1225612002E; Fri, 14 Feb 2020 15:57:28 -0800 (PST) Received: by mail-lj1-x234.google.com with SMTP id x7so12572842ljc.1; Fri, 14 Feb 2020 15:57:27 -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=j22WbRlxYD3vWT0bpE2+bdivh9BD+sBcSIEO+hAuIgU=; b=BVAkU86Sey6rmolf4ACI7MH5gDtUA7EtGvUG6SuxlzlU+TcsrGuCdk+/ukuA73r4ZR SlGw6qbKxcrPaL0Oev8Ba+M7T8os5+vRkx16eodOUqd2icy0CeMt/8KCz+m7k/eogqpA VDPdoyKTFQEo7nc8Ai3hbaKhT0ETafsv65e0/JB3uaZ9kOPzuc7Zk84xy+SS0om0/soJ W1pwGUxwgtvLY6z7S/s42pXssqAwpB404t+gKNpti+qHlne+X3w8trzcSjSplzBnl643 9lqcblDuyH4O09a7q92ObjIiJ0J6A19HWl+CebbCQ8SY962uKJrBPdezM45PG7GkvqWn jmWg== 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=j22WbRlxYD3vWT0bpE2+bdivh9BD+sBcSIEO+hAuIgU=; b=t8WrH9mFEp4EiFgatEJge3circ/1cdL9AQq4L71rJoeA3ompBsNsPCdk75RJSqVhFb HLGXjlZKkJoV/miqKEk1bHKAt5iLax5u1Kxm4J5gy/yiAkkQtEPshNBsdG6J0U9l3+KO Fb9i+wX8faJjn7DKPtb70owcJnnIIK6ttSnLeY3eVzG9bpAdrquLFTBv33VotdD3yeFt BtkXvw4LB+vW8sKHbfFnRKrcia32JgrJL6HXuF3WkZajKGsJdFF9fatWML2mbsa91WEU AeXCrXUXfPh+vj/8dkg3k0hoCd0f0TxflAZib09kRhHhx5GJZxKyhtBvQUVOKekfsgb+ DgHw== X-Gm-Message-State: APjAAAU0wiGswhB2cgcyP+jtl3nePAyKneeFU6woe7Arv4lwQ+n5nas9 jRC5aJ490EhRn2LY69LEi+FfC0TZGE+hO8bCWKNSrrPv X-Google-Smtp-Source: APXvYqzPgefQt+DOOqb4nJHEp2QqRqRbGZMG0ASbCKpDK03AUoP9zL4qYn5kM6NZadIoKySZsS5QUmSQjjQNKXaErvQ= X-Received: by 2002:a2e:300e:: with SMTP id w14mr3495392ljw.222.1581724646173; Fri, 14 Feb 2020 15:57:26 -0800 (PST) MIME-Version: 1.0 References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Fri, 14 Feb 2020 17:57:00 -0600 Message-ID: To: David Schinazi Cc: IESG , WebTransport Content-Type: multipart/alternative; boundary="000000000000aaf0fb059e91f78c" Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 23:57:32 -0000 --000000000000aaf0fb059e91f78c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, David, On Fri, Feb 14, 2020 at 5:54 PM David Schinazi wrote: > Thanks Spencer! We added those specific protocols > at the request of the transport ADs, so I think we'll > leave them in for now if that's OK. > Of course. Do the right thing :-) Best, Spencer > David > > On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> Hi, David, >> >> On Fri, Feb 14, 2020 at 2:50 PM David Schinazi >> wrote: >> >>> Hi Spencer, >>> >>> The main goal is for WebTransport to use QUIC and benefit >>> from QUIC features such as reduced head-of-line blocking. >>> However, on networks where QUIC is blocked, the WG will >>> most likely define a fallback version over TLS/TCP. That >>> version will obviously not see QUIC features. I think this fits >>> into the proposed charter, as it requires paying attention to >>> these concerns. >>> >>> We explicitly chose not to specify which exact protocols >>> WebTransport will be built on in the charter, because we >>> have not reached consensus on that yet, and this will be >>> discussed in the newly formed WG. >>> >> >> That's all fine, but I'd suggest dropping QUIC and TLS/TCP as examples, >> if you're deferring the decision to the working group. Just saying "The >> working group will not define new >> transport protocols but will instead use existing protocols." would have >> avoided my confusion. >> >> Best, and enjoy your working group. >> >> Spencer >> >> >>> Thanks, >>> David >>> >>> On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF < >>> spencerdawkins.ietf@gmail.com> wrote: >>> >>>> As usual, I'm reading this, and not just looking at the words (as >>>> previously). >>>> >>>> Most of it looks fine, except for the part where I fell off the edge o= f >>>> the cliff. >>>> >>>> On Fri, Feb 14, 2020 at 9:20 AM The IESG >>>> wrote: >>>> >>>>> A new IETF WG has been proposed in the Applications and Real-Time >>>>> Area. The >>>>> IESG has not made any determination yet. The following draft charter >>>>> was >>>>> submitted, and is provided for informational purposes only. Please >>>>> send your >>>>> comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. >>>>> >>>>> WebTransport (webtrans) >>>>> ---------------------------------------------------------------------= -- >>>>> Current status: Proposed WG >>>>> >>>>> Chairs: >>>>> Bernard Aboba >>>>> David Schinazi >>>>> >>>>> Assigned Area Director: >>>>> Barry Leiba >>>>> >>>>> Applications and Real-Time Area Directors: >>>>> Adam Roach >>>>> Alexey Melnikov >>>>> Barry Leiba >>>>> >>>>> Mailing list: >>>>> Address: webtransport@ietf.org >>>>> To subscribe: https://www.ietf.org/mailman/listinfo/webtransport >>>>> Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ >>>>> >>>>> Group page: https://datatracker.ietf.org/group/webtrans/ >>>>> >>>>> Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >>>>> >>>>> Description of Working Group >>>>> >>>>> The WebTransport working group will define new client-server protocol= s >>>>> or >>>>> protocol extensions in order to support the development of the >>>>> WebTransport >>>>> API https://wicg.github.io/web-transport. >>>>> >>>>> The WebTransport working group will define an application-layer >>>>> protocol >>>>> or suite of application-layer protocols that support a range of simpl= e >>>>> communication methods. These must include unreliable messages (that >>>>> might >>>>> be limited by the path MTU), reliable messages, and ordered streams o= f >>>>> reliable messages. Attention will be paid to the performance of the >>>>> protocol, with particular attention to the protocol=E2=80=99s overhea= d and the >>>>> potential for head-of-line blocking; its ability to be deployed and >>>>> used >>>>> >>>> >>>> Speaking of "head of line blocking" ... >>>> >>>> >>>>> reliably under different network conditions; and its ability to >>>>> integrate >>>>> into the Web security model. The working group will not define new >>>>> transport protocols but will instead use existing protocols such as >>>>> QUIC >>>>> and TLS/TCP. >>>>> >>>> >>>> Is the intention here to allow applications using WebTransport to do >>>> something like what applications using HTTP/3-QUIC do today, and failo= ver >>>> to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited? >>>> >>>> If "Yes", that might be said more clearly. >>>> >>>> If "No" - how badly does the world need WebTransport for TLS/TCP? >>>> >>>> I ask this especially because the charter raises head of line blocking >>>> as a consideration - as it should, in 2020 - but TLS/TCP hasn't change= d >>>> about that since QUIC was chartered in 2016, with avoiding TCP head of= line >>>> blocking as a key goal. So listing QUIC and TLS/TCP as apparently equa= lly >>>> legit existing protocols seems odd. >>>> >>>> Could someone clue me in about this? >>>> >>>> Best, >>>> >>>> Spencer, who is also curious about possible coordination between >>>> WebTransport and TAPS, but let's ignore that for now. >>>> >>>> The group will pay attention to security issues arising from the above >>>>> scenarios so as to protect against creation of new modes of attack. >>>>> >>>>> To assist in the coordination with owners of the WebTransport API, th= e >>>>> group will initially develop an overview document containing use case= s >>>>> and requirements in order to clarify the goals of the effort. The >>>>> requirements will include those arising from the WebTransport API. >>>>> Feedback will also be solicited at various points along the way in >>>>> order >>>>> to ensure the best possible match between the protocol extensions and >>>>> the >>>>> needs of the WebTransport API. >>>>> >>>>> The group will also coordinate with related working groups within the >>>>> IETF, >>>>> such as QUIC and HTTPBIS, as appropriate. In particular, if the >>>>> working >>>>> group needs any changes to or extensions of the core protocols, those >>>>> issues will be raised with the relevant working groups for decisions >>>>> on how >>>>> best to handle them. If those decisions result in work in WebTrans, >>>>> the >>>>> working group last calls for that work will again be sent to the >>>>> relevant >>>>> working groups. >>>>> >>>>> Milestones: >>>>> >>>>> Mar 2020 - Adopt a WebTransport Overview draft as a WG work item >>>>> >>>>> Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG >>>>> work item >>>>> >>>>> Oct 2020 - Issue WG last call of the WebTransport Overview document= . >>>>> >>>>> Jan 2021 - Issue WG last call on the first WebTransport protocol >>>>> document >>>>> >>>>> >>>>> _______________________________________________ >>>>> IETF-Announce mailing list >>>>> IETF-Announce@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>> >>>> -- >>>> Webtransport mailing list >>>> Webtransport@ietf.org >>>> https://www.ietf.org/mailman/listinfo/webtransport >>>> >>> --000000000000aaf0fb059e91f78c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,=C2=A0

On Fri, Feb 14, 2020 at 5= :54 PM David Schinazi <dschi= nazi.ietf@gmail.com> wrote:
Thanks Spencer! We add= ed those specific protocols
at the request of the transport ADs, so I t= hink=C2=A0we'll
leave them in for now if that's OK.
=

Of course. Do the right thing = :-)

Best,

Spencer
=C2=A0
David

On Fri, Feb 14, 2020 at 3:42 = PM Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
H= i, David,=C2=A0

On Fri, Feb 14, 2020 at 2:50 PM David Schinazi <dschinazi.ietf@gmail= .com> wrote:
Hi Spencer,

The main goal is for We= bTransport to use QUIC and benefit
from QUIC features such as red= uced head-of-line blocking.
However, on networks where QUIC is bl= ocked, the WG will
most likely define a fallback version over TLS= /TCP. That
version will obviously not see QUIC features. I think = this fits
into the proposed charter, as it requires paying attent= ion to
these concerns.

We explicitly cho= se not to specify which exact protocols
WebTransport will be buil= t on in the charter, because we
have not reached consensus on tha= t yet, and this will be
discussed in the newly formed WG.

That's all fine, but I'd sugge= st dropping QUIC and TLS/TCP as examples, if you're deferring the decis= ion to the working group. Just saying "The working group will not defi= ne new
transport protocols but will instead use existing protocols.&qu= ot; would have avoided my confusion.

Best, and enjoy your working group.

Spencer
=C2=A0
Thanks,
David

On Fri, Feb 14, 2020 at 12:15 P= M Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
As= usual, I'm reading this, and not just looking at the words (as previou= sly).

Most of it looks fine, except for the part w= here I fell off the edge of the cliff.

=
On Fri, Feb 14, 2020 at 9:20 AM The I= ESG <iesg-s= ecretary@ietf.org> wrote:
A new IETF WG has been proposed in the Applications and Re= al-Time Area. The
IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send you= r
comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24.

WebTransport (webtrans)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
=C2=A0 Bernard Aboba <bernard.aboba@gmail.com>
=C2=A0 David Schinazi <dschinazi.ietf@gmail.com>

Assigned Area Director:
=C2=A0 Barry Leiba <barryleiba@computer.org>

Applications and Real-Time Area Directors:
=C2=A0 Adam Roach <adam@nostrum.com>
=C2=A0 Alexey Melnikov <aamelnikov@fastmail.fm>
=C2=A0 Barry Leiba <barryleiba@computer.org>

Mailing list:
=C2=A0 Address: = webtransport@ietf.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/= listinfo/webtransport
=C2=A0 Archive: https://mailarchive.ietf.org/a= rch/browse/webtransport/

Group page: https://datatracker.ietf.org/group/webtrans/=

Charter: https://datatracker.ietf.org/doc/cha= rter-ietf-webtrans/

Description of Working Group

The WebTransport working group will define new client-server protocols or protocol extensions in order to support the development of the WebTransport=
API https://wicg.github.io/web-transport.

The WebTransport working group will define an application-layer protocol or suite of application-layer protocols that support a range of simple
communication methods. These must include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of
reliable messages. Attention will be paid to the performance of the
protocol, with particular attention to the protocol=E2=80=99s overhead and = the
potential for head-of-line blocking; its ability to be deployed and used

Speaking of "head of line blocking&q= uot; ...=C2=A0
=C2=A0
reliably under different network conditions; and its ability to integrate into the Web security model. The working group will not define new
transport protocols but will instead use existing protocols such as QUIC and TLS/TCP.

=C2=A0Is the intention her= e to allow applications using WebTransport to do something like what applic= ations using HTTP/3-QUIC do today, and failover to HTTP/2-TLS-TCP if QUIC i= s blocked or significantly rate-limited?

If "= Yes", that might be said more clearly.=C2=A0

= If "No" - how badly does the world need WebTransport for TLS/TCP?=

I ask this especially because the charter raises = head of line blocking as a consideration - as it should, in 2020 - but TLS/= TCP hasn't changed about that since QUIC was chartered in 2016, with av= oiding TCP head of line blocking as a key goal. So listing QUIC and TLS/TCP= as apparently equally legit existing protocols seems odd.

Could someone clue me in about this?

Best= ,

Spencer, who is also curious about possible coor= dination between WebTransport and TAPS, but let's ignore that for now.= =C2=A0

IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--000000000000aaf0fb059e91f78c-- From nobody Mon Feb 17 18:30:38 2020 Return-Path: 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 E82C012004D; Mon, 17 Feb 2020 03:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 g1WdVCGSxEjJ; Mon, 17 Feb 2020 03:08:58 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2064.outbound.protection.outlook.com [40.107.22.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4375120046; Mon, 17 Feb 2020 03:08:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oZk5866hoXI1H5SreTThSwU8yjLV3G9xRyMlqrJTQndmC+dmXw1XWt60XEyd3hgp9LQykVKsGyXBcAHckwm4PUw1OX8w8kLD2kHUoEjxnpw4NtMVK0wmDlhm9LVn/Zj/hG08rhmrpi/5H9EX6ezWteKg55Fx5lhTkh94bPPRGHCFYCIdCGDIsi3qte203x5RtVwDWjAa0jJiQlhoo7yKDOW1Eef6RFcesitQhuLyN0+MjBJX/urCt2v9qOLa5INfmY9Guy6EcQ+limvI6Z7+KScj3u69k5yNfqGonWqsyHG71ZL8R3fj8bOJ1jVwOHyxbyCAd+zovcDw9Gwf261eXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FDSLCoPlKbzTIgWCFXdJux5nbA5xZo96s95O97z72d4=; b=htkYg8dqjUwBy7cMq4MG+9E/LndwUqogFLLahwEGaYAbcHK1GBW53+H2TWoKTkTTkn5tA9Z5uYE+WD/pqZRTirU/eXbnp+xsSlEXwRT/763Oi88FWOdDII8zy8TsP9FJcGxQyunDshM3HkEZyBCadpvaDjg0HPQUh0Dv4zbXDiTrO/qUFYDV2wbAN2RcMl64lSSc2K9ozIIpL8y0/OxHrostQinHPxS/F4O9+C9dLe91rohSHN3PYuGHDCCnGKSgpahxCsUwhuWWMOUz3fxTHYAhTTZ6XIqFiQ7xy98kqmCZuqrfRhHbtlSL5FaCqZO3QUy1VfQrQFiFMW9czPnbXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FDSLCoPlKbzTIgWCFXdJux5nbA5xZo96s95O97z72d4=; b=XPs7gtCiidig54J9PVfPmKr8BEzwMZUNQ1uXq6l3J7BFNnk+1OGCKKB9D2WljRieMXFl41CcjSWPT/k52300+TykFbuE11nSSXCjnkNyOPuv0+OnlH5gCTvt9vyE2ykrOxMVASDloDHALjhY+9JGEun5ZranL95GK1+biOwdTvs= Received: from DB7PR07MB4572.eurprd07.prod.outlook.com (52.135.133.12) by DB7PR07MB5178.eurprd07.prod.outlook.com (20.178.40.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.9; Mon, 17 Feb 2020 11:08:55 +0000 Received: from DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::5dc9:9b70:83a1:cbfd]) by DB7PR07MB4572.eurprd07.prod.outlook.com ([fe80::5dc9:9b70:83a1:cbfd%7]) with mapi id 15.20.2750.016; Mon, 17 Feb 2020 11:08:55 +0000 From: Magnus Westerlund To: "spencerdawkins.ietf@gmail.com" , "dschinazi.ietf@gmail.com" CC: "iesg@ietf.org" , "webtransport@ietf.org" Thread-Topic: [Webtransport] WG Review: WebTransport (webtrans) Thread-Index: AQHV40pR6FB0HEKOEUCPkHc/aTspaqgbIC2AgAAKDgCAAC/OAIAAA5eAgAAAsACAA+BjAA== Date: Mon, 17 Feb 2020 11:08:55 +0000 Message-ID: <6668892136bb171f55ebcc86a87418573315d4ba.camel@ericsson.com> References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.83] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7554c37-89cf-44cf-0043-08d7b399c778 x-ms-traffictypediagnostic: DB7PR07MB5178: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0316567485 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(366004)(396003)(376002)(199004)(189003)(53546011)(6506007)(2906002)(6512007)(478600001)(186003)(316002)(66616009)(110136005)(2616005)(76116006)(91956017)(44832011)(66946007)(86362001)(26005)(71200400001)(54906003)(66446008)(64756008)(966005)(8676002)(4326008)(36756003)(81156014)(81166006)(5660300002)(6486002)(66476007)(66556008)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5178; H:DB7PR07MB4572.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nvyrn44OIjp3tMNzLA5ic78OJDXxIJlVw9oDHmdzzYbCgQHbUE7/Et6jOZ/XYm9RfhFgGVdxigCqCbRUFA39DPu45s2Lir3dvtC9pDkgdXwuwarcpWX2nX1hDYiHg522DGgyRZBlr/lrv8wefCKQYUoVvVhjlwPKXC7Uqyf+Ne7NRZhI0CGtGvqpldprINXCalxbrzJkx9Yo6eOFLWZa2ayjYsDmd5OsSRS+a8us2T5PR02eBYojOUlzOL4jC52rFxh/YbeTGIO/AQU8wDYoAxmIo1aVvl3ubLkmrId7h7HnR8V0wu+gxFo0PL4LC7DoSMVTF88+QTkX8yEK6u7a6cBX6k07rfuIeP3TED87/qEWJ4X0OfgNrxwUQKSutNzeR9VDMPCnxnc0+IL5un8JIuLZcTgRLwaVhLUnAEiOubsb6MyJmBAn9F1LMGBxwjsE6b3KMKhhPsdJFovPTz1imJI1Yfe7Fvg31VSo55hPtpEjeGSegCbT2/itvDUn2Ikclwa9aBZDRfLNiCBNrvGEmA== x-ms-exchange-antispam-messagedata: uuMhF95UUhE5uRtCFL9QKF8Tv7+xKawZQMo3CCWN6kJYuJPwsrd2ey8KaAwY5Psp0YhhnHUahrC6lLhvLIk/BLghl4gMWRT/5sl5i4YSdN5FW1KzOTVmDrJCIt4eIS+OXcv+zA2tUxneFjnhOEgeUQ== x-ms-exchange-transport-forked: True Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-2ywqpO8f4S5nDiewreZy" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7554c37-89cf-44cf-0043-08d7b399c778 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Feb 2020 11:08:55.3173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PdGcc4aki4JcnrPVllgn3EwOhYTtzAFu7fjWNiD2xSEB98PNjeipRKAcVGBl3lZL/plzc8RzzOHuJVJmYReJ57IdPksMxhWW4WKVv3r0Q24= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5178 Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 11:09:02 -0000 --=-2ywqpO8f4S5nDiewreZy Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I am fine with dropping the specifics now that the charter is explicit abou= t using existing transport protocols. However, note that I am not considering= UDP as transprot protocol that WebTrans can just use.=20 Cheers Magnus On Fri, 2020-02-14 at 17:57 -0600, Spencer Dawkins at IETF wrote: > Hi, David,=20 >=20 > On Fri, Feb 14, 2020 at 5:54 PM David Schinazi > wrote: > > Thanks Spencer! We added those specific protocols > > at the request of the transport ADs, so I think we'll > > leave them in for now if that's OK. > >=20 >=20 > Of course. Do the right thing :-) >=20 > Best, >=20 > Spencer > =20 > > David > >=20 > > On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF < > > spencerdawkins.ietf@gmail.com> wrote: > > > Hi, David,=20 > > >=20 > > > On Fri, Feb 14, 2020 at 2:50 PM David Schinazi > > > wrote: > > > > Hi Spencer, > > > >=20 > > > > The main goal is for WebTransport to use QUIC and benefit > > > > from QUIC features such as reduced head-of-line blocking. > > > > However, on networks where QUIC is blocked, the WG will > > > > most likely define a fallback version over TLS/TCP. That > > > > version will obviously not see QUIC features. I think this fits > > > > into the proposed charter, as it requires paying attention to > > > > these concerns. > > > >=20 > > > > We explicitly chose not to specify which exact protocols > > > > WebTransport will be built on in the charter, because we > > > > have not reached consensus on that yet, and this will be > > > > discussed in the newly formed WG. > > > >=20 > > >=20 > > > That's all fine, but I'd suggest dropping QUIC and TLS/TCP as example= s, if > > > you're deferring the decision to the working group. Just saying "The > > > working group will not define new > > > transport protocols but will instead use existing protocols." would h= ave > > > avoided my confusion. > > >=20 > > > Best, and enjoy your working group. > > >=20 > > > Spencer > > > =20 > > > > Thanks, > > > > David > > > >=20 > > > > On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF < > > > > spencerdawkins.ietf@gmail.com> wrote: > > > > > As usual, I'm reading this, and not just looking at the words (as > > > > > previously). > > > > >=20 > > > > > Most of it looks fine, except for the part where I fell off the e= dge > > > > > of the cliff. > > > > >=20 > > > > > On Fri, Feb 14, 2020 at 9:20 AM The IESG > > > > > wrote: > > > > > > A new IETF WG has been proposed in the Applications and Real-Ti= me > > > > > > Area. The > > > > > > IESG has not made any determination yet. The following draft ch= arter > > > > > > was > > > > > > submitted, and is provided for informational purposes only. Ple= ase > > > > > > send your > > > > > > comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24= . > > > > > >=20 > > > > > > WebTransport (webtrans) > > > > > > ---------------------------------------------------------------= ----- > > > > > > --- > > > > > > Current status: Proposed WG > > > > > >=20 > > > > > > Chairs: > > > > > > Bernard Aboba > > > > > > David Schinazi > > > > > >=20 > > > > > > Assigned Area Director: > > > > > > Barry Leiba > > > > > >=20 > > > > > > Applications and Real-Time Area Directors: > > > > > > Adam Roach > > > > > > Alexey Melnikov > > > > > > Barry Leiba > > > > > >=20 > > > > > > Mailing list: > > > > > > Address: webtransport@ietf.org > > > > > > To subscribe: https://www.ietf.org/mailman/listinfo/webtransp= ort > > > > > > Archive: https://mailarchive.ietf.org/arch/browse/webtranspor= t/ > > > > > >=20 > > > > > > Group page: https://datatracker.ietf.org/group/webtrans/ > > > > > >=20 > > > > > > Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans= / > > > > > >=20 > > > > > > Description of Working Group > > > > > >=20 > > > > > > The WebTransport working group will define new client-server > > > > > > protocols or > > > > > > protocol extensions in order to support the development of the > > > > > > WebTransport > > > > > > API https://wicg.github.io/web-transport. > > > > > >=20 > > > > > > The WebTransport working group will define an application-layer > > > > > > protocol > > > > > > or suite of application-layer protocols that support a range of > > > > > > simple > > > > > > communication methods. These must include unreliable messages (= that > > > > > > might > > > > > > be limited by the path MTU), reliable messages, and ordered str= eams > > > > > > of > > > > > > reliable messages. Attention will be paid to the performance of= the > > > > > > protocol, with particular attention to the protocol=E2=80=99s o= verhead and > > > > > > the > > > > > > potential for head-of-line blocking; its ability to be deployed= and > > > > > > used > > > > >=20 > > > > > Speaking of "head of line blocking" ...=20 > > > > > =20 > > > > > > reliably under different network conditions; and its ability to > > > > > > integrate > > > > > > into the Web security model. The working group will not define = new > > > > > > transport protocols but will instead use existing protocols suc= h as > > > > > > QUIC > > > > > > and TLS/TCP. > > > > >=20 > > > > > Is the intention here to allow applications using WebTransport t= o do > > > > > something like what applications using HTTP/3-QUIC do today, and > > > > > failover to HTTP/2-TLS-TCP if QUIC is blocked or significantly ra= te- > > > > > limited? > > > > >=20 > > > > > If "Yes", that might be said more clearly.=20 > > > > >=20 > > > > > If "No" - how badly does the world need WebTransport for TLS/TCP? > > > > >=20 > > > > > I ask this especially because the charter raises head of line blo= cking > > > > > as a consideration - as it should, in 2020 - but TLS/TCP hasn't > > > > > changed about that since QUIC was chartered in 2016, with avoidin= g TCP > > > > > head of line blocking as a key goal. So listing QUIC and TLS/TCP = as > > > > > apparently equally legit existing protocols seems odd. > > > > >=20 > > > > > Could someone clue me in about this? > > > > >=20 > > > > > Best, > > > > >=20 > > > > > Spencer, who is also curious about possible coordination between > > > > > WebTransport and TAPS, but let's ignore that for now.=20 > > > > >=20 > > > > > > The group will pay attention to security issues arising from th= e > > > > > > above > > > > > > scenarios so as to protect against creation of new modes of att= ack. > > > > > >=20 > > > > > > To assist in the coordination with owners of the WebTransport A= PI, > > > > > > the > > > > > > group will initially develop an overview document containing us= e > > > > > > cases > > > > > > and requirements in order to clarify the goals of the effort. T= he > > > > > > requirements will include those arising from the WebTransport A= PI. > > > > > > Feedback will also be solicited at various points along the way= in > > > > > > order > > > > > > to ensure the best possible match between the protocol extensio= ns > > > > > > and the > > > > > > needs of the WebTransport API. > > > > > >=20 > > > > > > The group will also coordinate with related working groups with= in > > > > > > the IETF, > > > > > > such as QUIC and HTTPBIS, as appropriate. In particular, if th= e > > > > > > working > > > > > > group needs any changes to or extensions of the core protocols, > > > > > > those > > > > > > issues will be raised with the relevant working groups for deci= sions > > > > > > on how > > > > > > best to handle them. If those decisions result in work in WebT= rans, > > > > > > the > > > > > > working group last calls for that work will again be sent to th= e > > > > > > relevant > > > > > > working groups. > > > > > >=20 > > > > > > Milestones: > > > > > >=20 > > > > > > Mar 2020 - Adopt a WebTransport Overview draft as a WG work i= tem > > > > > >=20 > > > > > > Mar 2020 - Adopt a draft defining a WebTransport protocol as = a WG > > > > > > work item > > > > > >=20 > > > > > > Oct 2020 - Issue WG last call of the WebTransport Overview > > > > > > document. > > > > > >=20 > > > > > > Jan 2021 - Issue WG last call on the first WebTransport proto= col > > > > > > document > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > IETF-Announce mailing list > > > > > > IETF-Announce@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/ietf-announce --=20 Cheers Magnus Westerlund=20 ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --=-2ywqpO8f4S5nDiewreZy Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEtww ggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYT AlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBD QSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+laqg5eXTqonqnzT9ykEGL2dx9mBT +2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJHGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9 uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iVIiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpig GFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36ogzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkr bdmdnjKGrYSnJigmxw14pJugxL/Vb2EeVcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYD VR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2 aWR1YWxjYXYzLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIu dHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEu Y29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUH AgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEB CwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4QihhoQR3c vhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXDyF9mhWYbSAkJ yx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6H3zO3nsq++KBmsOi SKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvElup5n7l864FqxnC2friD o4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl60rmc8SJlt6QXKw0wXEOE1Mu bauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwDig3SZi1qP7D/Ds4V+JLIjjUJc25l 9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8Kv7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLC QaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Z la71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzYVBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd/ /n4YbY2QhDCCBgcwggPvoAMCAQICEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQELBQAwRzEL MAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRp dmlkdWFsIENBIHYzMB4XDTE3MTIxNTA3MjIyM1oXDTIwMTIxNTA3MjIyMlowcDERMA8GA1UECgwI RXJpY3Nzb24xGjAYBgNVBAMMEU1hZ251cyBXZXN0ZXJsdW5kMS0wKwYJKoZIhvcNAQkBFh5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20xEDAOBgNVBAUTB2VyYW1zd2QwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCwqUdm8HdOyYsQO09KIUUoCHvdLbACm36VqqDl5dOqieqfNP3K QQYvZ3H2YFP7ZZmIgrGjjDayKxWXcQRhOpdORy2m6vtw3b2AsLwXe0kcYjaxRWk70DClWs35S4cR V60e3uF3Fb25h3QsknxM/r/AaQh8AVpnGVlSfv07Z4cSV+KHWJUiJNlctwR7WsEm3OFQ1EdaA6ba 9CUMniwKmKAYWrnD5dJG+IRAyRBlG/DUJCZvflBL8L9PfqiDMhEcO4B2ShJqJQ5j9LZ0ungeTC84 6D60AOloeStt2Z2eMoathKcmKCbHDXikm6DEv9VvYR5VyCkB9VWy3subg849Ejz7AgMBAAGjggHE MIIBwDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsLnRydXN0LnRlbGlhLmNvbS9lcmljc3Nv bm5saW5kaXZpZHVhbGNhdjMuY3JsMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0dHA6 Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50ZWxp YXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjApBgNVHREEIjAggR5tYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4 BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMw HQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBTmK+6GlTnVbhSEEMFbB/xe xTzftjAfBgNVHSMEGDAWgBQcexmel5x2rCA92NzjkWrj2y2mUzAOBgNVHQ8BAf8EBAMCBaAwDQYJ KoZIhvcNAQELBQADggIBAGfQUq6SDTRQ39z8RKnFIhphOux3yWIccy7msuk4E05pykY0EwY2BQMO 3hCKGGhBHdy+FhcKsAzn01O/DQc2WCodmgR5VjtickliclcMItR+QrkOfbwTdCvPKSQXqCJQ5cPI X2aFZhtICQnLHRiPRdzx6ffBg3KgVgSqOUq1mt1XSlyAXMR5dUtLwNavNLLv4p9S0M4SIzoffM7e eyr74oGaw6JIqRafihgRFmDkoSUQAeKz1q/7cohoQ+c4C3xBFZGkV8Znh3z0XXqoW8SW6nmfuXzr gWrGcLZ+uIOjiEtBjoQ1o5pgiKFeFuXZRjEAYOTz1omb9LmljKrvDOb4orchxSXrSuZzxImW3pBc rDTBcQ4TUy5tq5goyxp3azyMP6sSRen5qBNGX6x7NZpHEcGnG5QoN3oyHAOKDdJmLWo/sP8OzhX4 ksiONQlzbmX228wYL36WojQ/68wjdnKui7Q019vnm4tBqrXw77sFnwq/uO8V3FjJSBvFDRI8SLKH KVwscCYl4sJBqJkeYJEQGQIspJ/Q7iUTZOtXN04PfzCPO5DbtTdR11UIP0RDe0XujoRWGnEklSUH rF7/ZRbDLhmVrvV0otSFqR1Ws3lpvPGoVa/M4BP2cFrYfNhUG2lty7ooaHvZgn4zv19r2IiRxAKB SfDeAgB5Z3/+fhhtjZCEMIIGwjCCBKqgAwIBAgIQU7h+g+GcmSiTsJtJHOy46zANBgkqhkiG9w0B AQsFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwWVGVsaWFTb25lcmEgUm9vdCBD QSB2MTAeFw0xNTEwMjcxMjE2NDZaFw0yNTEwMjcxMjE2NDZaMEcxCzAJBgNVBAYTAlNFMREwDwYD VQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzCCAiIw DQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAOzy3wAAuFDyp7vYVLfGk/fjwao71MNGNLSzzl5D tjQtMtl2ZLPZyX6ViqzTN9JOb7uZ6KxuGSpReQvt8XOh7iIhkKH9W5hRpbjTsJmUMJd6zifhOpNK 6iSU3q44+FjsQL1lVtcguUuFG6aZN0N3GFVbgt6jRrASF8t/3wy9bHPAIfMyPybpg6Y2PH5/1Nwk TepoDSmK69LGV+lV2IK6U9OWayZXZFIFIDCoGyFlhFxAEgN+qZ2+Rqg/0TM0oCHvKO2ELSGmAdnJ kwizR42ji/Y9SYTSuG75mzSe6OfCGWM8Db/xvy/20aLEPXNu1PvOgzY63WZ6cmkWnjMlVJ90pWC2 haqDm3Yf8TRdjUvAl7Pz1bTuexwShzIGakL7MkCYrEqHMRaojI/VStloQgW76E76zQ2byw5QxrhO UbisBSKRzlTlOZQgYFFAbG6ViF8DOpJh/ygtQwuTLUM5r15G7eynQV1AMTNCWcX+HUvgArUw6RfW 9L58uA68GjktFTV8s9RlDsUqsNcLqeXaV28S2WMday0YGaq/bloS8AD7KuumUKH+Ri9IGO9mJvP0 5tvDHjKpLvv80c3WLJnJU/aznYHYEt2+jjKHOTqdGTxL/zMdpRSQFSuu+KM8NoYrkU1VJqKga+QL sgqKghMp99gu1P1e6KsqseWHdXORrMbjqkBXAgMBAAGjggG4MIIBtDCBigYIKwYBBQUHAQEEfjB8 MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxpYXNvbmVyYS5jb20wSwYIKwYBBQUH MAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJv b3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEAMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQEC MDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20v Q1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20v dGVsaWFzb25lcmFyb290Y2F2MS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4G A1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUHHsZnpecdqwgPdjc45Fq49stplMwHwYDVR0jBBgwFoAU 8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcNAQELBQADggIBAFBYa/HVjDu0LqtXQ8iMp8PL Fpqchf41ksQY6R1AsoZbaBUu0NQlAQ9GzlC1pmI5s0cJnuaZI0xV6TiWS3/R2p9UgW61XD9CTIUb AL31mY3BdJf3P46gzKgQEca/DlFjq9GVmuPS4q90BLNgvgoxoHubc3C6s0OaY1sbnay5EhnvrAE4 Q511FlxmJPLnRmQGpieeXa3cPegFfY1kJDKyyFRypF1RuRLXcdMIgKEy5NX1bS3M9dQ4mgmUmVT2 d33UiKSEYQ6s/B+LFaaz4LywXSv2o3W4kbHoQs86IWst821ww0wxsCpEfClIvF7fBw2QkbG/1Pwu zAuLVStEhDzkAqOrMGctKyNEaBsyAn7Eq2eCa8QDXnkmagp9QPsNFs/oqnXj9j1cVtH9a4OPzhtg 0pd7gd0NzU/5QxibXqbYvouQgihGXHQDmaL4ruN7C4arMUqRo82YnREsKL7h3j/jtmzcMLc9Q07F 04QQd/iSR1Y5pIi6PdNBiE2/4uyAXS6KOIGZrPbNQUNrZtwiQpqQNl8AUzgegfPwrYFlFocpaF3d 1m5r+2VKKqiRQVfYPGYeZnWfkcz06JoAhc/9mjbHXSP9hvWYzeLRuoZqHGUdjOX9DIQb926OneV7 C5WMIjSY8ORkamG/HKqngmjypL3gSc6oG/E6B+1i6Ds5j0Qpj5aQMYICzTCCAskCAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJYIZIAWUDBAIBBQCgggFDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDIxNzExMDg1NFowLwYJKoZIhvcN AQkEMSIEIE1IiftLQhmSgxOvsxXqW5WeyuNhQNozHNbAf2cWVWZOMGoGCSsGAQQBgjcQBDFdMFsw RzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJ bmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMGwGCyqGSIb3DQEJEAILMV2gWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2 aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62a3lxee0wDQYJKoZIhvcNAQEBBQAEggEANQq0EnSIZKdK 78+mjY5oZtwAA5hr1v6+ubhW5lA9TLcwT119/sDdfSEARqI3Gxzhnt1cHPy6RoM4GaoFNsaSpR/T ke7UmRG2kAWL/42UTi4x+VxUAoPOVzZ7u6PlnjHhGMgGl5a3JeObd/giUms82SxRgA3a6FjwW7wh eI46jPUo1iop1xJ8lld+v0OQ0dUmmWaCjdfJz1/iuqPHyTVYohf3/igVXxc5Dl09e2L/ESyMIWKz rnVbPm1Y0Bf4sfsQ4ShpdeCVQI6yxVvaU/ClT8kJzI/qO5r5C/auIGxsHkECnLIZ1seNIQ8S+HkP JOSU+JMPfthsdVdLTs6Kb0WpigAAAAAAAA== --=-2ywqpO8f4S5nDiewreZy-- From nobody Mon Feb 17 18:34:42 2020 Return-Path: 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 C7ED8120812; Mon, 17 Feb 2020 06:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 olYdPagIvhZy; Mon, 17 Feb 2020 06:09:07 -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 0A5BF120809; Mon, 17 Feb 2020 06:09:06 -0800 (PST) Received: from [129.192.10.3] (helo=[10.149.0.124]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1j3h57-0002ZU-Gz; Mon, 17 Feb 2020 15:09:05 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 17 Feb 2020 15:09:04 +0100 Cc: David Schinazi , WebTransport , IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1581948547;0007fd1d; X-HE-SMSGID: 1j3h57-0002ZU-Gz Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 14:09:11 -0000 I would prefer to have the protocol in. If the intention is to = =E2=80=9Conly=E2=80=9D use TLS/TCP as a fallback, it could be even good = to make this explicit in the charter. Mirja > On 15. Feb 2020, at 00:57, Spencer Dawkins at IETF = wrote: >=20 > Hi, David,=20 >=20 > On Fri, Feb 14, 2020 at 5:54 PM David Schinazi = wrote: > Thanks Spencer! We added those specific protocols > at the request of the transport ADs, so I think we'll > leave them in for now if that's OK. >=20 > Of course. Do the right thing :-) >=20 > Best, >=20 > Spencer > =20 > David >=20 > On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF = wrote: > Hi, David,=20 >=20 > On Fri, Feb 14, 2020 at 2:50 PM David Schinazi = wrote: > Hi Spencer, >=20 > The main goal is for WebTransport to use QUIC and benefit > from QUIC features such as reduced head-of-line blocking. > However, on networks where QUIC is blocked, the WG will > most likely define a fallback version over TLS/TCP. That > version will obviously not see QUIC features. I think this fits > into the proposed charter, as it requires paying attention to > these concerns. >=20 > We explicitly chose not to specify which exact protocols > WebTransport will be built on in the charter, because we > have not reached consensus on that yet, and this will be > discussed in the newly formed WG. >=20 > That's all fine, but I'd suggest dropping QUIC and TLS/TCP as = examples, if you're deferring the decision to the working group. Just = saying "The working group will not define new > transport protocols but will instead use existing protocols." would = have avoided my confusion. >=20 > Best, and enjoy your working group. >=20 > Spencer > =20 > Thanks, > David >=20 > On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF = wrote: > As usual, I'm reading this, and not just looking at the words (as = previously). >=20 > Most of it looks fine, except for the part where I fell off the edge = of the cliff. >=20 > On Fri, Feb 14, 2020 at 9:20 AM The IESG = wrote: > A new IETF WG has been proposed in the Applications and Real-Time = Area. The > IESG has not made any determination yet. The following draft charter = was > submitted, and is provided for informational purposes only. Please = send your > comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. >=20 > WebTransport (webtrans) > = ----------------------------------------------------------------------- > Current status: Proposed WG >=20 > Chairs: > Bernard Aboba > David Schinazi >=20 > Assigned Area Director: > Barry Leiba >=20 > Applications and Real-Time Area Directors: > Adam Roach > Alexey Melnikov > Barry Leiba >=20 > Mailing list: > Address: webtransport@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/webtransport > Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ >=20 > Group page: https://datatracker.ietf.org/group/webtrans/ >=20 > Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ >=20 > Description of Working Group >=20 > The WebTransport working group will define new client-server protocols = or > protocol extensions in order to support the development of the = WebTransport > API https://wicg.github.io/web-transport. >=20 > The WebTransport working group will define an application-layer = protocol > or suite of application-layer protocols that support a range of simple > communication methods. These must include unreliable messages (that = might > be limited by the path MTU), reliable messages, and ordered streams of > reliable messages. Attention will be paid to the performance of the > protocol, with particular attention to the protocol=E2=80=99s overhead = and the > potential for head-of-line blocking; its ability to be deployed and = used >=20 > Speaking of "head of line blocking" ...=20 > =20 > reliably under different network conditions; and its ability to = integrate > into the Web security model. The working group will not define new > transport protocols but will instead use existing protocols such as = QUIC > and TLS/TCP. >=20 > Is the intention here to allow applications using WebTransport to do = something like what applications using HTTP/3-QUIC do today, and = failover to HTTP/2-TLS-TCP if QUIC is blocked or significantly = rate-limited? >=20 > If "Yes", that might be said more clearly.=20 >=20 > If "No" - how badly does the world need WebTransport for TLS/TCP? >=20 > I ask this especially because the charter raises head of line blocking = as a consideration - as it should, in 2020 - but TLS/TCP hasn't changed = about that since QUIC was chartered in 2016, with avoiding TCP head of = line blocking as a key goal. So listing QUIC and TLS/TCP as apparently = equally legit existing protocols seems odd. >=20 > Could someone clue me in about this? >=20 > Best, >=20 > Spencer, who is also curious about possible coordination between = WebTransport and TAPS, but let's ignore that for now.=20 >=20 > The group will pay attention to security issues arising from the above > scenarios so as to protect against creation of new modes of attack. >=20 > To assist in the coordination with owners of the WebTransport API, the > group will initially develop an overview document containing use cases > and requirements in order to clarify the goals of the effort. The > requirements will include those arising from the WebTransport API. > Feedback will also be solicited at various points along the way in = order > to ensure the best possible match between the protocol extensions and = the > needs of the WebTransport API. >=20 > The group will also coordinate with related working groups within the = IETF, > such as QUIC and HTTPBIS, as appropriate. In particular, if the = working > group needs any changes to or extensions of the core protocols, those > issues will be raised with the relevant working groups for decisions = on how > best to handle them. If those decisions result in work in WebTrans, = the > working group last calls for that work will again be sent to the = relevant > working groups. >=20 > Milestones: >=20 > Mar 2020 - Adopt a WebTransport Overview draft as a WG work item >=20 > Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG = work item >=20 > Oct 2020 - Issue WG last call of the WebTransport Overview document. >=20 > Jan 2021 - Issue WG last call on the first WebTransport protocol = document >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --=20 > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport From nobody Tue Feb 18 07:48:02 2020 Return-Path: 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 A3D421200EC for ; Tue, 18 Feb 2020 07:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=jdrosen.net 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 2bRy3wLKAvBj for ; Tue, 18 Feb 2020 07:47:58 -0800 (PST) Received: from se1-lax1.servconfig.com (se1-lax1.servconfig.com [104.244.124.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE8E120071 for ; Tue, 18 Feb 2020 07:47:55 -0800 (PST) Received: from ecbiz261.inmotionhosting.com ([173.231.209.30]) by se1-lax1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j456H-000SY6-3H for Webtransport@ietf.org; Tue, 18 Feb 2020 10:47:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jdrosen.net ; s=default; h=Content-Type:To:Subject:Message-ID:Date:From:MIME-Version: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ElOxsGAYjU464394cAtUDtszpch/KLSHPMmVGiQv5Sc=; b=jMSxmxNh/DKH8z28uN4/YXMaD/ /P53JqPRul3IJE5WIDCwp5gVxb7iQOy6banVIjFX1GwQxHDJZOiw7Wy7BIAfwxiFSPeAL2S7PZ6YO /Nx34tjc5+7S1OPf4W0TewQgciq9W1cqhFp2ibAZaa9jFpkCefd83TvET1rgxNY5xBgUitqlb/MgI jAseeKK/o96O2gZLEFNfJ8hszYtsDkusB0kHzyPtdJfpe5KqaBR9T22XfWh0ligq3+Ioinr75sp5u 0a6ZMK3T4JmiRQRrug742htGrYxp++mRcGpV1jZGMfI4cMwBHZzLo9mWagdXATfQisrNuBqgzevi3 +wlkUPKw==; Received: from mail-il1-f173.google.com ([209.85.166.173]:37351) by ecbiz261.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j4567-0093pJ-5c for Webtransport@ietf.org; Tue, 18 Feb 2020 10:47:52 -0500 Received: by mail-il1-f173.google.com with SMTP id v13so17720252iln.4 for ; Tue, 18 Feb 2020 07:47:43 -0800 (PST) X-Gm-Message-State: APjAAAWB/B6huD0yAUeBAHEukWCG0971Q51HaTZQujD5GHvnkrIV4g/V i0dcxOZcHDOtSi2FFwBZsqVdmAk60de6KAVx3aw= X-Google-Smtp-Source: APXvYqyY87u6fAjH9Pu0vYCb58asyMHejD6OeJ0C/DiLC1PDojJsufJG/8brn8zmxR9eiOSihQKc7IvYj3SZ/B0cXmg= X-Received: by 2002:a92:4997:: with SMTP id k23mr21251953ilg.176.1582040862856; Tue, 18 Feb 2020 07:47:42 -0800 (PST) MIME-Version: 1.0 From: Jonathan Rosenberg Date: Tue, 18 Feb 2020 10:47:34 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000a69c1d059edb9748" X-OutGoing-Spam-Status: No, score=-1.0 X-Get-Message-Sender-Via: ecbiz261.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: ecbiz261.inmotionhosting.com: jdrosen@jdrosen.net X-Originating-IP: 173.231.209.30 X-SpamExperts-Domain: ecbiz261.inmotionhosting.com X-SpamExperts-Username: 173.231.209.30 Authentication-Results: servconfig.com; auth=pass smtp.auth=173.231.209.30@ecbiz261.inmotionhosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0UaqOYGQPGxXNcBH7FeyDZOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDnAGsen2KeDiO50GolS3tmuyP SeHQJ3CfNoRoPk1qIXTm/Pco+QCypfsfenMiA6s5JODXbtOodkPED+RkHjVGHxm/qT8zdjr5APfl dJ+ym0pWPxogfnoVZ953YHh7n+p4JVMmgkXeahsR/ce7FII+RnR4aP4OrbEgQrPBmvwoCHs5Fu/n q1mfdqvGyP7QRMmubEYBdMHLz8fdZytxBPvQ/tfm/6ZhrBvMHqGRRS2yqrTz7IssKbNSm6Aylrz7 vRRedYGRJ5j/qgI5gfjNk3Q1FcO1wjmeb9RCa+YI49T4kOuhAPmLnhEQ2H55IKD7afzmVf1qzaRU c3P3olRHLamMQyb0mbZGjIHswS91OoTWbV3vACnlJN4y6bSeAbUjBgwJUB0x5xwn0JVoh8+nMohe tJ8ZQzrOqjAERHu4pt/Ia6wELzcGxDgkPe7eR6qspNNQGjLhGMBSrFdf8dBbPvtqJwEiRQv+PVjj wa+Z5RFCOMRAERQAllQH9FPHXfs6ey0oR7/dvDWlsWWmYvtoo/dCwvOGz8rxHwKK/GIupUcSPvcq AveHjsqi3OQ0RYuYaFViTucrugcaAcVYwSK0xHMIfgE9FrvLEUPXJbB4TOB4dAFErSs0X3oyoTc8 j/o7qulxmxWPL1fNE7Ad+FPRMGMimWgxaUBTIJceeww0VXdyJ0nGGY78cxhxg1CE3562pk2jBzof O1B1DuaEly3vQDpqtDwJWw42swm4bO6gacpMpzJ455BRyVInUbTkzONQiztd510/FotJZrRhNy3y lK/kSDcgudEky7pUm0n8o1YAKQzPVmKyU85J5e2nFczuuVL1B8G1oKz6VjwrqfAQZ7S9zexUaF+Y zdNpbHOo42T3qOYPOfbeWZtDjnn5PC2w8MO5PURcmKwvgkHFPttmw4UZDC+ZRNlh6LVZG3vcdfXd /PBWBRU3XZvUK1+KHvj8p2fafcsvPH8XaBPfCXwlAm8GGg== X-Report-Abuse-To: spam@se1-lax1.servconfig.com Archived-At: Subject: [Webtransport] New mailer and IETF107 BoF on RIPT - voip over httpbis and webtransport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 15:48:00 -0000 --000000000000a69c1d059edb9748 Content-Type: text/plain; charset="UTF-8" There is a new work effort underway to standardize an application protocol on top of httpbis for real-time voice and video, basically replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and UDP-based transport, that makes httpbis more amenable to real-time. The current draft also makes use of webtransport for media, falling back to just httpbis when not available. We've got a mailer set up: https://www.ietf.org/mailman/listinfo/v3 And you can read the core draft here: https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1 We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering a working group. It would be great to get participation and support from the experts in the webtransport community. Thx, Jonathan R. -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --000000000000a69c1d059edb9748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is a new work effort underway to standardize an appl= ication protocol on top of httpbis for real-time voice and video, basically= replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and = UDP-based transport, that makes httpbis more amenable to real-time. The cur= rent draft also makes use of webtransport for media, falling back to just h= ttpbis when not available.=C2=A0

We've got a mailer = set up:
https://www.ietf.org/mailman/listinfo/v3=C2=A0=C2=A0
<= /div>

And you can read the core draft here:
https://datatracker.ietf.org/doc/= draft-rosenbergjennings-dispatch-ript/?include_text=3D1=C2=A0

We'll be holding a BoF at IETF107 in Vancouver with the= aim of chartering a working group.=C2=A0

It would= be great to get participation and support from the experts in the webtrans= port community.=C2=A0

Thx,
Jonathan R.= =C2=A0=C2=A0

--
--000000000000a69c1d059edb9748-- From nobody Tue Feb 18 08:12:06 2020 Return-Path: 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 357FA120103 for ; Tue, 18 Feb 2020 08:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 RwfDs5GUHOCL for ; Tue, 18 Feb 2020 08:12:00 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 1B46912082E for ; Tue, 18 Feb 2020 08:11:56 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id p14so13047738vsq.6 for ; Tue, 18 Feb 2020 08:11:56 -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=CuPo7cHVMA/QmorQt0j+UEvIXQbbRllMxHjFC6XS108=; b=Q8/01IDxw6KOAaR8xBI/uT2RKKBxRJaBjDl9mn3xxLRJZ78cVi/zj7EAM/VV0RLKAU E8CjIviHmkIjqJKB1Qpp5jlMhv9Oko5VawuY739B+r9S/fG+VrnH1b3r6IvzDWoSfEu1 Vn8FEu0Wk7xgA1g6jT3bOepMhSreCGCJzsyH5OxnyM4trIWhjIyP4fHpplIzxNRgGDGn 5Avs8f761K/C7c6BYbUKU5GZRvdmXPJMi5RzqC6z3Ph1CA02PbfdONE2zvROXmPnpIPY ZH+FvwOUuhhGzLNpAOlDFKjkcbJiQ0Eq6ceYIXC39tqrkNZIeC7q65PrX/XgWe0Wp6Dz j3Pg== 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=CuPo7cHVMA/QmorQt0j+UEvIXQbbRllMxHjFC6XS108=; b=aPsT3YWfoo4ftiJzs/FVT0T6/EX4Vrz8I61WvY47seSY5PNgPXqy7ozbTApj8/6/Yf wOxQqmND/cyMcQvXnoZd4zweWD9faaxPgL8dRlx0rWISB6xR2yysvlVa+0qXd99goITi 4K0HEKQ6RDYJTMGcuoonf2jgKczEgHgWeDgbVeealUR7ZBo0s+XoII4Sn7pouLWrNI9E jqAsNpI+sVta9jbqpWB2Ao0zsS2DaH2gUqzF/SNX+FAj3ae3R8J/lHTn8FGpvzOV9DjY 6u69Cp/7mzgc/jGrh8fsqN9dGKa10eDg0/PLLOPmBfPoimTOjAWuR+juaePpugdbhJvx m1kA== X-Gm-Message-State: APjAAAXaXN7XPdwRwepBm0dPr4q8vr5g91iKVyDwyEn3WpxtUzRNYFQC xbYvzKBYf4Cx4tvgUmXNECpLgE7evOXZ4h07UcyPWvgP X-Google-Smtp-Source: APXvYqzGV8v2YeWiSLaMLYSJmIt/3pc1n4ZIsThbH1VQcd/hQRCvBbYZOomevOIbKD0glY9EDLQE2Ypi/6S6uEIWe5E= X-Received: by 2002:a05:6102:20c:: with SMTP id z12mr11632867vsp.32.1582042314677; Tue, 18 Feb 2020 08:11:54 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bernard Aboba Date: Tue, 18 Feb 2020 08:11:40 -0800 Message-ID: To: Jonathan Rosenberg Cc: Webtransport@ietf.org Content-Type: multipart/alternative; boundary="0000000000002fa059059edbeee4" Archived-At: Subject: Re: [Webtransport] New mailer and IETF107 BoF on RIPT - voip over httpbis and webtransport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 16:12:05 -0000 --0000000000002fa059059edbeee4 Content-Type: text/plain; charset="UTF-8" Can you provide a bit more detail on the requirements relating to WebTransport, such as REQ1? REQ1: The solution shall not require extensions or modifications to HTTP/3. REQ2: The solution shall work with both L4 and L7 HTTP load balancers REQ3: The solution shall work in ways that are compatible with best practices for load balancers and proxies supporting HTTP/3, and not require any special changes to these load balancers in order to function. REQ11: The solution shall provide low latency for media REQ12: The solution shall support audio and video On Tue, Feb 18, 2020 at 7:48 AM Jonathan Rosenberg wrote: > There is a new work effort underway to standardize an application protocol > on top of httpbis for real-time voice and video, basically replacing SIP, > RTP and SDP. This takes advantage of the usage of QUIC and UDP-based > transport, that makes httpbis more amenable to real-time. The current draft > also makes use of webtransport for media, falling back to just httpbis when > not available. > > We've got a mailer set up: > https://www.ietf.org/mailman/listinfo/v3 > > And you can read the core draft here: > > https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1 > > > We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering > a working group. > > It would be great to get participation and support from the experts in the > webtransport community. > > Thx, > Jonathan R. > > -- > Jonathan Rosenberg, Ph.D. > jdrosen@jdrosen.net > http://www.jdrosen.net > -- > Webtransport mailing list > Webtransport@ietf.org > https://www.ietf.org/mailman/listinfo/webtransport > --0000000000002fa059059edbeee4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you provide a bit more detail on the requirements rela= ting to WebTransport, such as REQ1?=C2=A0

   REQ1:=
 The solution shall not require extensions or modifications to
   HTTP/3.

   REQ2: The solution shall work with both L4 and L7 HTTP load balancers

   REQ3: The solution shall work in ways that are compatible with best
   practices for load balancers and proxies supporting HTTP/3, and not
   require any special changes to these load balancers in order to
   function.

   REQ11: The solution shall provide low latency for media

   REQ12: The solution shall support audio and video


On Tue, Feb 18, 2= 020 at 7:48 AM Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
There is a new work effort underway t= o standardize an application protocol on top of httpbis for real-time voice= and video, basically replacing SIP, RTP and SDP. This takes advantage of t= he usage of QUIC and UDP-based transport, that makes httpbis more amenable = to real-time. The current draft also makes use of webtransport for media, f= alling back to just httpbis when not available.=C2=A0

We= 've got a mailer set up:

And you can read the core dra= ft here:

We'll be holding a BoF at IETF107 = in Vancouver with the aim of chartering a working group.=C2=A0
It would be great to get participation and support from the ex= perts in the webtransport community.=C2=A0

Thx,
Jonathan R.=C2=A0=C2=A0

--
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--0000000000002fa059059edbeee4-- From nobody Tue Feb 18 08:24:13 2020 Return-Path: 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 5E7C5120020 for ; Tue, 18 Feb 2020 08:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=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=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=jdrosen.net 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 NuWlWgkFaZpn for ; Tue, 18 Feb 2020 08:24:09 -0800 (PST) Received: from se2-iad1.servconfig.com (se2-iad1.servconfig.com [144.208.77.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC461120044 for ; Tue, 18 Feb 2020 08:24:08 -0800 (PST) Received: from ecbiz261.inmotionhosting.com ([173.231.209.30]) by se2-iad1.servconfig.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j45fG-000Xpt-2K for Webtransport@ietf.org; Tue, 18 Feb 2020 11:24:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jdrosen.net ; s=default; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=mMqD3sr3v+nOHLKqYABpdCIS5Uem945FiRXT2fpWV6w=; b=o2tXfrrrgYjEVjkZJEqf2p9qdp bdjhQGqRlUk22vkJu8jP1qp+2gHbgoavgHZGCDUtGy6455yudI8geEltxRhvFpYpK1jhVCuCCvRtd BgbfL/NcOTd2NboVeJreE/iN386XTDAByEg27FQ3OKZFXZVoVR07L+HsKehyYNnJUkPPTr7FhQEP7 QZ5x2qrLb0HO7SEkHZYiidNPwzT6UeQKOTRb7wPxthu8D3+Ook/e0JcKaHN+XWhMYxTp/IvZ9x0ng c+HogibDwSutH9EEpUVXurUnL5Z1jSjTUKkqMT3oB0JgpRGxPktZm4TW0NnkfZxoRgZcRAWa5QUT9 wUDnORCQ==; Received: from mail-il1-f179.google.com ([209.85.166.179]:35423) by ecbiz261.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j45f4-00AbLH-OI for Webtransport@ietf.org; Tue, 18 Feb 2020 11:24:01 -0500 Received: by mail-il1-f179.google.com with SMTP id g12so17843925ild.2 for ; Tue, 18 Feb 2020 08:23:50 -0800 (PST) X-Gm-Message-State: APjAAAW15w9OeDqYMhepv3s2iFD3NOyJ3hVdZsqEnA1e5Uh9+KsEkanP 0V36c/1Qv2EDHDYf5w8PcmT+LLpZ9Xl4Ro0hoEc= X-Google-Smtp-Source: APXvYqzu9PUUwpFS9Yq0s2asdZY+GGzoq/YWQjfDR5TuQGTX7sB9uM3P0+0X1ycR2hlA5bsAXTltl4vwntrEdI3pBTs= X-Received: by 2002:a92:4997:: with SMTP id k23mr21421417ilg.176.1582043030458; Tue, 18 Feb 2020 08:23:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Rosenberg Date: Tue, 18 Feb 2020 11:23:41 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Bernard Aboba Cc: Jonathan Rosenberg , Webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000d99b77059edc18b6" X-OutGoing-Spam-Status: No, score=-1.0 X-Get-Message-Sender-Via: ecbiz261.inmotionhosting.com: authenticated_id: jdrosen+jdrosen.net/only user confirmed/virtual account not confirmed X-Authenticated-Sender: ecbiz261.inmotionhosting.com: jdrosen@jdrosen.net X-Originating-IP: 173.231.209.30 X-SpamExperts-Domain: ecbiz261.inmotionhosting.com X-SpamExperts-Username: 173.231.209.30 Authentication-Results: servconfig.com; auth=pass smtp.auth=173.231.209.30@ecbiz261.inmotionhosting.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0UaqOYGQPGxXNcBH7FeyDZOpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDnAGsen2KeDiO50GolS3tmuyP SeHQJ3CfNoRoPk1qIXTXQX6jDXTwprH3tCCFxtyOJODXbtOodkPED+RkHjVGHxm/qT8zdjr5APfl dJ+ym0pWPxogfnoVZ953YHh7n+p4JVMmgkXeahsR/ce7FII+RkGdgepX+tE3hDOqdlJngxc5Fu/n q1mfdqvGyP7QRMmubEYBdMHLz8fdZytxBPvQ/tfm/6ZhrBvMHqGRRS2yqrTz7IssKbNSm6Aylrz7 vRRedYGRJ5j/qgI5gfjNk3Q1FcO1wjmeb9RCa+YI49T4kOuhAPmLnhEQ2H55IKD7afzmVf1qzaRU c3P3olRHLamMQyb0mbZGjIHswS91OoTWbV3vACnlJN4y6bSeAbUjBgwJUB0x5xwn0JVoh8+nMohe tJ8ZQzrOqjAERHu4pt/Ia6wELzcGxDgkPe7eR6qspNNQGjLhGMBSrFdf8dBbPvtqJwEiRQv+PVjj wa+Z5RFCOMSaRWvOrnQgl9D8BDY7MFvpdaHGhhRyqhQQBJU//EzuzLdbXVWteTbXU3/F4eAOE0oz LCiw1GgT299R4iC96szkvniThBTmYvzk7cGy7MwNxjf9bG4oCE8tXKfGDzsW4pDsxBoFbdIyTZwD 0tTyhMSstYrO3cJ5/LxJUPWYiCmuk+S3445IvydeDKBSVHjl+mdLxlAdoKtTaZaygmC3RjP8yF+Z 0Cmu/gKboP7HGoqlX1z1pRXWhjh9fdbl44I0Df2TMMBo8GfVIgD/zfELGgQV9+iXw0Z5SvcvFINJ khI4r5AGPYCOSiEDj9I59D4Ol5LqW2sAYgCuOkXFAGA6L13APMx7VhMNP/C3NwCfeAq0a1X+b5ui JfvXNX+fh+j/FIprCNSbi5MsZfrPbfNSjbczWJIeDNx9EPi2+lb/gsYGTDfW9VLZFbV+QEjw8rkf 17r71WYfjIt2Mg/U0mvo5fsxA330qL0w9BYh2GgEQn/xTA== X-Report-Abuse-To: spam@se1-lax1.servconfig.com Archived-At: Subject: Re: [Webtransport] New mailer and IETF107 BoF on RIPT - voip over httpbis and webtransport X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 16:24:11 -0000 --000000000000d99b77059edc18b6 Content-Type: text/plain; charset="UTF-8" Yeah, this one is confusing. What it means is - we don't want to make an extension to HTTP which is just for voip. The goal is to sit on top of the modern http stack, which can include webtransport assuming that gets standardized. Definitely that requirement needs rewording. On Tue, Feb 18, 2020 at 11:12 AM Bernard Aboba wrote: > Can you provide a bit more detail on the requirements relating to > WebTransport, such as REQ1? > > REQ1: The solution shall not require extensions or modifications to > HTTP/3. > > REQ2: The solution shall work with both L4 and L7 HTTP load balancers > > REQ3: The solution shall work in ways that are compatible with best > practices for load balancers and proxies supporting HTTP/3, and not > require any special changes to these load balancers in order to > function. > > REQ11: The solution shall provide low latency for media > > REQ12: The solution shall support audio and video > > > > > On Tue, Feb 18, 2020 at 7:48 AM Jonathan Rosenberg > wrote: > >> There is a new work effort underway to standardize an application >> protocol on top of httpbis for real-time voice and video, basically >> replacing SIP, RTP and SDP. This takes advantage of the usage of QUIC and >> UDP-based transport, that makes httpbis more amenable to real-time. The >> current draft also makes use of webtransport for media, falling back to >> just httpbis when not available. >> >> We've got a mailer set up: >> https://www.ietf.org/mailman/listinfo/v3 >> >> And you can read the core draft here: >> >> https://datatracker.ietf.org/doc/draft-rosenbergjennings-dispatch-ript/?include_text=1 >> >> >> We'll be holding a BoF at IETF107 in Vancouver with the aim of chartering >> a working group. >> >> It would be great to get participation and support from the experts in >> the webtransport community. >> >> Thx, >> Jonathan R. >> >> -- >> Jonathan Rosenberg, Ph.D. >> jdrosen@jdrosen.net >> http://www.jdrosen.net >> -- >> 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 > -- Jonathan Rosenberg, Ph.D. jdrosen@jdrosen.net http://www.jdrosen.net --000000000000d99b77059edc18b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, this one is confusing. What it means is - we don'= ;t want to make an extension to HTTP which is just for voip. The goal is to= sit on top of the modern http stack, which can include webtransport assumi= ng that gets standardized. Definitely that requirement needs rewording.


On Tue, Feb 18, 2020 at 11:12 AM Bernard Aboba &l= t;bernard.aboba@gmail.com>= ; wrote:
Can you provide a bit more detail on the requirements relating to= WebTransport, such as REQ1?=C2=A0

   REQ1: The so=
lution shall not require extensions or modifications to
   HTTP/3.

   REQ2: The solution shall work with both L4 and L7 HTTP load balancers

   REQ3: The solution shall work in ways that are compatible with best
   practices for load balancers and proxies supporting HTTP/3, and not
   require any special changes to these load balancers in order to
   function.

   REQ11: The solution shall provide low latency for media

   REQ12: The solution shall support audio and video


On Tue, Feb 18, 2020 at 7:48 AM Jonathan Rosenberg <jdrosen@jdrosen.net> wrote:
There is a new work effort underway to standardize an applica= tion protocol on top of httpbis for real-time voice and video, basically re= placing SIP, RTP and SDP. This takes advantage of the usage of QUIC and UDP= -based transport, that makes httpbis more amenable to real-time. The curren= t draft also makes use of webtransport for media, falling back to just http= bis when not available.=C2=A0

We've got a mailer set= up:
https://www.ietf.org/mailman/listinfo/v3=C2=A0=C2=A0

And you can read the core draft here:
<= br>
We'll be holding a BoF at IETF107 in Vancouver with the a= im of chartering a working group.=C2=A0

It would b= e great to get participation and support from the experts in the webtranspo= rt community.=C2=A0

Thx,
Jonathan R.=C2= =A0=C2=A0

--
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=
--
Webtransport mailing list
Webtransport@iet= f.org
https://www.ietf.org/mailman/listinfo/webtransport=


--
Jonathan Rosenberg, Ph.D.
jdrosen@jdrosen.net<= /a>
http://www.jdro= sen.net
--000000000000d99b77059edc18b6-- From nobody Wed Feb 26 06:58:00 2020 Return-Path: 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 73BE33A08E1; Wed, 26 Feb 2020 06:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_FROM=0.001, HTML_MESSAGE=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 aMn9Wii451em; Wed, 26 Feb 2020 06:57:47 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 903A33A08DE; Wed, 26 Feb 2020 06:57:41 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id f24so2223741lfh.3; Wed, 26 Feb 2020 06:57:41 -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=/XwaKjEPoVSnqjlDlYcSWa+mFsn6hfglkxXd8whyFSk=; b=Wh/y3K8OyBEJxBTH4bSr2myNnHA8G3SsjDNX1VqPQY0vKH7wmcG7QjwP++XBYxkwEC GYLrEa47TuTTk8JSb15OEeuAGW9RscoKmRYjajLPOXRdp9t6SrlNV8jXRPKAKSZdNC70 WdzjebB4Jtq7jgh0shqZdHVNh+a8DVso++7vb7CNclR0ipPdc25A+/RAEsWcvkAwWeCq AIDVN4lST5SJuFpKH5g/Ev7twRJhb9tfXpYlCMM7vTWXkhkuw6r94gAUgqUyq1Vrpo7e Rd0ge85jswZjSguvuwJ731LPW3/x38qTl39hUaihUAZWlg5+B7r+cit8aY1HXlxL3vP2 3hCg== 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=/XwaKjEPoVSnqjlDlYcSWa+mFsn6hfglkxXd8whyFSk=; b=UiVB8LNsBqOiAYgbNPYWwBtNOC0v7YEat3sUINYZFr+K6GXUL070TuDDnEAkkxmrcS IeG72i+jFKX6SwDRphlMGUg+cAisuVoJJP4EX/u5P6HNBghHIVhfc/GWCAU6f0iwBaY/ I650cKb/wVaSwmJcmMB8/KpVMqO5tR08mbr/F7oPS6L0PPLuUO09XFNmxv59dRZ7bypd tlphiFbVL4GnV0S67EerwhMtfbEkHh4Tuc0N3FmdqUzRifyh0yZnGBgeg4i67TI6gxsJ YGuFtWSzCf9WLyIGIlgcqkJF5j5scJ5RREPjJ/Rrzq7LBRtfDZiH8gIUBfZZORLfXo0d kwWA== X-Gm-Message-State: APjAAAWHfWjp89AJnnGY5ubAQedRY6ssc0MkY1nwyuiq5V9Cj3i1JMk1 UqlzpYMz0OdBVOJbA+WLSEsfLW4k0feC0JH2wX5Hj90iPwg= X-Google-Smtp-Source: APXvYqwy3pB8OsCu3n3Maz5RRtQhU5fCL2b2GT9ynVfM5BoVnvuRs4V3iB0D1erlWikqgBta2ax8lDEt2e3O4inlM70= X-Received: by 2002:a19:6a07:: with SMTP id u7mr2709319lfu.152.1582729059393; Wed, 26 Feb 2020 06:57:39 -0800 (PST) MIME-Version: 1.0 References: <158169360444.16309.1460416678858459460.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 26 Feb 2020 08:57:12 -0600 Message-ID: To: Mirja Kuehlewind Cc: David Schinazi , WebTransport , IESG Content-Type: multipart/alternative; boundary="0000000000005c66bd059f7bd334" Archived-At: Subject: Re: [Webtransport] WG Review: WebTransport (webtrans) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 14:57:53 -0000 --0000000000005c66bd059f7bd334 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, David, On Mon, Feb 17, 2020 at 8:09 AM Mirja Kuehlewind wrote: > I would prefer to have the protocol in. If the intention is to =E2=80=9Co= nly=E2=80=9D use > TLS/TCP as a fallback, it could be even good to make this explicit in the > charter. > FWIW. Mirja's suggestion would have also improved my understanding of the charter. Clarity is good. Do the right thing, of course :-) Best, Spencer > > Mirja > > > > > On 15. Feb 2020, at 00:57, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > > > Hi, David, > > > > On Fri, Feb 14, 2020 at 5:54 PM David Schinazi > wrote: > > Thanks Spencer! We added those specific protocols > > at the request of the transport ADs, so I think we'll > > leave them in for now if that's OK. > > > > Of course. Do the right thing :-) > > > > Best, > > > > Spencer > > > > David > > > > On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Hi, David, > > > > On Fri, Feb 14, 2020 at 2:50 PM David Schinazi > wrote: > > Hi Spencer, > > > > The main goal is for WebTransport to use QUIC and benefit > > from QUIC features such as reduced head-of-line blocking. > > However, on networks where QUIC is blocked, the WG will > > most likely define a fallback version over TLS/TCP. That > > version will obviously not see QUIC features. I think this fits > > into the proposed charter, as it requires paying attention to > > these concerns. > > > > We explicitly chose not to specify which exact protocols > > WebTransport will be built on in the charter, because we > > have not reached consensus on that yet, and this will be > > discussed in the newly formed WG. > > > > That's all fine, but I'd suggest dropping QUIC and TLS/TCP as examples, > if you're deferring the decision to the working group. Just saying "The > working group will not define new > > transport protocols but will instead use existing protocols." would hav= e > avoided my confusion. > > > > Best, and enjoy your working group. > > > > Spencer > > > > Thanks, > > David > > > > On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > As usual, I'm reading this, and not just looking at the words (as > previously). > > > > Most of it looks fine, except for the part where I fell off the edge of > the cliff. > > > > On Fri, Feb 14, 2020 at 9:20 AM The IESG > wrote: > > A new IETF WG has been proposed in the Applications and Real-Time Area. > The > > IESG has not made any determination yet. The following draft charter wa= s > > submitted, and is provided for informational purposes only. Please send > your > > comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24. > > > > WebTransport (webtrans) > > ----------------------------------------------------------------------- > > Current status: Proposed WG > > > > Chairs: > > Bernard Aboba > > David Schinazi > > > > Assigned Area Director: > > Barry Leiba > > > > Applications and Real-Time Area Directors: > > Adam Roach > > Alexey Melnikov > > Barry Leiba > > > > Mailing list: > > Address: webtransport@ietf.org > > To subscribe: https://www.ietf.org/mailman/listinfo/webtransport > > Archive: https://mailarchive.ietf.org/arch/browse/webtransport/ > > > > Group page: https://datatracker.ietf.org/group/webtrans/ > > > > Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/ > > > > Description of Working Group > > > > The WebTransport working group will define new client-server protocols = or > > protocol extensions in order to support the development of the > WebTransport > > API https://wicg.github.io/web-transport. > > > > The WebTransport working group will define an application-layer protoco= l > > or suite of application-layer protocols that support a range of simple > > communication methods. These must include unreliable messages (that mig= ht > > be limited by the path MTU), reliable messages, and ordered streams of > > reliable messages. Attention will be paid to the performance of the > > protocol, with particular attention to the protocol=E2=80=99s overhead = and the > > potential for head-of-line blocking; its ability to be deployed and use= d > > > > Speaking of "head of line blocking" ... > > > > reliably under different network conditions; and its ability to integra= te > > into the Web security model. The working group will not define new > > transport protocols but will instead use existing protocols such as QUI= C > > and TLS/TCP. > > > > Is the intention here to allow applications using WebTransport to do > something like what applications using HTTP/3-QUIC do today, and failover > to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited? > > > > If "Yes", that might be said more clearly. > > > > If "No" - how badly does the world need WebTransport for TLS/TCP? > > > > I ask this especially because the charter raises head of line blocking > as a consideration - as it should, in 2020 - but TLS/TCP hasn't changed > about that since QUIC was chartered in 2016, with avoiding TCP head of li= ne > blocking as a key goal. So listing QUIC and TLS/TCP as apparently equally > legit existing protocols seems odd. > > > > Could someone clue me in about this? > > > > Best, > > > > Spencer, who is also curious about possible coordination between > WebTransport and TAPS, but let's ignore that for now. > > > > The group will pay attention to security issues arising from the above > > scenarios so as to protect against creation of new modes of attack. > > > > To assist in the coordination with owners of the WebTransport API, the > > group will initially develop an overview document containing use cases > > and requirements in order to clarify the goals of the effort. The > > requirements will include those arising from the WebTransport API. > > Feedback will also be solicited at various points along the way in orde= r > > to ensure the best possible match between the protocol extensions and t= he > > needs of the WebTransport API. > > > > The group will also coordinate with related working groups within the > IETF, > > such as QUIC and HTTPBIS, as appropriate. In particular, if the workin= g > > group needs any changes to or extensions of the core protocols, those > > issues will be raised with the relevant working groups for decisions on > how > > best to handle them. If those decisions result in work in WebTrans, th= e > > working group last calls for that work will again be sent to the releva= nt > > working groups. > > > > Milestones: > > > > Mar 2020 - Adopt a WebTransport Overview draft as a WG work item > > > > Mar 2020 - Adopt a draft defining a WebTransport protocol as a WG wor= k > item > > > > Oct 2020 - Issue WG last call of the WebTransport Overview document. > > > > Jan 2021 - Issue WG last call on the first WebTransport protocol > document > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > -- > > Webtransport mailing list > > Webtransport@ietf.org > > https://www.ietf.org/mailman/listinfo/webtransport > > --0000000000005c66bd059f7bd334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, David,=C2=A0

On Mon, Feb 17, 2020 at 8= :09 AM Mirja Kuehlewind <ietf@kue= hlewind.net> wrote:
I would prefer to have the protocol in. If the intention is to = =E2=80=9Conly=E2=80=9D use TLS/TCP as a fallback, it could be even good to = make this explicit in the charter.

FWIW= . Mirja's suggestion would have also improved my understanding of the c= harter. Clarity is good.=C2=A0

Do the right thing,= of course :-)

Best,=C2=A0

Spencer
=C2=A0

Mirja



> On 15. Feb 2020, at 00:57, Spencer Dawkins at IETF <spencerdawkins.ietf@gma= il.com> wrote:
>
> Hi, David,
>
> On Fri, Feb 14, 2020 at 5:54 PM David Schinazi <dschinazi.ietf@gmail.com>= wrote:
> Thanks Spencer! We added those specific protocols
> at the request of the transport ADs, so I think we'll
> leave them in for now if that's OK.
>
> Of course. Do the right thing :-)
>
> Best,
>
> Spencer
>=C2=A0
> David
>
> On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF <spencerdawkins.iet= f@gmail.com> wrote:
> Hi, David,
>
> On Fri, Feb 14, 2020 at 2:50 PM David Schinazi <dschinazi.ietf@gmai= l..com> wrote:
> Hi Spencer,
>
> The main goal is for WebTransport to use QUIC and benefit
> from QUIC features such as reduced head-of-line blocking.
> However, on networks where QUIC is blocked, the WG will
> most likely define a fallback version over TLS/TCP. That
> version will obviously not see QUIC features. I think this fits
> into the proposed charter, as it requires paying attention to
> these concerns.
>
> We explicitly chose not to specify which exact protocols
> WebTransport will be built on in the charter, because we
> have not reached consensus on that yet, and this will be
> discussed in the newly formed WG.
>
> That's all fine, but I'd suggest dropping QUIC and TLS/TCP as = examples, if you're deferring the decision to the working group. Just s= aying "The working group will not define new
> transport protocols but will instead use existing protocols." wou= ld have avoided my confusion.
>
> Best, and enjoy your working group.
>
> Spencer
>=C2=A0
> Thanks,
> David
>
> On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF <spencerdawkins.= ietf@gmail.com> wrote:
> As usual, I'm reading this, and not just looking at the words (as = previously).
>
> Most of it looks fine, except for the part where I fell off the edge o= f the cliff.
>
> On Fri, Feb 14, 2020 at 9:20 AM The IESG <iesg-secretary@ietf.org> wrote:<= br> > A new IETF WG has been proposed in the Applications and Real-Time Area= . The
> IESG has not made any determination yet. The following draft charter w= as
> submitted, and is provided for informational purposes only. Please sen= d your
> comments to the IESG mailing list (iesg@ietf.org) by 2020-02-24.
>
> WebTransport (webtrans)
> ----------------------------------------------------------------------= -
> Current status: Proposed WG
>
> Chairs:
>=C2=A0 =C2=A0Bernard Aboba <bernard.aboba@gmail.com>
>=C2=A0 =C2=A0David Schinazi <dschinazi.ietf@gmail.com>
>
> Assigned Area Director:
>=C2=A0 =C2=A0Barry Leiba <barryleiba@computer.org>
>
> Applications and Real-Time Area Directors:
>=C2=A0 =C2=A0Adam Roach <adam@nostrum.com>
>=C2=A0 =C2=A0Alexey Melnikov <aamelnikov@fastmail.fm>
>=C2=A0 =C2=A0Barry Leiba <barryleiba@computer.org>
>
> Mailing list:
>=C2=A0 =C2=A0Address: webtransport@ietf.org
>=C2=A0 =C2=A0To subscribe: https://www.ietf.or= g/mailman/listinfo/webtransport
>=C2=A0 =C2=A0Archive: https://mailarchive.= ietf.org/arch/browse/webtransport/
>
> Group page: https://datatracker.ietf.org/group/webt= rans/
>
> Charter: https://datatracker.ietf.org/do= c/charter-ietf-webtrans/
>
> Description of Working Group
>
> The WebTransport working group will define new client-server protocols= or
> protocol extensions in order to support the development of the WebTran= sport
> API https://wicg.github.io/web-transport.
>
> The WebTransport working group will define an application-layer protoc= ol
> or suite of application-layer protocols that support a range of simple=
> communication methods. These must include unreliable messages (that mi= ght
> be limited by the path MTU), reliable messages, and ordered streams of=
> reliable messages. Attention will be paid to the performance of the > protocol, with particular attention to the protocol=E2=80=99s overhead= and the
> potential for head-of-line blocking; its ability to be deployed and us= ed
>
> Speaking of "head of line blocking" ...
>=C2=A0
> reliably under different network conditions; and its ability to integr= ate
> into the Web security model. The working group will not define new
> transport protocols but will instead use existing protocols such as QU= IC
> and TLS/TCP.
>
>=C2=A0 Is the intention here to allow applications using WebTransport t= o do something like what applications using HTTP/3-QUIC do today, and failo= ver to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited?
>
> If "Yes", that might be said more clearly.
>
> If "No" - how badly does the world need WebTransport for TLS= /TCP?
>
> I ask this especially because the charter raises head of line blocking= as a consideration - as it should, in 2020 - but TLS/TCP hasn't change= d about that since QUIC was chartered in 2016, with avoiding TCP head of li= ne blocking as a key goal. So listing QUIC and TLS/TCP as apparently equall= y legit existing protocols seems odd.
>
> Could someone clue me in about this?
>
> Best,
>
> Spencer, who is also curious about possible coordination between WebTr= ansport and TAPS, but let's ignore that for now.
>
> The group will pay attention to security issues arising from the above=
> scenarios so as to protect against creation of new modes of attack. >
> To assist in the coordination with owners of the WebTransport API, the=
> group will initially develop an overview document containing use cases=
> and requirements in order to clarify the goals of the effort. The
> requirements will include those arising from the WebTransport API.
> Feedback will also be solicited at various points along the way in ord= er
> to ensure the best possible match between the protocol extensions and = the
> needs of the WebTransport API.
>
> The group will also coordinate with related working groups within the = IETF,
> such as QUIC and HTTPBIS, as appropriate.=C2=A0 In particular, if the = working
> group needs any changes to or extensions of the core protocols, those<= br> > issues will be raised with the relevant working groups for decisions o= n how
> best to handle them.=C2=A0 If those decisions result in work in WebTra= ns, the
> working group last calls for that work will again be sent to the relev= ant
> working groups.
>
> Milestones:
>
>=C2=A0 =C2=A0Mar 2020 - Adopt a WebTransport Overview draft as a WG wor= k item
>
>=C2=A0 =C2=A0Mar 2020 - Adopt a draft defining a WebTransport protocol = as a WG work item
>
>=C2=A0 =C2=A0Oct 2020 - Issue WG last call of the WebTransport Overview= document.
>
>=C2=A0 =C2=A0Jan 2021 - Issue WG last call on the first WebTransport pr= otocol document
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Annou= nce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-a= nnounce
> --
> Webtransport mailing list
> Webtranspor= t@ietf.org
> https://www.ietf.org/mailman/listinfo/webtran= sport

--0000000000005c66bd059f7bd334-- From nobody Fri Feb 28 14:38:28 2020 Return-Path: X-Original-To: webtransport@ietf.org Delivered-To: webtransport@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7BD3A1F58; Fri, 28 Feb 2020 14:35:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: webtransport@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931937.19931.13228301141967904614@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:19 -0800 Archived-At: Subject: [Webtransport] webtrans - Requested session has been scheduled for IETF 107 X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:26 -0000 Dear Amy Vezza, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. webtrans Session 1 (2:00 requested) Monday, 23 March 2020, Afternoon Session I 1330-1530 Room Name: Regency C size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/webtrans.ics Request Information: --------------------------------------------------------- Working Group Name: WebTransport Area Name: Applications and Real-Time Area Session Requester: Amy Vezza Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Technology Overlap: core dnssd httpbis quic taps tls tsvarea avtcore mmusic emu People who must be present: Dr. Bernard D. Aboba Ph.D. Barry Leiba David Schinazi Resources Requested: Special Requests: ---------------------------------------------------------