[core] Responses to NON with 4.02

Christian Amsüss <christian@amsuess.com> Tue, 16 February 2021 20:29 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 963733A10BF for <core@ietfa.amsl.com>; Tue, 16 Feb 2021 12:29:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ldfNmYGrr0uR for <core@ietfa.amsl.com>; Tue, 16 Feb 2021 12:29:53 -0800 (PST)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922073A10A3 for <core@ietf.org>; Tue, 16 Feb 2021 12:29:53 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net []) by prometheus.amsuess.com (Postfix) with ESMTPS id 7ADC440887 for <core@ietf.org>; Tue, 16 Feb 2021 21:29:51 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com []) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id B7192FD for <core@ietf.org>; Tue, 16 Feb 2021 21:29:50 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6142E44 for <core@ietf.org>; Tue, 16 Feb 2021 21:29:50 +0100 (CET)
Received: (nullmailer pid 604186 invoked by uid 1000); Tue, 16 Feb 2021 20:29:50 -0000
Date: Tue, 16 Feb 2021 21:29:50 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Core WG mailing list <core@ietf.org>
Message-ID: <YCwrPuU31Kecn9K7@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4twL7e+S2Jb6ZaMS"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/DrTN46-IhZDeCUsZRlFLy05iI0o>
Subject: [core] Responses to NON with 4.02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2021 20:29:58 -0000


reviewing new-block told me something new about RFC7252, that is that a
response to a NON request containing an unknown critical option MUST be
either RST or complete silence (whereas in the CON case, 4.02 is the
logical response).

Why is that? A NON 4.02 response would be just the same size, give
better information, and (to me, most importantly) would not require the
additional case distinction between "it's a 4.02 because some option
value doesn't make sense" and "it's a 4.02 because I don't know the
particular option" at a very different place than were the options are

(Or worse yet: A NON may arrive at a proxy that forwards it over TCP or
as a CON, and by the time the proxy gets the 4.02, it doesn't know

And will anything go Really Bad if I ignore that MUST? (I currently do
-- up to now for ignorance, going forward because my libraries all work
under the fiction that the library is an intermediary, and thus may do
all things an intermediary may do).


To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom