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 CE9B0131356 for ; Tue, 2 Oct 2018 10:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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] 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 n1I6hjlejXlX for ; Tue, 2 Oct 2018 10:11:26 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 3E1AF1311B9 for ; Tue, 2 Oct 2018 10:06:53 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id h26-v6so2626244otl.9 for ; Tue, 02 Oct 2018 10:06:53 -0700 (PDT) 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=ShnDr+OI5dJ7M0BuRlyJ3IoIMQlLdhG4AyWK3hObgdU=; b=e7hXXN8XRb/fkehZjJHHD3Y73Gx2qLtpwD3V4mtraYEsZLr+Laane7kMg+jheZx9/D MdgxlxCy84Xo0gTByw/SrDQAkpDWJzwM4ReUHM3MGp9lxBxbmadyJ2X+K7X/ez/JJ87K nnk7SL2FH/9ozG3fq3zJPPoD2Y4teYqjIjewG8aORzt8N4ZwwW3V3RaT4oju0ftYniTh mu9x5y3jkt2zpikNEXRBs4LpOU29uGZc2kHmqRm4KbUNE3xJBkeMguWTPLWvHp8osXFK w1RFxAQFP2FWbtwmrbny8I8YtWHPfSRo5q+u0OijzdOL9Uzkng4rmyX6aeH8u1Vn8cQV 9axA== 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=ShnDr+OI5dJ7M0BuRlyJ3IoIMQlLdhG4AyWK3hObgdU=; b=l8M6XoWZBg2KzrdNgoY+BLODdDLGPLd8WqZo9g78UTYZj8YUulf62YuVleNZ/gzleb q9rExsOjII86pNpgLK2v3n+9PiulAya61gNbsz7+RH5tQy+somlsWgylcfFNPdDmGsmt gpXdO6R59v63JuHkZRw1F/9gTO6/WDDtGJJPNPhRJ0xNxiUj1AaVDOBIfqN2fJ95khaO 5qMWi6AjAoDpGAM3M4I5vHQg2al7eWiNvSy7DdPMyE6jPuOo0RiNnma4cM/RQb0QC2C7 GQEBKUmTmwQyUOwQjR5Ndu7bZrWNwnTldQodnnIsAjQKO5Vph4uvKfxnyi6OgE9ILk7i lRHA== X-Gm-Message-State: ABuFfoh5LDxRj88kMqHKtPLkabIpVvhIOI3bwWPJZ7EBLWSwjNR/DYuH zl9zxdaoY6BPVw6ibQ4QUf7dI6LxZWr4ArBS0a4= X-Google-Smtp-Source: ACcGV633wEEn6gQOvQZ3YkfF110H5SWi3khM4zR3Ls/0aHia4h0Fl937uKItrjHQ/ucg4TtZIWvtcYKqX3K1zn6xLK0= X-Received: by 2002:a9d:9a1:: with SMTP id q30-v6mr9668248otd.351.1538500012287; Tue, 02 Oct 2018 10:06:52 -0700 (PDT) MIME-Version: 1.0 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> <32072_1538492813_5BB3898D_32072_266_1_8380ff40-29fe-269b-8ed7-4331c9e53f4d@orange.com> In-Reply-To: From: Ted Hardie Date: Tue, 2 Oct 2018 10:06:25 -0700 Message-ID: Subject: Re: Spin bit decision To: Mike Bishop Cc: alexandre.ferrieux@orange.com, Lars Eggert , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b82b3b057741f225" 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 17:11:29 -0000 --000000000000b82b3b057741f225 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 2, 2018 at 9:51 AM Mike Bishop wrote: > I don=E2=80=99t think it=E2=80=99s a grim view, I think it=E2=80=99s a pr= agmatic view. Our role > is to specify the things which are fundamental to the protocol and have t= o > happen for peers to interoperate. Mis-using normative language for other > things is an abuse of the process -- that's kind of the point of RFC 6919= . > > > > RFC 2119 says: > > In particular, [normative language] MUST only be used where it is actuall= y > required for interoperation or to limit behavior which has potential for > causing harm (e.g., limiting retransmisssions) For example, they must no= t > be used to try to impose a particular method on implementors where the > method is not required for interoperability. > > > > Given that the spin bit is not =E2=80=9Cactually required for interoperat= ion,=E2=80=9D but > is the very definition of =E2=80=9Ctry to impose a particular method on > implementors,=E2=80=9D I=E2=80=99d say that RFC 2119 imperatives are unwa= rranted. > That's not quite what we generally mean by "interoperation" here. It's quite common to have something say, in effect, "If you use X, you MUST do Y.". So, we could have a MUST in Section 2.3 of the draft, instead of the current language: Each client and server MUST reset its spin value to zero when sending th= e first packet of a given connection with a new connection ID. This reduces the risk that transient spin bit state can be used to link flows across connection migration or ID change. That MUST doesn't say anything about when you use the spin bit, it simply says that *if* you use it, other implementations will expect this behavior; if they get a new connection ID with a non-zero spin value, it will be a protocol error. That pattern of use is very common. Ted --000000000000b82b3b057741f225 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 2, 2018 at 9:51 AM Mike Bishop <mbishop@evequefou.be> wrote:

I don=E2=80=99t think it=E2= =80=99s a grim view, I think it=E2=80=99s a pragmatic view.=C2=A0 Our role = is to specify the things which are fundamental to the protocol and have to = happen for peers to interoperate.=C2=A0 Mis-using normative language for ot= her things is an abuse of the process -- that's kind of the point of RFC 6919.

=C2=A0

RFC 2119 says:

In particular, [nor= mative language] MUST only be used where it is actually required for intero= peration or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)=C2=A0 For example, they= must not be used to try to impose a particular method on implementors wher= e the method is not required for interoperability.

=C2=A0

Given that the spin bit is = not =E2=80=9Cactually required for interoperation,=E2=80=9D but is the very= definition of =E2=80=9Ctry to impose a particular method on implementors,= =E2=80=9D I=E2=80=99d say that RFC 2119 imperatives are unwarranted.=


That's not quite what we g= enerally mean by "interoperation" here.=C2=A0 It's quite comm= on to have something say, in effect, "If you use X, you MUST do Y.&quo= t;.=C2=A0 So, we could have a MUST in Section 2.3 of the draft, instead of = the current language:

   Each client and =
server MUST reset its spin value to zero when sending the
   first packet of a given connection with a new connection ID.  This
   reduces the risk that transient spin bit state can be used to link
   flows across connection migration or ID change.

That MUST d= oesn't say anything about when you use the spin bit, it simply says tha= t *if*=C2=A0 you use it, other implementations will expect this behavior; i= f they get a new connection ID with a non-zero spin value, it will be a pro= tocol error.=C2=A0 That pattern of use is very common.

=
Ted
--000000000000b82b3b057741f225--