From nobody Tue Nov 17 16:45:27 2020 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 56C153A0E02 for ; Tue, 17 Nov 2020 16:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 v54A50FstR2p for ; Tue, 17 Nov 2020 16:45:24 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 D6A003A112A for ; Tue, 17 Nov 2020 16:45:23 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id ay21so170601edb.2 for ; Tue, 17 Nov 2020 16:45:23 -0800 (PST) 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=p1ty7wnhsZXtP1kQ6orACYZQ+fi0c4VrY/MNcD+B420=; b=bJkmoL85AFlk0d1rrYF2MmaAkcUGt5auF+N2XTQ8YIncaaVXB2KCT4+CA4XWRb7mfI 8vPp/UuYeFONOvFhbinfw7DxxDw4cM18NwvLNR5Q+AuTlU2LKf+1JT3d+uZK5p/OCytj wa6he2J3tuhr9hmpWulHQxDDJGSuNEu/MnP4oV1rj8jT59psXqxdkH/RqsqLo4qYXNu9 AM/6IJQ9XKEGbE9yerDmXkEsQMLdFbpjZEFzLyROx3xdWZG1YIhSgfFhEPFfSV6S7lM6 PaS33EqcIwauAZFDGhkc7wUw3cJZaUL/6MXZzRsEjLHg21T55E9o8Vixr1TUHgLfqT3R O58A== 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=p1ty7wnhsZXtP1kQ6orACYZQ+fi0c4VrY/MNcD+B420=; b=LKmzjgQO2ERykjejpXPybJiFjrza2mE1Avqcn7zAlekNzdmHULDRPYVuiUKSsTIqXG sbaQarxxStUHzQvx6208NvO27d9a03mkfdsjl5IRsbVQvxIN/ckJnhkzcsVr+CuLSbRt MXtZdBgqQVN6zFTBsKSVsIdxonqvvEQCpGs9j6gJUgaTt3VVSiVq6c7uLzbRJbecYvgZ rSK7b5Ua3RdI9uZCKCgVzUiQL4E+ww+kagwkeTnWPMNC2DGpKIRWxaE11YeanO30i0cu swL+uNxO0HC3w+X18GlTygd96X0J1b3jOHLU1aTWmp+gjoGpCFvoXlZ4/buI0Vqg1Kz4 YC3A== X-Gm-Message-State: AOAM531QaesNohNbem834TAP4PrD5Q8WHs5+BvfCl3BsUDD+x8XgTo+J Z/u8DCtr+gwlrNR1A8GLERD9E0CBWfosfW0tAIM= X-Google-Smtp-Source: ABdhPJyv9uUICNxjfve9bxjInqLOpcAlIxkcKpPyJgq2q1YtcjF5WnKFfKKAeF9dGtehdcSEXSg7b1YUeJ/ewzZMxlE= X-Received: by 2002:a05:6402:1c99:: with SMTP id cy25mr23644551edb.283.1605660322310; Tue, 17 Nov 2020 16:45:22 -0800 (PST) MIME-Version: 1.0 References: <59a19e58-ced4-4a38-89da-e9441df162fb@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Wed, 18 Nov 2020 00:45:09 +0000 Message-ID: Subject: Re: Too many GREASE codepoints To: Kazuho Oku Cc: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000002431de05b456edda" 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: Wed, 18 Nov 2020 00:45:25 -0000 --0000000000002431de05b456edda Content-Type: text/plain; charset="UTF-8" > > That said, I am not sure if we have to change the greasing scheme at this > point. When we noticed that the ack-delay extension was colliding with the > greasing ID, I created the PR below, that detects such misuse at compile > time: > > https://github.com/h2o/quicly/pull/416 > > It might just be sufficient if other endpoints implement this type of > detection scheme as well. > > Or add the failure condition to the I-D tools :D --0000000000002431de05b456edda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div>That said, I am not sure if we have to change the greasing scheme at th= is point. When we noticed that the ack-delay extension was colliding with t= he greasing ID, I created the PR below, that detects such misuse at compile= time:


It might just be sufficient if other = endpoints implement this type of detection scheme as well.

Or add the failure con= dition to the I-D tools :D

--0000000000002431de05b456edda--