Structuring the BKK spin bit discussion

Lars Eggert <lars@eggert.org> Mon, 29 October 2018 15:26 UTC

Return-Path: <lars@eggert.org>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B335A130FF1 for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 08:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ODvI2Kub_vU5 for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 08:26:52 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D631D130DF9 for <quic@ietf.org>; Mon, 29 Oct 2018 08:26:51 -0700 (PDT)
Received: from eggert.org (unknown [62.248.255.56]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id E27D92041F for <quic@ietf.org>; Mon, 29 Oct 2018 17:26:48 +0200 (EET)
Received: from slate.eggert.org (pf.eggert.org [172.16.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 0525B1D072E for <quic@ietf.org>; Mon, 29 Oct 2018 17:26:34 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_6566EC29-2637-4CEF-A9F0-6B7BE0850158"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Structuring the BKK spin bit discussion
Message-Id: <18A2F994-0E82-48E4-875D-93C674483D49@eggert.org>
Date: Mon, 29 Oct 2018 17:26:34 +0200
To: IETF QUIC WG <quic@ietf.org>
X-MailScanner-ID: 0525B1D072E.A31F6
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5a2AE7MKXonzjWfUWn-T7NZOHcE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2018 15:26:54 -0000

Hi,

you'll have seen that we've set aside a lengthy slot on the agenda in order to finish the discussion on whether the spin bit (described in draft-ietf-quic-spin-exp) should be included in the first version of QUIC the IETF publishes, and if yes, what shape that inclusion would take.

Note that draft-ietf-quic-spin-exp describes what we commonly call the single-bit spin bit variant. We'd like to confirm that the discussion will be limited to that variant.

Next, we'd like to confirm that the WG believes that it is fit-for purpose, i.e., that if a sufficient number of bits were spinning, operators could obtain the information they need. This also includes confirmation that the privacy aspects of the spin bit proposal are understood and acceptable to the WG.

We'd specifically like to ask client and server implementors with projected sizable deployments to indicate whether they intent to implement and deploy, if the WG decided to include the spin-bit in the spec. We have seen one such statement on the list from Microsoft (thank you!) and would be interested to hear from others, either on the list or during the session in Bangkok.

Finally, if the WG has agreement to include the spin bit in the spec based on the information from and the discussion on the points above, we need to come to consensus on what shape such an inclusion of the spin bit would take, e.g., negotiated extension, conformance requirements (MAY/SHOULD/MUST) for clients and servers, etc.

Please let us know if you have any questions or comments about this approach for structuring the discussion in Bangkok.

Lars and Mark