Re: Dealing with Design issues following Last Call

Lucas Pardue <> Fri, 18 December 2020 20:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97B2F3A0896 for <>; Fri, 18 Dec 2020 12:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zRyfaKCPGYTO for <>; Fri, 18 Dec 2020 12:40:12 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7A5A3A0888 for <>; Fri, 18 Dec 2020 12:40:11 -0800 (PST)
Received: by with SMTP id w1so5048886ejf.11 for <>; Fri, 18 Dec 2020 12:40:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DBfcdl/eeqBkEI9owlHHm+avPCeMdKdzKc1kKcSVokg=; b=P6dbY+EpdbGKY6goW2Yd8GjymVOVcHAgfRN++XgG8TGx2f5nZgVctWrEV/YFhOe/mc f6/6i6KbxYQGo15LJYgw9BmolOe+XIl0WKfjm1MWvPdQXB8kIfhx493yd/SSnBuvdwMw t4g2fEvo27gU6eu6gIEQWS5xX2XHtEFJsT7PVZJ9LriqD9eCgohBSF2UwQMCkTeP8x7+ KJXLu98bFccQ3elEO/3sJZLXWpOLZdWrjsVStCgsTVruiruOTI3NvZcpNq5/62xcmT6Q HhxwqFfSthUsQXTiOL94jg80T9RarFQ8FO3f1wHCAYiaOKxTAFdg3CKCXPIXso+3GbSL cTgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DBfcdl/eeqBkEI9owlHHm+avPCeMdKdzKc1kKcSVokg=; b=QaYeq8wDcdnMKNgQi2LJL9mlAC1RO0iKdXeW8MVtg0irAuDH6nE0/bFhpWhP+XXxKG 1m3E9mygJ4VudJWPPyvb5pMB0BtkBMlHFjjVTcg6N+13wZPkMH2OFx68c5UGrYNr5Dm/ fTcs/ox+aB30kIK5gyJvD1OsZEicDwdL+H5RXUckTGNKSXc1kNqO2Pe0cZYYPOJETAK9 2zD4pbpYbZvtvtn0wKpAL1FqSnNhBqZDMcVNHN9VppRplon9Xqss27/4Yx6wg30t8AxJ ZEfUip/emERY8lT5UYZt9aSv2FqKCIlk6+/hIbRP4T5Z6VBYNUanxH+BFv7dHHRycj8x AfqQ==
X-Gm-Message-State: AOAM532iEtzx9D3AEOZWVqMnAG++CO0kfYO/Jd6YtdVWmop6wsCuhAtJ 4rzJ/yEN0C+RHLHypVLoC0gjXCLOjUF/3d3uu2lcnZmbarw=
X-Google-Smtp-Source: ABdhPJzu3TjOnYd18INtrYlRHrm0Gl+IpuGuzvKpFMBP2gLjJXIi5eclDxvo+o8+DIy4U3dlVofjquJqjq7lDcIqz7w=
X-Received: by 2002:a17:906:1db2:: with SMTP id u18mr5818559ejh.440.1608324009647; Fri, 18 Dec 2020 12:40:09 -0800 (PST)
MIME-Version: 1.0
References: <> <20201218201131.GB34756@okhta>
In-Reply-To: <20201218201131.GB34756@okhta>
From: Lucas Pardue <>
Date: Fri, 18 Dec 2020 20:39:58 +0000
Message-ID: <>
Subject: Re: Dealing with Design issues following Last Call
To: QUIC WG <>
Content-Type: multipart/alternative; boundary="00000000000047616e05b6c31d42"
Archived-At: <>
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: Fri, 18 Dec 2020 20:40:14 -0000

Hey Dmitri,

On Fri, Dec 18, 2020 at 8:11 PM Dmitri Tikhonov <>

> Hi Lucas,
> Could you please clear something up for me:
> On Wed, Dec 09, 2020 at 07:22:33PM +0000, Lucas Pardue wrote:
> > * Path Challenge Padding and Amplification Protection -
> >
> >
> > We are preparing the QUIC documents and intend to cut a new set of drafts
> > for our Area Director, Magnus Westerlund, to take forward to the IESG.
> > Rather than issue a WG consensus call for the above design issues, we
> plan
> > to merge the associated PRs, mark the issues as "call-issued" and leave
> > them open until the IESG review period concludes.
> And then what?  In other words, should I implement the changes associated
> with 4257 or not?  The text is in transport-33, yet the issue is still
> open.  I take it to mean that this change is not as solid as it could be
> and it may be rolled back (otherwise, why leave the bug open?).  In this
> case, implementing this may end up to be a waste of time.

Draft-33 is effectively the proposed resolution to all issues opened during
the IETF Last Call. These are the documents that the IESG will review to
ensure we addressed last call comments. It's feasible, albeit hopefully
unlikely, that changes might be requested to the text that deals
specifically with those design issues. The IESG may also request other
changes as a result of their review, of course. The transport, tls,
recovery and invariants documents are on the agenda for the next IESG
telechat on 2021-01-07 [1].

I'd treat implementing draft 33 as trying to implement a PR before it was
merged, while the WG was running its late-stage process. There's a risk it
could change or be rolled back, it's upon implementers to decide if they
wish to bear that risk. I'll also highlight that draft 33 includes the note
"DO NOT DEPLOY THIS VERSION". That doesn't mean don't trial implement the
changes but it is a factor people should consider before investing effort
at this stage.