IETF Logo Mail Archive

Re: [Last-Call] Artart last call review of draft-ietf-quic-version-negotiation-10

Martin Thomson <mt@lowentropy.net> Wed, 05 October 2022 22:55 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE732C14E514; Wed, 5 Oct 2022 15:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=fXTVVMo7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q5FNqENU
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3tM_wwyfwYG; Wed, 5 Oct 2022 15:55:49 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10E2C14CF09; Wed, 5 Oct 2022 15:55:12 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B19EE5C00EE; Wed, 5 Oct 2022 18:55:11 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Wed, 05 Oct 2022 18:55:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:cc:content-transfer-encoding:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1665010511; x= 1665096911; bh=i9q/kvBqGsALbzC33p376eSWeihURIxywWK717qCQvU=; b=f XTVVMo7Hg5J7uk8BQJSFncVhwsyMKFb1H8FueQIXldYOxnJ3mLm5b7Kfdn24Fm6R Kxz34GbF3DEO2Hs+1x1WGfs9WTkkt6aDdbgbu/S+rFI652Cg9Ju/48pq4YIGK4Lx o3I7y0LgRHyJilWdLfhuqIS26jF1XogaZ5elkThPZOyYYg4pQnGxm4/27J/DJ+If WvGfzy4sxfA9Jjqy0bD2byzycbXvMj5A+CR5ENeY/3zt+7ZYosvT/cU/9S33HjwF kUbF7z70DRoOrGS0k3Iz+BV/8AM6wPjqieIExNR6lQKZoLhhch4AtafNZ6HfpRTX lE49Nr2sZ3FEzLervCI9w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1665010511; x= 1665096911; bh=i9q/kvBqGsALbzC33p376eSWeihURIxywWK717qCQvU=; b=Q 5FNqENUFLc/AGRNEi59TF4TdG9pUmQm7xPIy9hI4f5GAmd+GVCsnC649Mt25VzUg RcEBqzlpiZYVMukDCP3ILVNCea1qG65DvA1GIfvfS0rnG6bDEFtdaiV/Cakvibpv AWg2m7uCEaLMrOfc/w85FpFStgE5uQAsjzUACBesvtyfBQUbIXgD+OnLYgsYi0Eo rymz09Bq3d4SAoqqSn5jJMgCfh9Kn8LrkQhZOTXlIkn/pg04jLbzGDHF+qOAqmPw IUpro6YgbEX+rG0hgDe5XJ3IQ5bDt0HGa8v4Itv3QorjiQY8lUkW6Yi+mPW4Ggi5 BfnJPPxkJQefF9XK5gAwg==
X-ME-Sender: <xms:Tws-Y3bUWAD71UqzMMKK-yOasExUbjlUjrHuYjcEyZHl2OYuFtqUvQ> <xme:Tws-Y2aWcm1fC9W28biI5EZ_GhHO5WI5PwsDxEAzE6aEZgplmQU4ANXW31rIHkVcu L3uoqSRtFh9K3Zxp8U>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeigedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdfo rghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqne cuggftrfgrthhtvghrnhepjedtvdekgeeihfdtvdffffehieetgedvteelfeeiteeiiedu keeggeeikeetudejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:Tws-Y58FUp75fViCE35k4pllkg4HEJSOyiV5tHATPOuQ5N150W6Jew> <xmx:Tws-Y9qqcG8w-AUVCqF5iof2QMjQx0EA6fPOgJDz8YL-5Db8LR97GA> <xmx:Tws-YypftHUFHyOmoEZVKwhNQnsAqbYq77aeZwXkkJO9EOE8hQNNzQ> <xmx:Tws-Y1U11jmY0UC87nGjXLEoHuBD9FimCwTIFD693bWTxd-oEdoMYg>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 66F6A234007B; Wed, 5 Oct 2022 18:55:11 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1015-gaf7d526680-fm-20220929.001-gaf7d5266
Mime-Version: 1.0
Message-Id: <0c3fe774-626d-4ca7-921c-2a3643fb503a@betaapp.fastmail.com>
In-Reply-To: <CAPDSy+77pETe2jZUas0_rvkgA6=GTBRk+Vx+6GQur2JJfF5auQ@mail.gmail.com>
References: <166491906926.345.3085225025028172235@ietfa.amsl.com> <CAPDSy+77pETe2jZUas0_rvkgA6=GTBRk+Vx+6GQur2JJfF5auQ@mail.gmail.com>
Date: Thu, 06 Oct 2022 09:54:52 +1100
From: Martin Thomson <mt@lowentropy.net>
To: David Schinazi <dschinazi.ietf@gmail.com>, Tim Bray <tbray@textuality.com>
Cc: art@ietf.org, draft-ietf-quic-version-negotiation.all@ietf.org, last-call@ietf.org, quic@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/RrYXzRFgW_hcm8pEjnZVQ7v234o>
Subject: Re: [Last-Call] Artart last call review of draft-ietf-quic-version-negotiation-10
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2022 22:55:55 -0000

On Thu, Oct 6, 2022, at 09:46, David Schinazi wrote:
>> Section 7.1, send para: "If a future document wishes to define compatibility
>> between two versions that support retry, that document MUST specify…" Is an RFC
>> allowed to impose MUST constraints on future RFCs? Not a rhetorical question,
>> just never seen anything like this before. (Also 7.3)
>
> Yes, I think this is common practice as far as I know. Future documents 
> can however
> remove the requirement, but that generally requires an Updates tag.

Just to expand on this (minor) point.

This is a requirement that is imposed on future RFCs that aim to use this RFC.  This RFC is effectively a framework under which those future RFCs operate.  The integrity of the design in this RFC - specifically the security claims it makes - depends on those RFCs complying with this an other similar requirements, each expressed as a MUST.  Therefore, this is really saying "if you wish to use this RFC and gain the benefits of having done so, you need to do this".

v2.23.0 | Report a Bug | By Email