RE: Spin bit decision

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Tue, 02 October 2018 15:13 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
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 93009130E9F for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 08:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 8Q2VXaHSdmLb for <quic@ietfa.amsl.com>; Tue, 2 Oct 2018 08:13:28 -0700 (PDT)
Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9CEC130E8F for <quic@ietf.org>; Tue, 2 Oct 2018 08:13:27 -0700 (PDT)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w92FDPIP021624; Tue, 2 Oct 2018 16:13:25 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0408.000; Tue, 2 Oct 2018 16:13:25 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>, Lars Eggert <lars@eggert.org>
CC: IETF QUIC WG <quic@ietf.org>
Subject: RE: Spin bit decision
Thread-Topic: Spin bit decision
Thread-Index: AQHUWhYuY5uphqKTlk+gydAimQZJXKULc8WAgAAbJICAACozgIAAHI2AgAAD5ACAAAMhAIAADuGAgAASIwCAABHx0A==
Date: Tue, 02 Oct 2018 15:13:25 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BBAFFCB@bgb01xud1012>
References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com> <9A63F295-5DC5-4992-9A9C-A98F72C8430D@eggert.org> <22440_1538469028_5BB32CA4_22440_292_2_8e00a462-2bbf-acf0-1195-74269a0c2fbd@orange.com> <3E3DBC15-FE42-47CF-AF7A-1F2597ED2390@eggert.org> <24019_1538484216_5BB367F8_24019_26_1_8e6b0d8e-78f0-56c7-e731-da2ff22cb194@orange.com> <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org> <9737_1538485723_5BB36DDB_9737_147_1_82e0e028-b0e8-5e09-7bd5-e66db97c556a@orange.com> <E7479831-9594-444E-9545-A162E8D9B154@eggert.org> <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com>
In-Reply-To: <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.211]
x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-24054.007
x-tm-as-result: No-11.450700-8.000000-10
x-tmase-matchedrid: L8tZF6zWW2q7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p0NcckEPxfz2MWl hj9iHeVpxqHJpNCgnQ7WgZRcXldbCXxpK/HViL+DFqNNeSB7ZZCC7C2rJeUToWuFHUq0bxxndhe NPERaTABSFLa4rvhU1DhKz81n5lYsNLRiJDKMJurCtSG/SQAC8ftEoNSP/uXBzBJjCfi4lf3CDc jF5OS/iOgwILxPYcqWqLRLXOmgYJSf1aLEK0xXO7MjW/sniEQKz+tKvxV+YbBRvLywkYw9qaPFj JEFr+olKE0Je8DR/D6No+PRbWqfRGTjfUfrkn0A
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--11.450700-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-24054.007
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/GK8cqeFEYfS9ClxgdcBROdCJz7s>
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: Tue, 02 Oct 2018 15:13:29 -0000

Alexandre Ferrieux wrote:
>On 10/02/18 16:00, Lars Eggert wrote:
>>
>> The point I can't seem to be getting across is that irrespective of
>> what the WG decides to require, there is no penalty for individual
>> stacks at deployment time (or after) to do whatever they wish, since
>> the spin bit by design has no impact on protocol operation and interop.
>
>It is getting across, but it is a very grim view of the standardization process
>itself. Are there many examples of MUST in RFCs that turned out to be
>ignored by implementations just because they were not part of the core
>semantics and hence not enforced by other peers ?
>

One example is provided in RFC 6919 Section 1 [1].

[1] https://tools.ietf.org/html/rfc6919#section-1


-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------