Return-Path: 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 63080127598 for ; Tue, 2 Oct 2018 05:59:42 -0700 (PDT) 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_PASS=-0.001, UNPARSEABLE_RELAY=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 pLCNY2KM1pI3 for ; Tue, 2 Oct 2018 05:59:40 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 5AC3F124D68 for ; Tue, 2 Oct 2018 05:59:40 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id c18-v6so1760047otm.3 for ; Tue, 02 Oct 2018 05:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=w7TWozWdoZV412F0h66SXvxq7iy0XLoFf7Y41FWdlAM=; b=Y50gpFkgpBzee1NArGRkObIdYb4KPRvX2kiFxo0xxK38omgh/H5oAvxeAKqQR/w70w jUXjgc/7p5A9PhEr2QBZLCnu1ftNCLi6rQhey0CsNAiCsYTtEVfp5UrYkZV5hsAXWKcb gyDYlAJyUb10o5WJNyP1PTHtFq9OBvvvrBjxjjc3MRq4K8VDgKNT7P2eWyXJ3tkLaO1S X6Em0ewMIvDyxlWrdb+hbwnPpOSBPnce9zDvfROdzEoT+K44EbjMpKAdB8/VpdWH6IiP DxV/EeuwqJb95lIOH6r9D7Q5eQUPvfmMDQg3M0sXmbdIRbMSKThvRqs+O37YzYGlGenm oCbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=w7TWozWdoZV412F0h66SXvxq7iy0XLoFf7Y41FWdlAM=; b=FTOzO7Rhzx/jwq2qC8PgZj6WQYr5At1ayCuFrMKZGF5atSovS8Cb2cMvF8f7S2jA/q 92ErQG34KgHdhrU6/svHrmt9tEV7gK2q6vRgwgPhLnaZDxmhosxWgG+EyeBfKr+Do8lN yaRoMY62fNAAA7gmnQgew7Rlp3VzNDsgHaK/5Dkg4zoejzsn750muWe6UeGDRSlpxm2W ChodD4Dqiv0xGcWYbfH1pxT/tEx0hYNYP5nycCfjmgZPtzUS35cFQA7xT5G5wt3SUXgJ FdQ8p8AhwY6QqSl8axXB92YgyDxybanjyg/2BMhmnKwsYqnSH6xCO4Ubs2izWw9cYmMN TE3g== X-Gm-Message-State: ABuFfoiRkiq2IxmgA2AAnGNtaD8r3Wx29nw9UMpbvQLmQbEcBxaxrmo/ BtxuqBfWsUcB+ocnr11F7f5GcsawlG0sDn8Jmhc= X-Google-Smtp-Source: ACcGV60wZMa+lKEy+rV0rsPH7xCE31uOH4BqPJEqQV7gGC7PKNop7KR3iCCkV8nomLnEKezG2074CIlkpT88FqiJok0= X-Received: by 2002:a9d:429a:: with SMTP id r26mr3527035ote.337.1538485179703; Tue, 02 Oct 2018 05:59:39 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 2 Oct 2018 05:59:39 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <08A9C80F-59E6-46EE-A4D4-1F78F5085CF7@eggert.org> 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> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 2 Oct 2018 05:59:38 -0700 Message-ID: Subject: Re: Spin bit decision To: Lars Eggert , "" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000a0e55905773e7e51" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2018 12:59:43 -0000 --000000000000a0e55905773e7e51 Content-Type: text/plain; charset="UTF-8" Are there any concerns about impact and how to handle or ignore malicious manipulation of the spin either by endpoint or a middlebox? On 2 October 2018 at 14.56.16, Lars Eggert (lars@eggert.org) wrote: Hi, again, as an individual: On 2018-10-2, at 15:41, < alexandre.ferrieux@orange.com> wrote: > Well, if the spec says that en endpoint MUST copy of flip a bit, an implementor would be fairly ill-advised not do comply. sure, it may be "ill-advised", but in practice, it won't affect interop at all. > And nothing prevents from adding a "does it spin ?" criterion to the interop test suite. We can certainly consider this - it may give us some data about the current capabilities and configurations of the participating stacks. > Clearly you now have this degree of freedom: weaken that MUST into a MAY or a SHOULD, separately for each role. But for what purpose ? The point I'm trying to make is that it in practice doesn't matter if the spec says "MUST", "SHOULD" or "MAY", since it doesn't affect interop, and doesn't affect performance. Essentially, each stack can decide in isolation whether to spin, echo, do nothing, grease the bits, etc., no matter what language we put in the spec. Lars --000000000000a0e55905773e7e51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Are there any concer= ns about impact and how to handle or ignore malicious manipulation of the s= pin either by endpoint or a middlebox?



On 2 October 2018 at 1= 4.56.16, Lars Eggert (lars@eggert.org) wrote:

=
Hi,

again, as an individual:

On 2018-10-2, at 15:41, <alexandre.ferrieux@orange.com> <alexandre.ferrieux@orange.com> wrote:
> Well, if the spec says that en endpoint MUST copy of flip a bit, a= n implementor would be fairly ill-advised not do comply.

sure, it may be "ill-advised", but in practice, it won't = affect interop at all.

> And nothing prevents from adding a "does it spin ?" crit= erion to the interop test suite.

We can certainly consider this - it may give us some data about the cur= rent capabilities and configurations of the participating stacks.

> Clearly you now have this degree of freedom: weaken that MUST into= a MAY or a SHOULD, separately for each role. But for what purpose ?

The point I'm trying to make is that it in practice doesn't mat= ter if the spec says "MUST", "SHOULD" or "MAY"= ;, since it doesn't affect interop, and doesn't affect performance.= Essentially, each stack can decide in isolation whether to spin, echo, do = nothing, grease the bits, etc., no matter what language we put in the spec.

Lars
--000000000000a0e55905773e7e51--