RE: Structuring the BKK spin bit discussion: and manufacturers ?
<email@example.com> Tue, 30 October 2018 09:25 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9891B12DD85 for <firstname.lastname@example.org>; Tue, 30 Oct 2018 02:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([126.96.36.199]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kflF-xTXTiex for <email@example.com>; Tue, 30 Oct 2018 02:25:27 -0700 (PDT)
Received: from orange.com (mta241.mail.business.static.orange.com [188.8.131.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F47312D4E9 for <firstname.lastname@example.org>; Tue, 30 Oct 2018 02:25:27 -0700 (PDT)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 42kmKK2C7wz5wZl; Tue, 30 Oct 2018 10:25:25 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 42kmKK18QLzCql8; Tue, 30 Oct 2018 10:25:25 +0100 (CET)
Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::6958:931c:a396:f51e%19]) with mapi id 14.03.0415.000; Tue, 30 Oct 2018 10:25:24 +0100
To: Lars Eggert <email@example.com>, IETF QUIC WG <firstname.lastname@example.org>, "Mark Nottingham (email@example.com)" <firstname.lastname@example.org>
Subject: RE: Structuring the BKK spin bit discussion: and manufacturers ?
Thread-Topic: Structuring the BKK spin bit discussion: and manufacturers ?
Date: Tue, 30 Oct 2018 09:25:24 +0000
Accept-Language: fr-FR, en-US
Content-Type: text/plain; charset="iso-8859-1"
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2018 09:25:28 -0000
Hi IMO manufacturers of any sort of devices (router, box, proxy, mobile equipment...) should start sharing their intends too. Regards Emile -----Message d'origine----- De : QUIC [mailto:email@example.com] De la part de Lars Eggert Envoyé : lundi 29 octobre 2018 16:27 À : IETF QUIC WG Objet : Structuring the BKK spin bit discussion 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 _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- RE: Structuring the BKK spin bit discussion: an... emile.stephan
- Re: Structuring the BKK spin bit discussion: an... Lars Eggert